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

[Peter van der Stok]

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: ***@vanderstok.org, ***@bbhmail.nl
www: www.vanderstok.org [1]
tel NL: [phone] F: [phone]

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

[Rahul Jadhav]

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

Thanks,
Rahul

Post by Peter van der Stok
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.
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
www: www.vanderstok.org
tel NL: [phone] F: [phone]

[Pascal Thubert (pthubert)]

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 <***@gmail.com<mailto:***@gmail.com>> 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 <***@bbhmail.nl<mailto:***@bbhmail.nl>> wrote:
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

[Rahul Jadhav]

Hello Pascal,

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

Best,
Rahul

Post by Pascal Thubert (pthubert)
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.

Post by Pascal Thubert (pthubert)
One last thing could be a bit more details on when to place options and why.

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

Post by Pascal Thubert (pthubert)
Otherwise all good for me!
Pascal
Many thanks Peter for the review. We will work on these comments and
update the draft and provide detailed response soon.
Thanks,
Rahul

Post by Peter van der Stok
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.
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
www: www.vanderstok.org
tel NL: [phone] F: [phone]

[Rahul Jadhav]

Please find responses inline.

Thanks,
Rahul

Post by Peter van der Stok
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.

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

Post by Peter van der Stok
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.

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

Post by Peter van der Stok
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.

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

Post by Peter van der Stok
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.

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

Post by Peter van der Stok
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.

Post by Peter van der Stok
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.
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,
[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.

Post by Peter van der Stok
I hope I conveyed my problems sufficiently, and look forward to a new
version to continue the review.

[Peter van der Stok]

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

Peter

Post by Rahul Jadhav
Please find responses inline.
Thanks,
Rahul
[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.

Post by Peter van der Stok
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.

Post by Peter van der Stok
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?

Post by Peter van der Stok
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.

Post by Peter van der Stok
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).
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/

[Rahul Jadhav]

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

Post by Peter van der Stok
Please find answers to responses and additional review of -06, later
switching to -07
Peter
Please find responses inline.
Thanks,
Rahul
[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.

Post by Peter van der Stok

Post by Peter van der Stok
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.

Post by Peter van der Stok
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.

Post by Peter van der Stok

Post by Peter van der Stok
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.

Post by Peter van der Stok
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.

Post by Peter van der Stok

Post by Peter van der Stok
__________________________________________________________________________________
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.

Post by Peter van der Stok
Common ancestor node: s/child node/target Node/
[RJ] Fixed
Section 1.1 which terms from RFC6550 are used. It is good practice to

Post by Peter van der Stok
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.

Post by Peter van der Stok
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

Post by Peter van der Stok
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).

Post by Peter van der Stok
Section 1.3 subtree switching example, suggested text is: needs to be done

Post by Peter van der Stok
for the routing table entries of (C), (H), (A), (G), and (B) with
destination (D), (E), and (F).

[RJ] Fixed.

Post by Peter van der Stok
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

Post by Peter van der Stok
route may invalidate the previous/

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

Post by Peter van der Stok
considers a single parent

[RJ] Fixed.
Sec 4.1; How does a common ancestor know, it is a common ancestor? I am

Post by Peter van der Stok
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.

Post by Peter van der Stok
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.

Post by Peter van der Stok
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.

Post by Peter van der Stok
DCOsequence is incremented but it is not clear what its initial value is

Post by Peter van der Stok
(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

Post by Peter van der Stok
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

Post by Peter van der Stok
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.

[Peter van der Stok]

Post by Rahul Jadhav
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.
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
Please find answers to responses and additional review of -06, later switching to -07
Peter
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

Post by Rahul Jadhav
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.

Post by Rahul Jadhav
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.

Post by Rahul Jadhav
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.

Post by Rahul Jadhav
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/