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

[Peter van der Stok <[e-mail]>]

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. 
> 
>> 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? 
> 
>> 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 [1] 
>> __________________________________________________________________________________
>> 
>> 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. 
>> 
>> Common ancestor node: s/child node/target Node/ 
>> 
>> 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. 
>> 
>> Section 1.2 end: s/BR/6LBR/ to align with earlier text and figure.. 
>> 
>> 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? 
>> 
>> 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). 
>> 
>> 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….. 
>> 
>> Section 2.3 s/from previous route may invalidate the existing/via previous route may invalidate the previous/ 
>> 
>> Sec 3.1 the title mentions "parents" (plural) where the earlier text only considers a single parent 
>> 
>> 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. 
>> 
>> Sec 4.2 /specifies/specify/  ---plural options 
>> 
>> Section 4.3 What are the initial values of the attributes of the DCO?. 
>> 
>> Learned from the DIO means: copied from last received DIO? 
>> 
>> DCOsequence is incremented but it is not clear what its initial value is (same for DCO-ACK) 
>> 
>> 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? 
>> 
>> 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? Thanks for the work,
>> 
>> hope this helps.
>> When you see that my suggestions are unrelated to the intended text, please consider rephrasing of the text, because the text is apparently unclear.
>> 
>> Greetings,
>> 
>> peter
 

Links:
------
[1]
https://datatracker.ietf.org/doc/draft-richardson-roll-applicability-template/