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

From: Peter van der Stok <[email-masked]>
Date: Thu, 06 Sep 2018 15:10:26 +0200

Hi authors,

Many thanks for this work and solving an open important problem.

being the shepherd of this draft, I looked at the text to look for
improvements to facilitate the reading by the IESG.
I found the document difficult to read due to the use of multiple terms
for the same concept.
I would appreciate that the first 3 sections are improved, such that I
can continue the review afterwards without me wondering about my choices
in the interpretation of the text.

For example: is a sub-node the same thing as a child in the node? and
what is a dependent node?
Some suggestions to improve the document are written below.

Can you use, for example, the terms Switching-node (S-node)
After-switching parent (A-parent) and Before-switching parent
(B-parent); that will simplify the text and improve readability.
Please use consistently throughout one DODAG terminology like parent,
child, ancestor or another preferred terminology.
What does "target" mean: an endpoint of a path, a field in a packet, or
the S-node?
I thought that there can be many common ancestors on two paths with same
source and destination, and one of them is the first common ancestor.
BTW is the first one important; The rest of the text does not seem to
rely on it.

In section 1.4; to which what subtree do you refer?

In section 8.2.1 of RFC6550 it is mentioned that there can be a set of
preferred parents.
However, I have the impression that your assumption is the existence of
a single preferred parent, Some explanatory text would help.

Some textual suggestions:
Every first introduction of an acronym must be introduced with the full
name; for example: DAO must be written out both in the abstract as in
the text for the first use; please look for all the first instances in
the text.
In section 1.1 it will help if the list of used terms of RFC6550 is
added.

Section 3; a reminder that this applies only to storing mode may help.

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

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.

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,

I hope I conveyed my problems sufficiently, and look forward to a new
version to continue the review.

All the best,

Peter

-- 
Peter van der Stok
vanderstok consultancy
mailto: [email-masked], [email-masked]
www: www.vanderstok.org [1]
tel NL: +31(0)492474673     F: +33(0)966015248 

Links:
------
[1] http://www.vanderstok.org

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 6 Sep 2018 21:37:12 +0530

Many thanks Peter for the review. We will work on these comments and update
the draft and provide detailed response soon.

Thanks,
Rahul

On Thu, 6 Sep 2018 at 6:40 PM, Peter van der Stok <[email-masked]>
wrote:

> I would appreciate that the first 3 sections are improved, such that I can
> continue the review afterwards without me wondering about my choices in the
> interpretation of the text.
>
> For example: is a sub-node the same thing as a child in the node? and what
> is a dependent node?
> After-switching parent (A-parent) and Before-switching parent (B-parent);
> that will simplify the text and improve readability.
> source and destination, and one of them is the first common ancestor. BTW
> is the first one important; The rest of the text does not seem to rely on
> it.
>
> However, I have the impression that your assumption is the existence of a
> single preferred parent, Some explanatory text would help.
>
> name; for example: DAO must be written out both in the abstract as in the
> text for the first use; please look for all the first instances in the text.
> In section 1.1 it will help if the list of used terms of RFC6550 is added.
>
> written in section 2.1, 2.2 and 2.3, just a reference to the corresponding
> section will do.
>
> Section 7 is rather short; I doubt that it will be accepted in this form.
> www: www.vanderstok.org

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 8 Sep 2018 11:15:59 +0000

Dear all

I made my own review and find the document mostly ready. I agree that Peter’s comments need handling to make the best text cleaner. The introduction could also be tightened and the English improved a bit, but I guess the rfc editor will help us there.

A word on DAO vs. NPDAO with a same sequence would clarify that the DAO is valid and the route installed or kept depending on the order of the 2 messages. A DAO received after a NPDAO but with an older sequence is ignored. This is classical RPL, but mentioning it could still be useful.

One last thing could be a bit more details on when to place options and why.

Otherwise all good for me!

Pascal

Le 6 sept. 2018 à 18:07, Rahul Jadhav <[email-masked]<mailto:[email-masked]>> a écrit :

Many thanks Peter for the review. We will work on these comments and update the draft and provide detailed response soon.

Thanks,
Rahul

On Thu, 6 Sep 2018 at 6:40 PM, Peter van der Stok <[email-masked]<mailto:[email-masked]>> wrote:
Hi authors,

