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 <noreply@xxxxxxxx> > Sent: Wednesday, August 23, 2023 11:56 PM > To: rtg-dir@xxxxxxxx > Cc: draft-ietf-roll-dao-projection.all@xxxxxxxx; last-call@xxxxxxxx; > roll@xxxxxxxx > 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 > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
