[Roll] AD Review of draft-ietf-roll-efficient-npdao-16

[Alvaro Retana <[e-mail]>]

Dear authors:

I reviewed the changes (only) and have some comments/questions.
Please take a look below.

I would like for my concerns to be addressed before sending the
document back to the RFC Editor.

Thanks!

Alvaro.


[Line numbers from idnits.]

384	4.3.  Destination Cleanup Object (DCO)
...
393	     0                   1                   2                   3
394	     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
395	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
396	     | RPLInstanceID |K|D|   Flags   |  RPL  Status  | DCOSequence   |
397	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
398	     |                                                               |
399	     +                                                               +
400	     |                                                               |
401	     +                            DODAGID(optional)                  +
402	     |                                                               |
403	     +                                                               +
404	     |                                                               |
405	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
406	     |   Option(s)...
407	     +-+-+-+-+-+-+-+-+

[nit] s/RPL  Status/RPL Status   To make it easier to search, please
eliminate the extra space.


...
434	   RPL Status: The RPL Status as defined in section 6.5.1 of [RFC6550].
435	   Indicative of the reason why the DCO happened, the RPL Status MUST
436	   NOT be changed as the DCO is propagated down the route being
437	   invalidated.  This value is informative and does not affect the
438	   behavior of the receiver.  In particular, unknown values are ignored
439	   by the receiver.  Only Rejection Codes (values of 128 and above) are
440	   expected in a DCO.

[major] rfc6550 defines a field called "Status" (not "RPL Status") for
the DAO-ACK, which "Indicates the completion", and not "the reason why
the DCO happened".  Also, the value of "130 indicating that the
address has moved" is not consistent with what seems to be intent in
the DAO-ACK: "Rejection; the node sending the DAO-ACK is unwilling to
act as a parent."   While the interpretation could be stretched, it
seems to me that it would be better to simply create a new "RPL
Status" field/registry that applies specifically to the DCO.

>From the discussion on the list, it was proposed that a common
registry can be defined in draft-ietf-roll-unaware-leaves.  Looking at
that draft, and the fact that it defines "RPL Status values for use in
DAO-ACK and DCO that map the 6LoWPAN ND values defined in Table 1 of
[RFC8505]", where 130 is called "Moved", but the definition in rfc8505
refers to a stale registration...  IOW, the use of 130 doesn't seem to
map well to the definitions in rfc8505.  This seems to be another
reason to create an independent field/registry.

Is there a strong reason for the reuse?


[major] "the RPL Status MUST NOT be changed...is informative and does
not affect the behavior of the receiver...unknown values are
ignored...Only Rejection Codes (values of 128 and above) are expected
in a DCO."

If the value doesn't matter (informative) and unknown ones are
ignored, why specify that it MUST NOT change?  What is the Normative
value of that?  Specifically, if the value was changed to something <
128, what should the receiver do?


...
574	4.5.  Unsolicited DCO

576	   A 6LR may generate an unsolicited DCO to unilaterally cleanup the
577	   path on behalf of the target entry.  The 6LR has all the state
578	   information, namely, the Target address and the Path Sequence,
579	   required for generating DCO in its routing table.  The conditions why
580	   6LR may generate an unsolicited DCO are beyond the scope of this
581	   document but some possible reasons could be:

583	   1.  On route expiry of an entry, a 6LR may decide to graciously
584	       cleanup the entry by initiating DCO.
585	   2.  6LR needs to entertain higher priority entries in case the
586	       routing table is full, thus resulting in eviction of an existing
587	       routing entry.  In this case the eviction can be handled
588	       graciously using DCO.

590	   Note that if the 6LR initiates a unilateral path cleanup using DCO
591	   and if it has the latest state for the target then the DCO would
592	   finally reach the target node.  Thus the target node would be
593	   informed of its invalidation.

[] This section wasn't changed, but it seems to me that there's an
opportunity to indicate these known reasons as Status in the DCO.
Among other things, the target node would be able to identify the
reason for the unsolicited DCO...