Hello,
I'd like to comment on some mostly editorial problems I see with RPL-11.
Note the following don't affect the protocol itself, messages, or mechanisms
proposed. These comments come from someone who has worked to implement part
of the RPL draft and they DO result in problems implementing the
specification.
#1) Trickle to RPL Interation
The trickle timer is an integral part of RPL, but defined in another draft
(draft-ietf-roll-trickle-04.txt). In that draft section 5 details that "A
protocol specification that uses Trickle MUST specify":
* Default values for Imin, Imax, and k
* What constitutes a "consistent" transmission.
* What constitutes a "inconsistent" transmission
* What "events", if any, besides inconsistent
transmissions that reset the Trickle timer.
However in roll-rpl-11.txt they are not clearly worded as such. Section
8.3.1 details Imin, Imax, and k well. Section 8.3 details the other three,
though does not use the keyword "consistent transmission" or "inconsistent
transmission". RPL-11 also includes a blanket statement which allows
implementers to consider any event a chance to reset the Trickle timer. Such
a blanket statement may give too much flexibility, since it would allow a
node to constantly reset the Trickle timer and yet adhere to the
specification.
#2) Problems in 'Protocol Overview'
The 'protocol overview' section is needlessly convoluted and complex. As a
few examples:
-Section 3.3.7 is called "Datapath Validation and Loop Detection", which has
the same information but written a different way from section 3.8, "Loop
Avoidance". It's not clear why there is two of essentially the same
sections.
-Section 3.8.1 devotes two pages to the description of what greediness is,
how it happens etc. It then mentions that such a condition as just described
could never happen in RPL due to the design. A simple sentence saying that
RPL disallows greediness, and giving a reference for readers to consult if
they want to learn about greediness would be sufficient.
-Objective Function (OF) is defined on page 9, page 14 in a section titled
'Objective Function', then defined again on page 20 (paragraphs 2 & 3).
#3) Complexity of English
This is not a specific concern, but throughout RPL-11 the language used is
very complex and not always consistent. As a few examples:
-'Option Length' is defined for each option, 10 in total I count. Almost
every definition uses some different wording. (Search for "Option Length:"
to see what I mean).
-"Indeed, whereas the OF dictates rules
such as DODAG parents selection, load balancing and so on, the set of
metrics and/or constraints used, and thus determine the preferred
path, are based on the information carried within the DAG container
option in DIO messages."
--Sentence from page 20, paragraph 3. I'm not even sure what that
sentence
should be saying.
-Though the preceding is a particularly bad example, a more common sentence
might be something like this:
" Unfortunately, such
an approach is not desirable in constrained environments such as LLN
and would lead to excessive control traffic in light of the data
traffic with a negative impact on both link loads and nodes
resources."
--Page 100, paragraph 2. Which does make perfect sense, but could easily
be shortened or even removed. By page 100 you probably get the idea that you
don't want to be sending excessive data.
Problems #1/#2 are fairly specific and could be fixed with minor editing.
Problem #3 would essentially require a re-write of the entire draft to use
clearer English throughout. Again this isn't affecting the
protocol/messages, just the language used!
Regards,
-Colin O'Flynn
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf