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

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

Rahul Jadhav schreef op 2018-10-01 07:07:

> Thank you Peter for the thorough review.
> 
> [pvds]My pleasure: I hope it helps implementers; At least for me things are much clearer.
> [pvds] See my last comments below; I will now start on the shepherd document; may take some time.
> Once finished, our AD will look at the documents.
> 
> 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

[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.
[pvds] happy with that 

> 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.
[pvds] I do understand what is meant now. 

> 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]

[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.

[pvds] Treatment is more explicit. I expect that this suffices. However,
there may be questions about what this means for the application. Can
rogue nodes remove paths, and render destinations unreachable? or worse
send to the wrong destinations?

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).
[pvds] less misunderstanding now. 

> 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. 
[pvds] My typing error: I meant section 4.4.1: I assume you mean the
subtree of the switching node 

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