[Roll] Review of draft-ietf-roll-rnfd-02

[Carles Gomez Montenegro <[e-mail]>]

Dear all,

Please find below my review of draft-ietf-roll-rnfd-02.

(Note: I purposefully did not look at the other review recently made by
S.V.R. Anand, to keep the different views "independent".)

In my opinion, the document is carefully written, and it is also mature.
The document defines functionality which, in my opinion, is very useful.
Please find next some minor comments/suggestions:

- Abstract: probably, the RFC Editor will request to expand the RFND
acronym in the abstract (and perhaps even in the title). Maybe this can be
done already in the current stage.

- Section 1, 1st paragraph: "the main"? Perhaps a "significant challenge"?

- Section 1, 2nd paragraph: "more prone to failures"...? Compared to what?
Perhaps remove "more".

- Section 1.2, 3: what is "the critical path"?

- Section 2. s/is the DODAG/is a DODAG

- Section 2. At this stage, a reader might wonder whether the Acceptor role
has any relationship with being a root's neighbor or not. Feel free to
ignore this comment if the current definition of Acceptor is preferred.

- Section 3. s/is the DODAG root’s/is a DODAG root’s

- Section 3.1. "The same is true for a Sentinel node in states “SUSPECTED
DOWN” and “LOCALLY DOWN”." Perhaps it might be good to add next an explicit
sentence regarding Acceptors?

- Section 3.2. The meaning of "merges" is not clear at this stage. Perhaps
it might be good to add a forward reference to the section where the
"merge" operation is defined?

- Section 3.2.  s/acros/across

- Section 4.2. "Returns TRUE, if more than 63% of the bits in c are equal
to 1, or FALSE, otherwise."  Regarding the 63% ratio, is there any
motivation behind it? For example, any scenario, network topology, etc.,
from which this ratio has been derived? Could it be a configurable
parameter?

- Section 5.1. "RNFD—if active" This is the first, but there are various
instances in the document where some explanatory phrase is inserted between
clauses. In my opinion, a blank space should be inserted before the first
hyphen and after the last hyphen to avoid understanding that e.g. "RNFD-if"
is a term, and so on.

- Section 5.1. "a switch from Sentinel to Acceptor has no preconditions".
Perhaps it might be good to describe any reasons why a node might want to
switch from Sentinel to Acceptor.

- Section 5.2. Is there any maximum amount of time during which LORS can be
in "SUSPECTED DOWN"?

- Section 5.2. I would suggest adding "(see Section 5.1)" after "do this
before the previous conditions 2–4"

- Section 5.3. "It is RECOMMENDED to use for RNFD a dedicated Trickle
timer". What would be the default settings for this dedicated Trickle timer?

- Section 5.5. "The node MUST NOT activate the protocol". What does "the
protocol" refer to?

- Section 5.5. "the protocol SHOULD be active from the moment of the
joining." It may be good to explain reasons or use cases that motivate that
the SHOULD is not a MUST.

- Section 5.6. "MAY reset its Trickle timer". Does this refer to the normal
Trickle timer, or to the RNFD-dedicated one?

- Section 5.8. "The default value of the threshold is 0.12".  "The default
value of the threshold is 0.51". Any reason, or hint on underlying
scenarios these numbers have been derived from?

- Section 5.8. s/increased traffic due suspicion/increased traffic due to
suspicion.

- Just a suggestion: perhaps it might be helpful to add examples regarding
some of the functionality defined in Section 5 (e.g., sections 5.1 and 5.3).

I hope this helps!

Cheers,

Carles