[Roll] review of dao-projection -22

["Li Zhao (liz3)" <[e-mail]>]

Hello Authors,

Thanks for your great effort. The PDAO draft looks more clear and detailed. Following is some concern:

3.5.2 Using Non-Storing Mode joining Tracks
P-DAO 1 signals C==>D==>E-to-F,G
P-DAO 2 signals A==>B==>C-to-C,F,G

   [Li] ->  Should it be ?
P-DAO 1 signals C==>D==>E-to-F,G
P-DAO 2 signals A==>B==>C-to-E,F,G

    Otherwise RIBs in A cannot include destination to E.

4.1. Extending RFC 6550
To ensure that the PDR and P-DAO messages can flow at most times, it is RECOMMENDED that the nodes involved in a Track ===mantain=== multiple parents in the Main DODAG, advertise them all to the Root, and use them in turn to retry similar packets. It is also RECOMMENDED that the Root uses diverse source route paths to retry similar messages ===ot=== the nodes in the Track.¶

[Li] -> Typo for “mantain” and “ot”?

4.1.6.
This specification defines a new flag "Projected Routes Support" (D).
The DODAG Configuration option is copied unmodified from parents to children. ====xref target='RFC6550'/>====  states that:

[Li] -> Typo for “xref target='RFC6550'/>”.  Why is flag named as “D”? There is no D in "Projected Routes Support"…


5.1 The Root may use an asynchronous PDR-ACK with an negative status to indicate that the Track was terminated before its time.

[Li] -> What's the difference between negative status PDR-ACK and No-Path P-DAO in section 6.5?  And when to use asynchronous PDR-ACK?
In storing mode, root should use No-Path P-DAO to tear down Track from egress node. Is PDR-ACK still needed?
In non-storing mode, No-Path P-DAO to ingress node is also enough.
But the PDR-ACK Status field makes sense. Is it possible to add this field in No-Path P-DAO?


5.1 One and only one RPL Target Option MUST be present in the message.

[Li] -> Is it possible to remove the limitation?  It’s not flexible If PDR can only carry one RTO.
For instance in figure 7, if node I requests P-Route to B&H together, Root can only push one Track I->A->B->H. Otherwise, Root may push two Tracks I->A->B and I->F->G->H.
If Root cannot computer one Track to multiple RTO, it can response with a special PDR-ACK Status.



5.4 only the router with the lowest Interface ID in its registered address needs report the SIO, and the Root will assume symmetry.



[Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, if A chooses B as sibling, but B doesn't choose A as sibling, Root may treat SIO from A as symmetry incorrectly when only receiving SIO from A.



6.2  There is no notification to the requesting node when those changes happen.



[Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send notification to the requesting node when those changes happen.





6.3 In a particular deployment where PDR are not used, the namespace can be delegated to the main Root, which can assign the TrackIDs for the Tracks it creates without collision.



[Li] -> Can you add some description for the collision case? E.g., node trusts itself than Root.



6.4.1 In both cases the Track Ingress is the owner of the Track, and it generates the P-DAO-ACK when the installation is successful

[Li] ->  Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g. any flags?  Normally, root won't receive any DAO-ACK from nodes.
Is it possible to add flag to distinguish P-DAO-ACK from DAO-ACK as P-DAO from DAO.


8 Profiles 0 and 1 are REQUIRED by all implementations that may be used in LLNs; this enables to use Storing Mode to reduce the size of the Source Route Header in the most common LLN deployments.

[Li] -> Profile 0 is the Legacy support of [RPL<https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-22.html#RFC6550>] Non-Storing Mode. I’m confuse about “this enables to use Storing Mode to reduce the size of the Source Route Header in the most common LLN deployments.”



Best regards,
Li