Last Call Review of draft-ietf-roll-efficient-npdao-11
review-ietf-roll-efficient-npdao-11-iotdir-lc-bhandari-2019-05-31-00

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?