Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks
draft-ietf-roll-applicability-ami-15

[Ballot comment]

Thanks for the changes in response to my discuss ballot.

In the new privacy considerations section I think there
are two changes still needed:

1) The reference to I_D.thaler... should be to
draft-ietf-6lo-privacy-considerations which replaced
the Dave Thaler's individual draft.

2) RFC6550 doesn't contain the term "privacy" at all
so I'm not sure what section(s) you're referring to there.

[DEVCC] does however seem to cover the issues, so
I've cleared my discuss. That said, I'm not sure if
the privacy considerations for deployments outside
the US may be significantly different, (I would not
be surprised if they are) so I'd  encourage you to also
search for and reference e.g. a European equivalent
document if there is one available. I've not read it
but maybe [1], or some of the references contained
in [1] might be useful.

  [1] http://publications.lib.chalmers.se/records/fulltext/215870/215870.pdf

OLD COMMENTS below - I didn't check 'em.

- 1.3: what's the 3rd bullet mean? It's worded very
ambiguously. With s/(vs. non-storing)// it'd be clear.

- section 3: "a potentially significant portion of which
is taken up by protocol and encryption overhead" seems
overstated to me - are there numbers to back that up?

- 5.1, last sentence: why is it important to note that?
explaining would be good

- 7.2.3: I don't get what you're telling me here that
assists in security or interop?

- section 9: please provide references to back up the
assertion that "many available security mechanisms are not
practical for use in such networks" for some relevant
security mechanisms. The problem is that such assertions
are used to justify doing nothing at all so they ought not
be blithely made.

- 9.1: "are unique per device" etc is the only sensible
thing and would be nice if always true, but that is often
not the case - why state what's known to not be true? Or
are you trying to say something else?

- 9.2: "it is replaced" - again that's not true, only
devices known to be compromised would be replaced, which
is by no means all compromised devices

- 9.3: "already existing" - you really should have a
reference there.

[Ballot discuss]


I have two things I'd like to chat about, given that these
applicability documents are where the roll WG has iirc
said it'd address security and privacy issues with RPL:

(1) 7.1.7: Don't you need to turn that "may not need"
around and say that AMI deployments of RPL REQUIRE
implementation (and maybe use) of link layer and higher
layer security features? (You almost say that in 9.3 I
think, so it'd maybe be good to be crystal clear.

(2) Why are there no privacy considerations? I think this
document needs that. For example, an AMI mesh based purely
on link layer security could be a total privacy nightmare.
And part of that is down to RPL - if I can cause lots of
folks' traffic to be sent to me, that is RPL's issue.
That I can then see the application layer content is not
RPL's fault, but is still relevant.  I think this section
is important to include because the authors here are
presumably the ones who know the application layer
information. And the sensitive information might not only
be readings, it could include packet size, if larger
packets are caused by activity such as turning on heating,
then larger packets indicate presence and smaller ones
absence, depending on weather. I am also concerned that
there may be privacy issues arising from the various
identifiers in use here.  Did the WG consider these issues
and their potential impact on how it is or is not safe to
use RPL? (While the analysis might sound complex, I'd bet
that not much new text would be needed, but who knows
until the analysis has been done.)

[Ballot comment]

- 1.3: what's the 3rd bullet mean? It's worded very
ambiguously. With s/(vs. non-storing)// it'd be clear.

- section 3: "a potentially significant portion of which
is taken up by protocol and encryption overhead" seems
overstated to me - are there numbers to back that up?

- 5.1, last sentence: why is it important to note that?
explaining would be good

- 7.2.3: I don't get what you're telling me here that
assists in security or interop?

- section 9: please provide references to back up the
assertion that "many available security mechanisms are not
practical for use in such networks" for some relevant
security mechanisms. The problem is that such assertions
are used to justify doing nothing at all so they ought not
be blithely made.

- 9.1: "are unique per device" etc is the only sensible
thing and would be nice if always true, but that is often
not the case - why state what's known to not be true? Or
are you trying to say something else?

- 9.2: "it is replaced" - again that's not true, only
devices known to be compromised would be replaced, which
is by no means all compromised devices

- 9.3: "already existing" - you really should have a
reference there.

[Ballot comment]
Section 1.2: Required reading - Why is the item [surveySG] in required reading not part of the normative references?

Section 1.3: Please expand RPL before first use and add a reference to RFC6550

Section 2: Is this section really required? Seems like a summarization of the RPL RFC. At least consider removing the part that starts with  "RPL was designed to meet the following application requirements:" and mentions a list of requirement RFCs. This list does not seem relevant here and is also covered in the RPL spec itself.

Section 4.1: This does not sound right. Isn't the periodic meter read traffic going the other direction? " The traffic generated by the head-end server and destined to metering devices is dominated by periodic meter reads,"

Section 7.4.1: Please add a reference the trickle algorithm at first use. e.g. "Trickle [RFC6206] was designed to be..."

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-roll-applicability-ami-12.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: roll-chairs@ietf.org, aretana@cisco.com, roll@ietf.org, draft-ietf-roll-applicability-ami@ietf.org, mcr+ietf@sandelman.ca
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks) to Proposed Standard


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'Applicability Statement for the Routing Protocol for Low Power and
  Lossy Networks (RPL) in AMI Networks'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-04-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document discusses the applicability of RPL in Advanced Metering
  Infrastructure (AMI) networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/ballot/


