Re: [Roll] draft-ietf-roll-efficient-npdao review

[Rahul Jadhav <[e-mail]>]

Thank you Peter for the thorough review.

Updates in -08:
1. Section 4.4.3 (DCO with multiple preferred parent) is updated with more
detailed text. Also an example DCO messaging for multiple preferred parents
is added in the Appendix section (A.2).
2. DCO, DCO-ACK initial values for DCOSequence is updated. Handling of
DCO-ACK failure explained.
3. Security considerations

Please find responses inline..

Thanks,
Rahul

On Thu, 27 Sep 2018 at 18:42, Peter van der Stok <[e-mail]>
wrote:

> Please find answers to responses and additional review of -06, later
> switching to -07
>
> Peter
>
> Rahul Jadhav schreef op 2018-09-27 10:49:
>
> Please find responses inline.
>
> Thanks,
> Rahul
>
> On Thu, 6 Sep 2018 at 18:40, Peter van der Stok <[e-mail]>
> wrote:
> [RJ] We have revisited all such instances and reworded to make the
> terminology consistent.
>
>
> [RJ] We had a good discussion internally to check whether to use the new
> terms you suggested. But we thought it might further complicate things and
> deter readability. We have updated the terminology sections with few
> previously un-explained terms and have revised wordings for sections 2 and
> 3.
>
> [pvds]The terminology is not a objective in itself. I think the text has
> been much clarified. thanks.
> BTW, sometimes it helps to introduce concepts and name them to make the
> text and ideas clearer.
>
> [RJ]: We have added definitions of 6LBR, 6LR DODAG, DAG in the terminology
section. Some of it we duplicated from 6550 so as to  help the reader.


>
>> In section 1.4; to which what subtree do you refer?
>>
>
> [RJ] We have added an explicit section "DCO with multiple preferred
> parents" to make it explicit.
> [pvds]see my review below
>
>
>>
>>
>
> [RJ] In introduction section we have explicitly added text saying the
> technique is applicable for storing MOP only.
> [pvds]That helped a lot.
>
>>
>> 3.1 How can transmission be tolerant to a link failure when the link has
>> disappeared completely or the node has been removed; some explanation is
>> needed here. It would help if the assumptions are listed: like there is
>> another path via ....
>>
>
> [RJ] Have reworded the para.
> [pvds] I still don't get it; what happens when no packet at all passes
> through the link? The NPDAO will never reach (B), (G), and (H) (your
> example), the DCO will reach (B) and (G); is that the tolerance you mean?
>
>
[RJ]  Yes. The new mechanism does not depend on previous route link
failures and thus is tolerant. That is what was meant.
We have changed the title of the section since it sounded confusing
(especially the term tolerant). Thank you for pointing it. Please check if
the new title and section rewording makes sense.


>> In section 3.1, 3.2 and 3.3 it should not be necessary to repeat what is
>> written in section 2.1, 2.2 and 2.3, just a reference to the corresponding
>> section will do.
>>
>> [RJ] we have removed duplicate sentences and reworded section 2 heavily.
> [pvds]Quite nice.
>
>> Section 7 is rather short; I doubt that it will be accepted in this form.
>> There have been earlier comments on the insufficiency of the security
>> considerations in RPL documents.
>>
>> [Pvds]You may be inspired by RFC7733, RFC7416 and
>> draft-richardson-roll-applicability-template-02
>> <https://datatracker.ietf.org/doc/draft-richardson-roll-applicability-template/>
>>
>>
>
[RJ] We have updated security considerations based on security
considerations from RFC 6550. I have also gone through 7733, 7416 and the
applicability template for inspiration. I think the applicability documents
security considerations are much different and it talks about key
provisioning/management which i feel are irrelevant for DCO, DCO-ACK. We
have explained the use of secure messaging in
Preinstalled/Authenticated/Unsecured security modes of 6550 for DCO,
DCO-ACK.


>
>> __________________________________________________________________________________
>>
>> Review npdao-06/-07
>>
>> Hi co-author,
>>
>> Thanks for this version that reads much more easily.
>>
>> Please, give the full name at first appearance of the following terms.
>>
>> RPL, 6LBR, 6LR; Otherwise someone from IESG will ask you to do so.
>>
> [RJ] Updated all acronyms regardless of whether they are from base
specification or not,, to improve readability  and completeness.

> Common ancestor node: s/child node/target Node/
>>
> [RJ] Fixed

> Section 1.1 which terms from RFC6550 are used. It is good practice to
>> enumerate them to help the reader, otherwise he wonders for each unknown
>> term where it comes from.
>>
> [RJ] Have enumerated certain terms from 6550 such as DODAG, DAG, 6LBR, 6LR
for improving readability.

> Section 1.2 end: s/BR/6LBR/ to align with earlier text and figure..
>>
> [RJ] Fixed.

> At the end of this section some text about multiple parents is helpful; Do
>> you exclude that possibility? Or does an additional set of parents
>> (foreseen in RFC6550) have no influence? I doubt it.
>>
>> Just read version 07; section 4.4.3 is a statement that needs some
>> explanation to be understood. Also an implementer needs some guidance on
>> what to do; send a NPDAO to all parents, probably not,? Do you need an
>> additional new parent? Send the DCO from all common ancestors on all paths?
>>
> [RJ] There has been a major text update for this. Section 4.4.3 is updated
and an example DCO signalling for multiple preferred parents is added in
appendix (A.2).

> Section 1.3 subtree switching example, suggested text is: needs to be done
>> for the routing table entries of (C), (H), (A), (G), and (B) with
>> destination (D), (E), and (F).
>>
> [RJ] Fixed.

> Section 2.2 suggested text:
>>
>> There is no NPDAO generated by the child nodes (E) and (F), through the
>> previous path via (D) to (B) and (G), resulting…..
>>
> [RJ] Fixed.

> Section 2.3 s/from previous route may invalidate the existing/via previous
>> route may invalidate the previous/
>>
> [RJ] Fixed.

> Sec 3.1 the title mentions “parents” (plural) where the earlier text only
>> considers a single parent
>>
> [RJ] Fixed.

> Sec 4.1; How does a common ancestor know, it is a common ancestor? I am
>> not convinced that a node which has an old entry that specifies a different
>> route is still necessarily a common ancestor. That old path may pass
>> through different nodes; not (G) and (H) to follow the example.
>>
> [RJ] A node which has an old entry that specifies a different route and
has received an updated DAO ... essentially means it is a common ancestor.
If there is any old path, it requires invalidation nonetheless.

> Sec 4.2 /specifies/specify/  ---plural options
>>
> [RJ] Fixed

> Section 4.3 What are the initial values of the attributes of the DCO?.
>>
> [RJ] Have updated DCOSequence initial value consideration. Also for
DCO-ACK the DCOSequence needs to be copied from DCO message. The text has
been updated.

> Learned from the DIO means: copied from last received DIO?
>>
> [RJ] Yes. We have tried using the same statements as with DAO messages in
6550.

> DCOsequence is incremented but it is not clear what its initial value is
>> (same for DCO-ACK)
>>
> [RJ] Fixed as mentioned above

> Suppose the K-flag is set and no ack arrives, after how long a period the
>> sender does what? Under what conditions does the K-flag need to be set?
>>
> [RJ] Have added K-flag handling in the signalling section.

> Section 4.1 Are the dependent nodes the nodes in the subtree introduced in
>> section 1.3? or only the children of the switching node?
>>
> [RJ]  Sorry but I didn't understand this. There is no reference to
dependent nodes or child nodes in section 4.1.

Thanks for the work,
>>
>
[RJ] Thank you for the thorough review.