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

[Rahul Jadhav <[e-mail]>]

Please find responses inline.

Thanks,
Rahul

On Thu, 6 Sep 2018 at 18:40, 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.
>

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


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


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



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

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

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


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


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