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

I support Stephen's DISCUSS point #2.

It's been covered enough already, but I also agree with Stephen's discuss points.

I support Stephen's discuss points and would also like to see more on privacy.

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.

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..."