The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams
RFC 6553
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
(Jari Arkko; former steering group member) (was Discuss, Yes) Yes
(Adrian Farrel; former steering group member) No Objection
I have no objection to the publication of this document, but I have a umber of questions/nits that I hope you will consider. Section 1 To that end, this document proposes a new IPv6 option, s/proposes/defines/ --- Setion 2 Every RPL router along a packet's delivery path processes and updates the RPL Option. If the received packet does not already contain a RPL Option, the RPL router must insert a RPL Option before forwarding it to another RPL router. Surely that means that the absence of the option indicates a defect in the upstream router. This issue is also present in section 4 where there is some flexibility about whether to include the RPL Option, but no guidance. --- Section 3 Please consider using RFC2119 language (e.g. "shall") --- Section 3 Nodes that do not understand the RPL Option MUST discard the packet. You cannot state this in this way. Nodes that do not understand the option will not implement this spec! You probably simply need: As defined in [foo] nodes that do not understand an option on a received packet MUST discard the packet. --- Sections 3 and 7 Please check "sub-TLV" and "TLV". I think you have used them interchangeably.
(Dan Romascanu; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) (was Discuss) No Objection
(Robert Sparks; former steering group member) No Objection
Please double-check the first paragraph of section 4 to make sure that "ICMPv6 errors generated by inserting the RPL option" is really what you mean to say - are you talking about errors that resulted from inserting the option itself, or possibly other ICMP errors that might result from other data in the tunnel header?
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
The Gen-ART Review by Joel Halpern on 22-Nov-2011 included a suggestion for improved clarity. Please consider it. While calling a bit the O bit does not appear unreasonable, I note that when looking at the packet form, the difference between the O bit and the mbz bits marked as 0 is small, and a likely source of confusion for the reader.
(Sean Turner; former steering group member) No Objection
I support Stephen's discuss.
(Stephen Farrell; former steering group member) (was Discuss) No Objection
- Why does this header need an instance ID when the SRH did not? - I don't get why this wasn't part of the core RPL spec, if in fact "RPL requires..." this as stated at the start of section 2. - s2, s/This draft specifies the use.../This draft also specifies the use.../ would be clearer as the non-tunnelled option is also allowed here. - s4, this says the router MUST include the RPL option - but is that needed in *every* packet? - s6, it would be better to give more detail of the several potential attacks, so that people could know to look out for or mitigate those.
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection