Note: This ballot was opened for revision 05 and is now closed.
Summary: Needs 6 more YES or NO OBJECTION positions to pass.
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.
To that end, this document proposes a new IPv6 option,
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
Please consider using RFC2119 language (e.g. "shall")
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
Comment (2011-11-28 for -06)
- 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
- 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.
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
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.