The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams
Note: This ballot was opened for revision 06 and is now closed.Search Mailarchive
(Jari Arkko) (was Discuss, Yes) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) (was Discuss) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
Comment (2011-11-30 for -)
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.
(Stephen Farrell) (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.
(Russ Housley) No Objection
Comment (2011-11-28 for -)
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.
(Pete Resnick) No Objection
(Dan Romascanu) No Objection
(Peter Saint-Andre) No Objection
(Robert Sparks) No Objection
Comment (2011-11-29 for -)
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?
(Sean Turner) No Objection
Comment (2011-11-30 for -)
I support Stephen's discuss.