RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
RFC 6550

Note: This ballot was opened for revision 19 and is now closed.

(Adrian Farrel) Yes

(Jari Arkko) (was Discuss) No Objection

(Ron Bonica) (was Discuss) No Objection

(Stewart Bryant) No Objection

Comment (2010-10-20 for -)
No email
send info
S3.8 - "RPL avoids creating loops when undergoing topology changes and includes rank-based datapath validation mechanisms for detecting  loops when they do occur (see Section 11 for more details)."

As far as I can see from Section 11 this should be "RPL trys to avoids creating loops...." since the text in section 11 indicates that loops may form. In any case the sentence is self contradicting.


I note that there are 10 Authors on the title page. This does not worry me per se, but I think that we need a consistent policy.

(Gonzalo Camarillo) No Objection

(Ralph Droms) (was Discuss) No Objection

Comment (2011-02-08)
No email
send info
C8. The definition of DAO-ACK rejection codes seems unclear to me:

         Status 0 is unqualified
         acceptance, 1 to 127 are unassigned and undetermined, and 128
         and greater are rejection codes used to indicate that the node
         should select an alternate parent.

Is it the case that 1 to 127 might be used to indicate some
non-rejection status while 128-255 are used to indicate a status that
requires selection of a new parent?

C10. The update to section 9.2, rule 3, actually went in the opposite
     direction from what I was trying to suggest.  In my opinion, the
     details about how to generate the downward source routes are all
     implementation details.  All that's needed for rule 3 is:

   3.  In non-storing mode, the DODAG Root MUST be able to generate
       source routes for destinations learned from DAOs

C12. It seems surprising that the following text, which is the first indication
     that the root of a grounded DODAG would act as a gateway between
     an LLN and other networks, appears in the description of
     multicast behavior in section 12:

      For unicast traffic, it is expected that the grounded DODAG root acts
      as a Low power and lossy network Border Router (LBR) and MAY
      redistribute the RPL routes over the external infrastructure using
      whatever routing protocol is used in the other routing domain.

C13. I'm not sure I understand the details of how NS/NA messages are
     used to maintain routing adjacencies.  I understand, in
     principle, that an NS/NA message exchange confirms destination
     reachability.  When, exactly, would this exchange be used?  Can
     traffic received from the neighbor be used, as in ND NUD, to
     confirm the routing adjacency?

(Russ Housley) No Objection

(Tim Polk) (was Discuss) No Objection

Comment (2010-12-14)
No email
send info
The Security Considerations includes the following text:

   Replay protection is provided via the use of a non-repeating value
   (nonce) in the packet protection process and storage of some status
   information for each originating device on the receiving device,
   which allows detection of whether this particular nonce value was
   used previously by the originating device.

I believe this refers to the CCM nonce, not the nonce that appears in the
CC base object.  It would also be good to elaborate on "some status 
information" - to my knowledge, the information is the triple {originating
device, key id K, last CCM nonce received from the sender}.  

(Dan Romascanu) (was Discuss) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) (was Discuss) No Objection

(Sean Turner) No Objection

Comment (2010-10-21 for -)
No email
send info
I support Tim's discuss.