Reviewer: Shwetha Bhandari Review result: Ready with Issues I am an assigned IOT directorate reviewer for <draft-ietf-roll-efficient-npdao >. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the IOT Directorate, see https://datatracker.ietf.org/group/iotdir/about/ Following sections/text need clarification as requested below: > 2.2. Invalidate routes of dependent nodes I am a bit confused about what this section implies. In the storing mode, RIB that results in the 6LRs with the DAO received will result in the identifying dependent nodes. See E.g https://tools.ietf.org/html/rfc6550#appendix-A.2.2 and https://tools.ietf.org/html/rfc6550#appendix-A.2.3. With this a NPDAO received from a node that is the next hop for its dependent nodes should result in the parent clean up routes to the dependent nodes as well as generate DAO to reflect the updated RIB. If this is correct then why would invalidating routes of dependent nodes be an issue with existing RPL + NPDAO mechanism? IMHO Route invalidation and RIB maintenance based on RPL messaging is an implementation decision that RPL doesnt have to specify. > "Dependent nodes route invalidation on parent switching" https://tools.ietf.org/html/draft-ietf-roll-efficient-npdao-11#section-3.2 Based on response to the above this requirement may not really be called out here? >4.6.1. Dependent Nodes invalidation For the same reasons as above it is confusing why this consideration is needed. >NPDAO and DCO in the same network In a network that has mix of nodes with DCO implementation how will a node is updated with DCO implementation decide on recommended option 2? The choice of picking option 2 largely depends on capability of the upstream nodes rather than the node that wants to invalidate a prefix to itself. Is there a way to discover capability of the upstream nodes in old and new path to see if DCO is implemented before that choice can be made?
