Subject: [Roll] AD review of draft-ietf-roll-security-threats

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 8 Aug 2014 18:00:31 +0100

Hi authors,

I have conducted my usual AD review of your document having received a
publication request. The purpose of the review is to make sure that the
document is in the best possible shape to go through IETF last call and
IESG evaluation.

Thank you for taking the time and investing the effort on this
important document.

I find the content readable and easy to understand (thank you). I'm not
a security expert, but what you have written is clear and credible. Good
job!

There is just a small set of editorial issues that I would like you to 
clean up before I run the IETF last call.

I'll put the document into "Revised I-D Needed" state and wait for you
to post a revision.

Thanks for the work,
Adrian

===-

The references are a mess as indicated by idnits and the Shepherd
write-up.

http://www.ietf.org/tools/idnits?url=http://www.ietf.org/archive/id/draft-ietf-r
oll-security-threats-08.txt

The point here is that you can't just include something in the 
references section because you think it is a fine document or you are
friends with the author :-)  If a document is worth reading in the
context of this I-D, then there should be a mention of it somewhere 
(appropriate) in the text. If there is nowhere that you find it 
appropriate to mention the reference, then remove it from the references
section.

[I-D.ietf-roll-terminology] is now RFC 7102.

---

A few abbreviations are used without expansion.

I found MPLS, ESSID/PAN, CCM, PANA, EAP-TLS, DODAG.

---

Your one use of RFC 2119 language outside Section 8 is unnecessary.

   RPL uses multicast as part of it's protocol,
   and therefore mechanisms which RPL uses to secure this traffic MAY be
   applicable to MPL control traffic as well: the important part is that
   the threats are similiar.

s/it's/its/
s/MAY/might also/
s/similiar/similar/

Furthermore, while your use of 2119 in Section 8 is fine with me, it is
not in harmony with the boilerplate you have included after the
Abstract.

I suggest you move it to Section 3, and have it read...

   Although this is not a protocol specification, the key words "MUST", 
   "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC 2119 [RFC2119] in 
   order to clarify and emphasize the guidance and directions to 
   implementers and deployers of LLN nodes that utilize RPL.

---

4.3 is a helpful way to present things. I think that "Limited energy,
memory, and processing node resources" also needs to highlight the
increased susceptibility of LLN nodes to denial of service attacks since
it is not only easier o swamp such nodes, but they can be exhausted to
the extent that they are never able to function again! Such an attack
may be mounted through the routing plane (and impact both routing and
data forwarding) or through the data plane (to impact both forwarding
and routing). Thus, there is also an interdependency between the two
planes that may be tighter in LLNs than in other networks.