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

[Rahul Jadhav <[e-mail]>]

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