Dear Mirja,
Thank you a lot for reading the draft and providing the detailed
comments. I tried to address them in a new version of the draft (07).
Below, I give a brief summary for each these actions.
On 01/03/2025 17:56, Mirja Kühlewind via Datatracker wrote:
Here are my detailed comments:
1) For the transport perspective my understanding is that this extension might
produce additional messages based on the Tickle timer. However, there are no
further recommendations given how to configure this time and especially how to
ensure to not overload the network if the timer is selected way to low.
Particularly, I think this should be further specfied in the following cases:
The recommendations regarding the Trickle timer configuration were added
in the new version of the draft (see also the specific replies below).
Compared to the original RPL, there are no new special measures to avoid
overloading the network with control traffic. Like in the original RPL,
this issue is actually very complex and depends on factors beyond the
network administrator's control. However, if RNFD is even suspected of
being a cause of an overload, it can always be deactivated, as explained
in the draft.
In Section 5.2:
“Internally, in turn, it is
RECOMMENDED that RNFD take action whenever there is a change to its
local CFRCs, so that a node can have a chance to participate in
detecting potential problems even when normally it would not exchange
packets over the link with the DODAG root during some period. “
I not sure what is actually meant by “take action”? Does it mean it should send
additional packets? If so this needs to be better specified, when to send what
and how often…?
No, it means that it may start suspecting that the DODAG root may be
down. This is stated explicitly in the next paragraph.
In Section 5.3:
“It is RECOMMENDED to use for RNFD a dedicated Trickle
timer, different from RPL’s original DIO Trickle timer.”
How is the Trickle timer supposed to be configured?
Good catch. Somehow this information was lacking. The intervals of the
timer should not be smaller than those of the original timer. Added this
explanation after the next sentence.
Section 5.5:
“However, it is RECOMMENDED that it sends sufficiently many
messages with the option to the link-local all-RPL-nodes multicast
IPv6 address to allow its neighbors to learn that RNFD has been
deactivated in the current DODAG version. “
What is sufficiently here? Also it would be important to discuss to not send to
much messages to not overload the network.
The DIO messages with the RNFD option are sent also during a normal
operation of RNFD. What this sentence says is that sending the option
may be stopped when the protocol has been deactivated. What
"sufficiently many" means here is hinted in the second part of the
sentence: enough to give the other nodes a chance to learn about the
deactivation. A more precise definition would be dependent on many
factors, like the underlying L2, and hence was avoided in the document,
and instead some examples are given in the next sentence. If the normal
operation does not overload the network, then neither should not sending
the option.
2) Further I have a question about this sentence:
Section 4.2:
“Finally, if PosCFRC has all its bits equal to 1,
then NegCFRC MUST also have all its bits equal to 1.”
I might be confused but isn’t this sentence the wrong way around?
Per the first sentence of the same paragraph, for any position i, we
always have PosCFRC[i] >= NegCFRC[i], so this may be the source of your
confusion. However, PosCFRC having all bits equal to 1 denotes infinity.
Therefore, to avoid mapping infinity to multiple combinations of the two
CFRCs, it was decided to require all NegCFRC bits to also be equal to 1.
This is the sole purpose of the quoted statement. If it were the other
way around, then it would bring no new information compared to the first
sentence of the same paragraph.
3) Here are a couple of examples where the normative language to very vague,
too unclear, or potentially wrongly used:
In section 5.2.:
“Care SHOULD be taken not to overload the DODAG root with traffic due to
simultaneous probes, …” and “RNFD also MUST make use of RPL’s independent
knowledge.” and “An implementation SHOULD thus try to minimize false-positive
transitions
from “UP” and “SUSPECTED DOWN” to “LOCALLY DOWN”.”
These don’t seems like good use of normative language because it doesn’t
specify a specific protocol action.
Removed the capitalization.
Section 5.4
“ Furthermore, the DODAG root SHOULD either generate a new DODAG
Version or increase the bit length of its CFRCs if
saturated(PositiveCFRC) becomes TRUE.”
Why is this a SHOULD and not a MUST?
If I remember correctly, the reasoning for "SHOULD" and not "MUST" was
that --- for the first option --- RNFD is a supplementary protocol for
RPL, and it is RPL that has a final say whether a new DODAG version will
be generated, and --- for the second option --- dynamically adjusting
bit lengths is not mandatory. If the DODAG root performs none of the two
actions, then the detection abilities of RNFD will degrade.
“The DODAG root MAY thus perform this operation also in other
situations.”
Which situations? This is very unspecific for a normative MAY.
The capital "MAY" was meant to emphasize that, from RNFD's perspective,
performing the action is allowed also in other situations that may be
implementation-specific, and hence beyond RNFD's control. To me a
normative word was better here, but I may be mistaken.
Section 5.5
“However, the
activation and deactivation SHOULD be done at the DODAG root node;
other nodes MUST comply.”
Why is this a SHOULD and not a MUST. And was does “MUST comply” actually mean?
I think the MUSTs should in the following sections are sufficient.
Good catch. It was "SHOULD" because it is hard to verify which node did
the activation. However, the correct behavior is described by "MUST".
Changed.
Section 5.6:
“A node thus MUST be prepared to receive...”
This is also a MUST without clear instruction, or actually the normative
instructions follow later which is sufficient.
Removed the capitalization.
Section 61.:
“In either of the solutions, Sentinel nodes SHOULD preferably be
stable themselves and have stable links to the DODAG root.”
Not sure what this even means or what action this implies.
Removed the capitalization. The sentence describes a desired property of
Sentinels, not any specific action to achieve it.
“Although as a mitigation the number of
such transitions and switches per node MAY be limited, having
Sentinels stable SHOULD be preferred.”
What does the SHOULD here imply?
That an implementation may decide to limit the number of transitions for
a single Sentinel, but that this approach is less preferred compared to
ensuring that the Sentinels are stable.
4) Some smaller editorial notes mainly on the abstract and intro:
I find the first two sentence in the abstract a bit generic and recommend to
actually just remove them. You don’t need a motivation in the abstract for a
protocol spec. Just say straight away what the protocol is about.
I understand your point, but believe that the overhead of two sentences
is acceptable and they have some benefits as well, for instance,
introducing the rest more gently.
Also I actually had to look up the term “by and large”…. again seems that term
is actually not needed and doesn’t help t make anything actually more clear.
Without the term, the rest of the sentence would not be true, that is,
there are cases in which a RPL network can operate without LBRs,
especially just temporarily.
And then even though this doc defines an extension to RPL for me as a
non-expert it was actually not clear what the acronym stands for or what an
“RPL network” is supposed to be. Further I highly recommend you to expand the
acronym RNFD already in the abstract. Also note that the first time this term
is used is in section 1.2 on design principles. I would have expected that the
intro would already early on say that this is the name of the extension
specified in this doc.
Both acronyms, RPL and RNFD, are now expanded in the abstract.
Generally, note that the RFC style guide actually says that the abstract is
usually in part constructed from material in the introduction section (see
https://datatracker.ietf.org/doc/html/rfc7322#section-4.3). Or I would say this
also the other way around, I recommend to also repeat anything you say in the
abstract in the intro to some extend; sometimes this is even done using the
same wording.
The abstract is in fact constructed from the material from the intro,
albeit perhaps using different wording.
And finally on the abstract it say “expedites […] even by an order of
magnitude”, however, compared to what?
To "bare" RPL. However, Éric pointed this as marketing, so the second
part of the statement was removed completely.
One editorial comment on the doc body:
I know this is probably a matter of taste, but I personally find the definition
of zero(), infinity(), and self() not very helpful, rather than just sending in
word, e.g. also bits set to zero.
I assume you are referring to Section 4.1. This section defines the
semantics of the operation for a generic CFRC, so that the reader can
build an intuition what they are all about. Section 4.2, in turn,
explains the operation of the specific CFRC realization, employed by
RNFD, and its description is exactly as you suggest, in particular, for
zero().
Thanks again for the effort you put in this review!
Best regards,
--
- Konrad Iwanicki.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