being the shepherd of this draft, I looked at the text to look for improvements to facilitate the reading by the IESG.
I found the document difficult to read due to the use of multiple terms for the same concept.
I would appreciate that the first 3 sections are improved, such that I can continue the review afterwards without me wondering about my choices in the interpretation of the text.

For example: is a sub-node the same thing as a child in the node? and what is a dependent node?
Some suggestions to improve the document are written below.

Can you use, for example, the terms Switching-node (S-node) After-switching parent (A-parent) and Before-switching parent (B-parent); that will simplify the text and improve readability.
Please use consistently throughout one DODAG terminology like parent, child, ancestor or another preferred terminology.
What does "target" mean: an endpoint of a path, a field in a packet, or the S-node?
I thought that there can be many common ancestors on two paths with same source and destination, and one of them is the first common ancestor. BTW is the first one important; The rest of the text does not seem to rely on it.

In section 8.2.1 of RFC6550 it is mentioned that there can be a set of preferred parents.
However, I have the impression that your assumption is the existence of a single preferred parent, Some explanatory text would help.

Some textual suggestions:
Every first introduction of an acronym must be introduced with the full name; for example: DAO must be written out both in the abstract as in the text for the first use; please look for all the first instances in the text.
In section 1.1 it will help if the list of used terms of RFC6550 is added.

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

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.

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,

I hope I conveyed my problems sufficiently, and look forward to a new version to continue the review.

All the best,

Peter

--
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
www: www.vanderstok.org<http://www.vanderstok.org>
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 27 Sep 2018 14:19:10 +0530

Please find responses inline.

Thanks,
Rahul

> Some suggestions to improve the document are written below.

[RJ] We have revisited all such instances and reworded to make the
terminology consistent.

> is the first one important; The rest of the text does not seem to rely on

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

> single preferred parent, Some explanatory text would help.

[RJ] We have added an explicit section "DCO with multiple preferred
parents" to make it explicit.

> Section 3; a reminder that this applies only to storing mode may help.

[RJ] In introduction section we have explicitly added text saying the
technique is applicable for storing MOP only.

> needed here. It would help if the assumptions are listed: like there is

[RJ] Have reworded the para.

> [RJ] we have removed duplicate sentences and reworded section 2 heavily.

> [RJ]: I have changed the wordings here, but i m not sure if there is any
more security considerations that could be added. Is there any other
consideration that is applicable? Would like to get  feedback from WG.

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 27 Sep 2018 14:25:35 +0530

Hello Pascal,

Thank you for the review. Have incorporated your comments and updated the
draft (-07).
Please find my response inline.

Best,
Rahul

On Sat, 8 Sep 2018 at 16:46, Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Dear all
>
> I made my own review and find the document mostly ready. I agree that
> Peter’s comments need handling to make the best text cleaner. The
> introduction could also be tightened and the English improved a bit, but I
> guess the rfc editor will help us there.
>
> A word on DAO vs. NPDAO with a same sequence would clarify that the DAO is
> valid and the route installed or kept depending on the order of the 2
> messages. A DAO received after a NPDAO but with an older sequence is
> ignored. This is classical RPL, but mentioning it could still be useful.
>

[RJ]: Have updated Section 4.3.3 "Path Sequence Number in DCO"   to
explicitly state the sequence number handling.

> One last thing could be a bit more details on when to place options and

[RJ]: Have updated Section 4.2 to explain this.

> Le 6 sept. 2018 à 18:07, Rahul Jadhav <[email-masked]> a écrit :
>
> Many thanks Peter for the review. We will work on these comments and
> update the draft and provide detailed response soon.
>
> Thanks,
> Rahul
>
>> can continue the review afterwards without me wondering about my choices in
>> the interpretation of the text.
>>

---

From: Peter van der Stok <[email-masked]>
Date: Thu, 27 Sep 2018 15:12:20 +0200

Please find answers to responses and additional review of -06, later
switching to -07

Peter
Rahul Jadhav schreef op 2018-09-27 10:49:

> [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 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. 
> 
> [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? 
> 
> [pvds]Quite nice. 
>> 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/

---

From: Rahul Jadhav <[email-masked]>
Date: Mon, 1 Oct 2018 10:37:42 +0530

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 <[email-masked]>
wrote:

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

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

> [RJ] Updated all acronyms regardless of whether they are from base
specification or not,, to improve readability  and completeness.

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

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

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

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

> [RJ] Fixed

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

> [RJ] Yes. We have tried using the same statements as with DAO messages in
6550.

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