RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
RFC 6550
Yes
No Objection
Note: This ballot was opened for revision 19 and is now closed.
(Adrian Farrel; former steering group member) Yes
(Dan Romascanu; former steering group member) (was Discuss) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) (was Discuss) No Objection
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?
(Robert Sparks; former steering group member) (was Discuss) No Objection
(Ron Bonica; former steering group member) (was Discuss) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
I support Tim's discuss.
(Stewart Bryant; former steering group member) No Objection
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.
(Tim Polk; former steering group member) (was Discuss) No Objection
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}.