No IPR declarations have been submitted directly on this I-D.

AD Review

The first two comments listed as Major should be fairly simple to resolve.  Security seems to be implied, but not explicitly discussed in detail as needed by a Standards Track document.

Some of the Minor comments are related to references, some missing, some that we should make Informative..  This topic is not as show-stopping as Security, but we need to resolve it too.

Thanks!

Alvaro.


Major:

1. There are 7 authors listed on the front page.  In general we want the list to be at most 5.  Please work among yourselves to cut the number of authors.  Alternatively, we can just list an Editor(s) (there's one already identified) + Contributors..or you can
produce a justification detailing the contributions of each author to consider an exception.

2. Section 1.3. (Out of scope requirements) includes "RPL storing mode of operation in AMI networks" as out of scope.  However, in Section 7.1.2.
(Storing vs. Non-Storing Mode) says that "the use of RPL storing or non-storing mode SHOULD be deployment specific", including considerations for their use.  It seems to me that if storing mode is out of scope then it should remain that way. If not, then more
information than just what is in 7.1.2 should be added to the text.

3. Section 9. (Security Considerations)  In general this section concerns me because you seem to leave security to mechanisms that "are typically in place" (= not always) and don't really provide considerations otherwise.

* "…link-layer, transport-layer and/or application-layer security mechanisms are typically in place and using RPL's secure mode is not necessary".  What
happens if those mechanisms are not there?  I think that in the text you imply that "RPL's secure mode" is the answer — if so, then you should explicitly mention specifics (with pointers).
* In 9.3. (Security Considerations based on RPL's Threat Analysis) you say again that the threats in RFC7416 are addressed by those same
link/application layer mechanisms.
* Having said that, in Section 7.2.3 you describe L2 security features that may address most/all (?) of the cases.  If your intent is for AMI networks to always use those features, then please be explicit about it in the Security Considerations section.
* L2 security could address the link-layer security, but what about end-to-end (transport and/or application)?  In 9.3 you do talk about "credential management" and an "authorization process", but don't provide specifics as to what those are or should be.



Minor:

1. References: 

* Please add references in Section 1.2. (Required Reading).  The references seem to be listed in the References Section, but not pointed out in the text.
* There are several versions of 802.15.4 (and amendments) used in the text, but only 802.15.4-2006 and 802.15.4e-2012 actually listed as References.  It may not be apparent to the average reader the relationship between the different versions and the relevance of mentioning all of them.  If mentioned there should at least be references to the different documents.
* The mention of the different IEEE standards is not consistent.  For example, 802.15.4e-2012 and 802.15.4e are used — is there a difference?  Similar for 1901.2-2013 and 1901.2.  Note that the average IETF reader may not always be familiar with the IEEE standards relationship, notation, etc..
* In general, it feels like the IEEE references should be Normative — specially if you are making assumptions about the link layer security (see above).
* Section 8. (Manageability Considerations) needs a reference to this: "DIO messages SHOULD contain a DODAG Configuration option for disseminating the
Trickle Timer parameters throughout the network".
* I think the following references can be made Informative: RFC5867, RFC5826, RFC5673, RFC7102 and RFC6997.

2. Please expand on first use: LBR, MP2P.

3. In Section 4.3. (RPL applicability per Smart Grid Traffic Characteristics) you write that "support of peer- to-peer
communications between DODAG nodes is identified as a key feature to be supported".  The traffic characteristics of this type of traffic are obviously different than "normal" communication M2HE/HE2M — should these be called out specifically?

4. Section 6. (Using RPL to Meet Functional Requirements) says that the "functional requirements for most AMI deployments are similar
to those listed in [RFC5548]".
* Are there other important requirements that don't apply to "most" deployments?  The point above about peer-to-peer communications comes to mind.
* The requirements section in RFC5548 is a lot longer than this Section.  Does it mean that all the requirements not mentioned from RFC5548 also apply here?  Or are you calling out in this document requirements that are different? Or maybe just mentioning the ones that are applicable?
* It is specially important to understand the scope given that RFC5548 is referenced as Normative, but it is an Informational RFC (so it would be a downref) -- I want to make sure we're doing the right thing.

Nits:

1. Section 3. (Description of AMI networks for electric meters)  Is there a way to make this text more generic to any part of the world without mentioning all the regulatory agencies (for example)?  "…due to a combination of factors including Federal Communications Commission (FCC) or other continents' regulations on spectrum use, American National Standards Institute (ANSI) standards or other continents' regulation on meter behavior and performance, on heat emissions within the meter, form factor and cost considerations."  Maybe something like "…due to a combination of factors including regulations on spectrum use, and on meter behavior and performance, on heat emissions within the meter, form factor and cost considerations."

2. Some substitutions:
* s/participate to a HAN/participate in a HAN
* s/with in/within
* s/peer- to-peer/peer-to-peer

3. Section 10. (Other Related Protocols): "This section is intentionally left blank."  I know this is part of the template..but if it's not needed, then maybe we don't want it in there.

Essay Style Document Writeup


1. Summary

Who is the document shepherd? Who is the responsible Area Director?

The document shepherd is ROLL co-chair, Michael Richardson.
The responsible AD is Alvaro Retano.

This is a standards track document in fullfilment of a charter item
to explain how to use RPL in Advanced Metering Infrastructure networks.

The document follows the template:
    draft-ietf-roll-applicability-template-08
which underwent a WG consensus call, and has previously been reviewed
by the SecDir.

The Applicability document series from the ROLL WG collects a series of
operational and security options into a single place, picking specific
items from a the palette of options provided in RFC6550.

The abstract is:
  This document discusses the applicability of RPL in Advanced Metering
  Infrastructure (AMI) networks.

While in some cases applicability statements in other WG have been
published as BCP or Informational, the applicability statements from the
ROLL WG are in essence industry specific profiles of IETF Standards.
Standards Track is appropriate for these specifications; they are intended to
be used as part of procurement and compliance work.


2. Review and Consensus

The applicability statement series from the ROLL WG tends to involve small
subsets of the WG, as there are typically few members of the WG who are
involved in a specific industry.  The industries represented by this
document are new to the IETF process; the document has taken a long time to
be produced and reviewed by the industry involved as this industry is
used to closed proprietary verticals, is not used to collaborating (in
public) with competitors.

The move to a new document editor was required to close certain issues, and
finalize the document.

The shepherd observes the participants involved are representative of
much internal review that occured in this sector.

The document had an early SecDir review, along with a SecDir review team
review that was done to the template.  WG reviews pointed to situations where
there was "fence-sitting" -- an unwillingness to make a choice between
storing and non-storing mode for instance --  and pushed for some specific
choice to be made.  Often this fence-sitting was the result of attempting to
be too inclusive in scope, and a reduction in scope was accomplished.

3. Intellectual Property

There have been no IPRs claims against the document, and authors have been
complied with BCP 78 and 79.

4. Other Points

The downrefs are to Information RFCs produced by the WG as requirements
documents, and are appropriate.

There are no IANA considerations.

This document has been around for a very long time, and has suffered at times
from "absenttee-landlords" --- authors who have changed jobs, or job
priorities.

The AMI industry has historically been a vertical with utilities procuring
specific devices for their "plant" with little thought to second sources or
interoperability.  Further, the utilities have expertise to install and
manage their networks: this includes being able to plug cables (such as JTAG
cables) into devices in order to provision layer-2 keys.

As such, standardized automatic key management facilities are not at present
interesting to these industries.  While this is unfortunate, the document is
pretty clear about what layer-2 facilities are to be used.

The document has been through IDnits.