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

["Pascal Thubert (pthubert)" <[e-mail]>]

Many thanks; Sue 😊 

Reviewing this draft is also quite a commendable effort and I really, really appreciate your time. 
This spec makes sense in the general context of RAW and IoT automation over wireless. I hope that its time is coming very soon.
I'll be in PTO till September 1st so (sorry for this) please expect some delay.

All the best!

Pascal

> -----Original Message-----
> From: Susan Hares via Datatracker <[e-mail]>
> Sent: Wednesday, August 23, 2023 11:56 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: Rtgdir last call review of draft-ietf-roll-dao-projection-32
> 
> 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
> 
>