The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams
draft-ietf-6man-rpl-option-06

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.

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?

  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.

I support Stephen's discuss.

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