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

[Peter van der Stok <[e-mail]>]

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 [1]
tel NL: [phone]     F: [phone] 

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