Last Call Review of draft-ietf-roll-efficient-npdao-11

Request Review of draft-ietf-roll-efficient-npdao
Requested rev. no specific revision (document currently at 18)
Type Last Call Review
Team Internet of Things Directorate (iotdir)
Deadline 2019-05-31
Requested 2019-05-07
Requested by Alvaro Retana
Authors JADHAV Rahul, Pascal Thubert, Rabi Sahoo, Zhen Cao
Draft last updated 2019-05-31
Completed reviews Iotdir Last Call review of -11 by Shwetha Bhandari (diff)
Secdir Last Call review of -10 by Brian Weis (diff)
Genart Last Call review of -10 by Francis Dupont (diff)
Rtgdir Telechat review of -12 by Eric Gray (diff)
Secdir Telechat review of -12 by Brian Weis (diff)
Assignment Reviewer Shwetha Bhandari
State Completed
Review review-ietf-roll-efficient-npdao-11-iotdir-lc-bhandari-2019-05-31
Posted at
Reviewed rev. 11 (document currently at 18)
Review result Ready with Issues
Review completed: 2019-05-31


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

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 and 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"
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?