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

[Rahul Jadhav <[e-mail]>]

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) <[e-mail]>
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
> why.
>

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


>
> Otherwise all good for me!
>
> Pascal
>
> Le 6 sept. 2018 à 18:07, Rahul Jadhav <[e-mail]> 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 <[e-mail]>
> 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
>>
>>
>> --
>> Peter van der Stok
>> vanderstok consultancy
>> mailto: [e-mail], [e-mail]
>> www: www.vanderstok.org
>> tel NL: [phone]     F: [phone]
>>
>