An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)
draft-ietf-6man-rpl-routing-header-07

I have no objection to the publication of this document, but I have a number of small editorial questions/comments that I hope you will address along the way.

Section 2

   First, RPL routers implement a strict source route policy where each
   and every IPv6 hop is specified within the SRH.

appears to be in conflict with

   2.  If the SRH only specifies a subset of the path from source to
       destination, the router uses IPv6-in-IPv6 tunneling [RFC2473]

This probably just needs clarifying text in the paragraph. There is 
explanation of when the situation occurs (after the numbered list).

---

Section 3 Next Header

Shouldn't your base reference be RFC 2460? If IPv6 was to choose to 
diverge from IPv4, which one would you follow?

---

Section 3 Routing Type

You do not mention the use to which this field is put anywhere in your
document. It should probably go here.

---

Section 3 Reserved

You have not said how the Reserved field is handled.

---

It would have been useful to state (section 4.1?) how "segments left"
is set on the initial SRH and whether the first entry in the address
list includes the source node.

---

Section 4.2

          else if 2 or more entries in Address[1..n] are assigned to
                  local interface and are separated by at least one
                  address not assigned to local interface {

This check is more specific than the text previously indicated. This 
is the first mention of non-adjacent repeat addressing.

---

Section 4.2

             swap the IPv6 Destination Address and Address[i]

Do you really mean swap? Or do you just want to set DstA = Address[i] ?

---

Section 4.2

I'm surprised that you check and decrement the hop limit so late in the
cycle.

Comment added on 11/30.

The working group summary is pretty terse.  I think it would be
helpful to explain that the design and use of the option morphed
several times during the working group discussion before
it arrived at its current state.  Also, the working group summary
should refer to the roll (not RPL) working group.

- how are RPL routers supposed to know which of them are border routers
at what point in time? Doesn't needing to know this further constrain the 
applicability of this scheme? 

- is it allowed for a RPL router to just drop an SRH and replace it with
an entirely new SRH?

- s1, "necessary mechanisms" is a bit odd, be better to name them if
they're known/agreed already.

- 6.1 seems to imply that all the attacks listed can be mounted from
within the LLN. Truth in advertising would call for saying that
explicitly.