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