[Roll] Rtgdir last call review of draft-ietf-roll-dao-projection-32

[Susan Hares via Datatracker <[e-mail]>]

Reviewer: Susan Hares
Review result: Has Issues

Status: Has Issues
Summary:
This specification demonstrates an amazing amount of work.  I commend the
authors for their creativity and their diligence in forging forward on new
concepts in routing. Reasons Not ready: 1) Text in sections 3.4 and 3.5 have
logic gaps that make it difficult to determine if this general discussion is
being implemented in section 7 (using sections 4 and 6) 2) This document
significantly modifies a major specification (RPL) without a prototype
implementation that interoperates with RPL basic.   One example of how this
impacts this document is the profile section.  The profile text has editorial
issues that make it unclear to a reader not involved in writing the text. 3)
Operational details on the two strict rules that prevent looping are unclear in
the text.  One example is the “administrator defining the ordering of the RPL
domain” in section 3.2. The text hints at what the answer might be, but it
seems there are policies.

Proposed resolution of comments:  Place this specification as experimental or
await an implementation.

Text in section 3.4 – Technical and/or editorial
Paragraph 2 starting with “A track” has a “;” that confuses the text.  It is a
critical part of the description of how the encapsulating Source IP address and
RPI instance are set.  The next paragraph jumps into the Track Lane as an
alternative to the segment in the main DODAG. It is important to know if the
longest-best match is being per RPL instance or across all instances to link
the packet to an ingress of a Track Lane or a segment. The last sentence in the
paragraph that starts with “A track lane” is very confusing.  Perhaps the text
makes sense to someone deeply embedded in the RPL community, but it is unclear
from the knowledgeable but unfamiliar reader. Text in section 3.5 – Technical
and/or editorial Editorial: Please place at top of the example which figure you
are using. I assumed figure 6.  Please also indicate that “ in a table
indicates the same value. Issue-1: Section 3.5, paragraph 8, starting with
“Loose sequences of hops” – technical/editorial issue. I cannot find a clear
logic step due to the use of commas.  The problem is I need this logic to walk
through the rest of the text.  Perhaps the authors could provide a bullet point
of what they are trying to say. Issue-2.  Section 3.5.1.2 Format on inner form
in Table 6 in “E if (X !=A), F, or G I think you mean E if (X != A or X !=F or
X != G). If so, please modify.  If not, please change text. This issue repeats.

Issue-3: Section 5.1.3, Table 7 Target entry for P-DAO 2 to B
Why is the entry not “B,C” per your earlier text of  “P-DAO 2 signals A ==> B
to B, C” Issue-4: Section 3.5.1.3, table 9 - E if (X !=A), F, or G I think you
mean E if (X != A or X !=F or X != G). If so, please modify the tabl3e.  If
not, please change section. Issue-5: section 3.5.2.1 Editorial/Technical: a)
What does ND mean? B) What is it preferred that A encapsulations and C
decapsulates? Issue-6: section 3.5.2.2, Table 13, targets, entry for P-DAO 2
Why is the entry not “C, E” since your text states “P-DAO 2 signals A ==> B ==>
C to C, E”? Issue-7: section 3.5.2.3, Table 16, targets, P-DAO 1 to C Why is
the entry not “E” since your text states “P-DAO 1 signals c == > D == > E -to-
E”. Section 4.1 extending RFC 6550, paragraph 3, sentence 3 “In the context of
this specification, the installed route appears as a more specific route to the
Track targets, and the Track Ingress forward packets toward the targets via the
Track using the longest match as normal.” Normal for IP? Normal for RPL IP?
Section 4.1.4 – How are loops prevented in the multicast DAO?  This is not
really clear her or in section 3. Sections 4-7 have error handling, but I am
concerned since I am not an expert in RPL error handling.  I strongly suggest
an independent person RPL experience review this text. I am concerned about
what happens when messages drop in the midst of a switch from one Track lane to
an other or from one segment to another. Section 5 – the concept of lifetime
being “infinity” for 0xFF needs a clear description.  I believe you set to a
value (even 0xFF) and then count down.  If 0xFF is a special value, then it
needs to be specified. Section 6 – Configured values should be carefully
specified rather than stated “A reasonable time” see section 6.6.1 in paragraph
3.
=============
Strictly Editorial issues:
#1 Section 2.3 – missing at least PSE and ARQ.  Please do a search to make sure
you have all the abbreviations.  I ran out of time to do that search.
 Was there a reason you did not provide the original place these terms were
 defined?  Are you assuming that section 1 allows you to skip this step?
#2 Section 2.3.5.5:
This section contains a single run-on sentence with unclear language.   If you
mean that all Serial tracks are created from segments, you could include this
in your definition in 2.4.5.3.  If not, please modify both to indicate what you
mean. New:/Refers to a Segment or a lane that is installed with a single P-DAO
and fully defines a serial Track installed from single Storing Mode Via
Information option (SM-VIO). / #3: Section 3.2, paragraph 8 The two strict
ordering rules would benefit from a numerical list in the order.  Here are
possible text changes for this paragraph: New-1/ The possible forwarding
methods are the following: 1)  to a direct next hop,  2) to an indirect
neighbor via a common neighbor, 3) along a segment, and 4) along a track./
New-2/ A RPL Instance may leverage another instance if and if only if that
other Instance is higher in the order defined by the operator.  Higher
instances [should/must?] be defined as higher if they are farther away from the
main instance. / The text is unclear how the operator will know what the
ordering should be. #3 section 3.3, paragraph 3. Old: /Limiting the packet size
is directly beneficial to the energy budget, but mostly, it reduces the changes
of frame loss and packet fragmentation, which are high detrimental to the LLN
operational.] The sentences should be rewritten as two sentences.  I believe
you are saying: 1) reduces packet size cuts transmission time + reduces frame
loss + packet fragmentation. You are indicating that reasons #2 and #3 are more
important than #1.  Please just state that. Note – after section 4, my
editorial review was brief so I may have missed some of the sentence which use
the “;” in an improper way. #4 section 4.1.1, paragraph 3 starting “This
document Amends” Unless it is clearly specified in standards, then “AMENDS” or
whatever is used. #5  section 4.1.4 to end RAN is an abbreviation that is
widely used.  I suggest you pick another abbreviation: RPLAN