Hello Karen Thanks a million for your deep support on this heavyweight specification!
Please see below > Le 7 mars 2026 à 01:28, Karen Moore <[email protected]> a écrit : > > Hi Pascal, > > Thank you for your in-depth review and detailed reply. We have updated our > files accordingly; please review (the files are below). We also have some > clarifications. > > 1) In Section 2.3, we added “DIO” to the glossary. Is the current ordering > okay, or would you like to list the terms in alphabetical order? Pascal > Please use alphabetical order. > ... > 2) In Section 2.4.3, we removed the quoted text from RFC 9473 and removed RFC > 9473 from the Informative References section (as it is not used elsewhere). > We updated the text as follows. Please let us know if this is agreeable or if > you prefer otherwise. > > Current: > See Section 3.1.1 of [RAW-ARCH] for a longer, more modern definition of path. > Pascal > Perfect > … > 3) We updated the sentences in question to reflect 2 instances of “MUST” as > we think this is clearer, and it matches similar phrasing in Section 6.4.1. > Please let us know of any objections. > > Current: > ... MUST be set to 0 by the sender and MUST be ignored by the receiver ... > Pascal > OK >> 29) <!--[rfced] We note the following variation - "MUST" occurs once in >> the first sentence and twice in the second. May we update the >> latter sentences to reflect two instances of "MUST" for >> consistency and clarity (i.e., update to "MUST be set to 0 by the >> sender and MUST be ignored by the receiver")? >> Original: >> (6 instances) >> ... MUST be set to 0 by the sender and MUST be ignored by the receiver ... >> (4 instances) >> ... MUST be set to 0 by the sender and ignored by the receiver ... >> --> >> Pascal > please use ‘Perhaps’ > > … > 4) We made “ingress” and “egress” lowercase in the running text. Note that > these terms are capitalized in Figures 7, 18, and 19 (per the context, we > left them as is). If you prefer lowercase in the figures, please let us know. > Pascal > Please leave as is > … > 5) Before making these vast changes, we’d like to confirm that each instance > of “Storing Mode” and “Non-Storing Mode” should be preceded by “RPL” and that > “Mode” should be made lowercase. Is that correct? (Updating these terms in > the next edit round should help to make the diff file review a little easier > too.) > Pascal > Hum all things considered I’m happier if we do not proceed with this broad change. Those modes are specific to RPL so RPL is already implicated there > Would this update be correct: "In a Non-Storing mode RPL domain” -> "In a RPL > Non-Storing mode domain” Pascal > Please leave as is. This would not be quite correct > >> RPL Storing Mode vs. Storing Mode >> Pascal > please use ' RPL Storing Mode " > >> f) Regarding "Non-Storing Mode" vs. "Non-Storing Mode of Operation >> (MOP)" and "Non-Storing MOP", should any of the instances below be >> "Non-Storing Mode" or are they correct as is? >> Pascal > they refer to the same thing. When we speak we say "mode", and we >> mean RPL MOP. Please lowercase "mode" or leave the full MOP expanded or not. > > … > 6) Before applying these terminology changes, we would like to confirm that > the following should be updated as shown below. > > a) We will update: > - "P-DAO Request (PDR)” to "P-DAO Request (PDAOReq)” > - all instances of “PDR” to “PDAOReq” > Pascal > Yes > - "P-DAO Request Acknowledgement (PDR-ACK)” to > "P-DAO Request Acknowledgement (PDAOAck)” > - all instances of "PDR-ACK" to “PDAOAck” > Pascal > Yes please > b) Should these field names be updated as well? Any others we may have missed? > > PDRSequence -> PDAOReqSequence > PDR-ACK Status -> PDAOAck Status > Pascal > Yes please > c) Should all of these IANA-related updates be made? > > Registry names: > "Projected DAO Request (PDR) Flags” registry -> "Projected DAO Request > (PDAOReq) Flags" registry > "PDR-ACK Flags” registry -> > 1) "PDAOAck Flags" registry or 2) "P-DAO Request Acknowledgement > (PDAOAck)" registry > "PDR-ACK Acceptance Status Values” registry -> "PDAOAck Acceptance Status > Values" registry > "PDR-ACK Rejection Status Values” registry -> "PDAOAck Rejection Status > Values" registry > > Values: > 0x09: Projected DAO Request (PDR) -> Projected DAO Request (PDAOReq) > 0x0A: PDR-ACK -> P-DAO Request Acknowledgement (PDAOAck) > > 0: PDR-ACK request (K) -> PDAOAck request (K) > > Table titles: > Table 24: Initial PDR Flags -> Initial PDAOReq Flags > Table 27: Initial PDR Flags -> Initial PDAOReq Flags > Table 28: Acceptance Values of the PDR-ACK Status -> PDAOAck Acceptance > Status Values > Table 29: PDR-ACK Rejection Status Values -> PDAOAck Rejection Status Values > Pascal > Yes to all, sorry for not catching the collision earlier! Again many thanks!!! Pascal >> e) We note the following inconsistencies with the companion >> document. Please review and let us know if any changes to this >> document are necessary or if these variations are okay. >> "packet delivery ratio (PDR)" (in draft-ietf-raw-architecture-30) vs. >> "P-DAO Request (PDR)" (in this document) >> Pascal > I suggest we use PDAOReq and PDAOAck in this spec > > > —Files— > > Note that it may be necessary for you to refresh your browser to view the > most recent version. Please review the document carefully to ensure > satisfaction as we do not make changes once it has been published as an RFC. > > Please contact us with any further updates or with your approval of the > document in its current form. We will await approvals from each author prior > to moving forward in the publication process. > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9914.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9914.txt > https://www.rfc-editor.org/authors/rfc9914.pdf > https://www.rfc-editor.org/authors/rfc9914.html > > Diff files showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9914-auth48diff.html > https://www.rfc-editor.org/authors/rfc9914-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9914-diff.html > https://www.rfc-editor.org/authors/rfc9914-rfcdiff.html (side by side) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9914 > > Best regards, > > Karen Moore > RFC Production Center > > >> On Mar 5, 2026, at 6:18 AM, Pascal Thubert via auth48archive >> <[email protected]> wrote: >> Dear Karen, Rebecca, and all: >> Many thanks for this huge piece of work! >> Pascal > Can you please make sure that you align my author snippet of that >> of RFC 9912 ? >> <author initials='P' surname='Thubert' fullname='Pascal Thubert' >> role='editor'> >> <organization>Independent</organization> >> <address> >> <postal> >> <city>Roquefort-les-Pins</city> >> <code>06330</code> >> <country>France</country> >> </postal> >> <email>[email protected]</email> >> </address> >> </author> >> Let's see below: >> Le ven. 27 févr. 2026 à 23:02, <[email protected]> a écrit : >> Authors, >> While reviewing this document during AUTH48, please resolve (as necessary) >> the following questions, which are also in the source file. >> 1) <!--[rfced] Please note that the document title has been updated as >> follows. Abbreviations have been expanded per Section 3.6 of RFC >> 7322 ("RFC Style Guide"). Please review. >> The short title that spans the header of the PDF file has also been >> updated to more closely match the document title. Please let us know >> of any objection. >> Original (document title): >> Root-initiated Routing State in RPL >> Current: >> Root-Initiated Routing State in the Routing Protocol for >> Low-Power and Lossy Networks (RPL) >> ... >> Original (short title): >> DAO Projection >> Current: >> Root-Initiated Routing State in RPL >> --> >> Pascal > OK >> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search. --> >> Pascal > IOT SDN DetNet RAW >> 3) <!-- [rfced] Because this document updates RFCs 6550 and 8138, >> please review the errata reported for RFC 6550 >> (https://www.rfc-editor.org/errata/rfc6550) and RFC 8138 >> (https://www.rfc-editor.org/errata/rfc8138) and let us know >> if you confirm our opinion that none of them are relevant >> to the content of this document. >> --> >> Pascal > I confirm >> 4) <!-- [rfced] We have two questions about the text below. >> First, we believe the intention is to cite RFC 6550 as a >> reference for the term "RPL", so we have updated the text >> accordingly. If that is not correct and you would like to include >> the exact title of RFC 6550 in quote marks instead, please let us >> know. >> Pascal > Good >> Second, would using "as opposed to" rather than "versus" be more clear >> in this context? Note that we included parentheses around the phrase >> starting with "versus" to improve readability of this long sentence. >> Original: >> RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] >> (LLNs), is a Distance Vector protocol, which is well-suited for >> application in a variety of low energy Internet of Things (IoT) >> networks where constrained nodes cannot maintain the full view of the >> topology, and stretched P2P paths are acceptable vs. the signaling >> and state overhead involved in maintaining the shortest paths across. >> Current: >> The Routing Protocol for Low Power and Lossy Networks (RPL) [RPL] >> is a Distance Vector protocol that is well-suited for application >> in a variety of low-energy Internet of Things (IoT) networks where >> constrained nodes cannot maintain the full view of the topology >> and stretched P2P paths are acceptable (versus the signaling and >> state overhead involved in maintaining the shortest paths across). >> Perhaps: >> The Routing Protocol for Low Power and Lossy Networks (RPL) [RPL] >> is a Distance Vector protocol that is well-suited for application >> in a variety of low-energy Internet of Things (IoT) networks where >> constrained nodes cannot maintain the full view of the topology >> and stretched P2P paths are acceptable (as opposed to the signaling and >> state overhead involved in maintaining the shortest paths across). >> --> >> Pascal > please use 'perhaps' >> 5) <!-- [rfced] Section 2.2 is titled "References". This may cause >> confusion with Section 13, which is also titled "References". >> Would you like to title Section 2.2 as "Terms and Concepts" or >> other for clarity? >> Original: >> 2.2 References >> Perhaps: >> 2.2 Terms and Concepts >> --> >> Pascal > please use 'perhaps' >> 6) <!-- [rfced] To improve readability, may we update this text to be an >> unordered list? >> Original: >> In this document, readers will encounter terms and concepts that are >> discussed in the "Routing Protocol for Low Power and Lossy Networks" >> [RPL], the "6TiSCH Architecture" [RFC9030], the "Deterministic >> Networking Architecture" [RFC8655], the "Using RPI Option Type, >> Routing Header for Source Routes, and IP-in-IP Encapsulation in the >> RPL Data Plane" [RFC9008], the "Reliable and Available Wireless (RAW) >> Architecture" [RAW-ARCHI], and "Terminology in Low power And Lossy >> Networks" [RFC7102]. >> Perhaps: >> In this document, readers will encounter terms and concepts that are >> discussed in the following: >> * "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RPL] >> * "An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode >> of IEEE 802.15.4 (6TiSCH)" [RFC9030] >> * "Deterministic Networking Architecture" [RFC8655] >> * "Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 >> Encapsulation in the RPL Data Plane" [RFC9008] >> * "Reliable and Available Wireless (RAW) Architecture" [RAW-ARCH] >> * "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102] >> --> >> Pascal > please use 'perhaps' >> 7) <!-- [rfced] Please clarify "to take the routing decision". Is the >> intended meaning "in order to make the routing decision"? >> Original: >> This requires additional control to take the routing decision >> early enough along the Track to route around the failure. >> Perhaps: >> This requires additional control in order to make the routing >> decision early enough along the Track to route around the >> failure. >> --> >> Pascal > please use 'perhaps' >> 8) <!--[rfced] Questions related to the Glossary >> a) Should "DIO" be included in this glossary since SIO, TIO, and VIO are >> listed? >> Pascal > yes >> b) FYI: We updated the expansions/descriptions of "NSM-VIO" and >> "SM-VIO" for consistency with the other entries (i.e., expansion first >> and then the description). Please let us know of any objection. >> Pascal > Good >> Also, is "Strict" VIO" correct, or should it be "Stateful VIO" per Table 26? >> Original: >> NSM-VIO: A Source-Routed Via Information Option, used in Non-Storing Mode >> P-DAO messages >> SM-VIO: A strict Via Information Option, used in Storing Mode P-DAO >> messages >> Current: >> NSM-VIO: Non-Storing Mode Via Information Option. Source-routed >> VIO used in Non-Storing Mode P-DAO messages. >> SM-VIO: Storing Mode Via Information Option. Strict VIO used >> in Storing Mode P-DAO messages. >> Pascal > Both strict and stateful are correct. please leave as is >> c) FYI: For consistency, we removed a few instances of "RPL" and "IPv6" as >> they >> were not a part of the expansions. >> Pascal > OK >> --> >> 9) <!-- [rfced] Section 2.4.3. The definition of "path" has changed since >> [I-D.irtf-panrg-path-properties] was published as RFC 9473. See Section 2 >> of RFC 9473 (https://www.rfc-editor.org/rfc/rfc9473.html#name-terminology) >> and let us know if we may update this document to match RFC 9473. >> Pascal > Please replace by a reference to RFC 9912: Reliable and Available >> Wireless (RAW) Architecture section 3.3.1 since we appear to duplicate the >> definition text >> Current: >> Section 2 of [I-D.irtf-panrg-path-properties] points to a longer, >> more modern definition of path, which begins as follows: >> | A sequence of adjacent path elements over which a packet can be >> | transmitted, starting and ending with a node. A path is >> | unidirectional. Paths are time-dependent, i.e., the sequence of >> | path elements over which packets are sent from one node to another >> | may change. A path is defined between two nodes. >> Perhaps: >> Section 2 of [RFC9473] points to a longer, more modern definition of >> path: >> | A sequence of adjacent path elements over which a packet can >> | be transmitted, starting and ending with a node. >> | >> | Paths are unidirectional and time dependent, i.e., there can be a >> | variety of paths from one node to another, and the path over which >> | packets are transmitted may change. A path definition can be >> | strict (i.e., the exact sequence of path elements remains the >> | same) or loose (i.e., the start and end node remain the same, but >> | the path elements between them may vary over time). >> --> >> 10) <!--[rfced] We are having trouble parsing this sentence. Should "and" >> be "versus" (i.e., the RPL does not behave the same way "downwards" >> versus "upwards")? If not, please let us know how we may update for >> clarity. >> Original: >> RPL does not behave the same way "downwards" (root towards >> leaves) with _multicast_ DIO messages that form the DODAG and >> "upwards" (leaves towards root) with _unicast_ DAO messages that >> follow the DODAG. >> Perhaps: >> RPL does not behave the same way "downwards" (root towards leaves) >> with _multicast_ DODAG Information Object (DIO) messages that form >> the DODAG versus "upwards" (leaves towards root) with _unicast_ DAO >> messages that follow the DODAG. >> --> >> Pascal > please use 'perhaps' >> 11) <!--[rfced] FYI: For Figure 1, we moved the information about the >> segments and paths out of the figure. Please review and let us >> know any concerns. >> --> >> Pascal > good >> 12) <!-- [rfced] How may we clarify what "and" is connecting in this >> sentence? >> Original: >> To reach this goal, RPL is primarily designed to minimize the control >> plane activity, that is the relative amount of routing protocol >> exchanges vs. data traffic, and the amount of state that is >> maintained in each node. >> Perhaps A: >> To reach this goal, RPL is primarily designed to minimize the control >> plane activity (i.e., the relative amount of routing protocol >> exchanges versus data traffic) and the amount of state that is >> maintained in each node. >> or >> Perhaps B: >> To reach this goal, RPL is primarily designed to minimize the control >> plane activity (i.e., the relative amount of routing protocol >> exchanges versus data traffic and the amount of state that is >> maintained in each node). >> --> >> Pascal > please use 'perhaps A' >> 13) <!--[rfced] Does "upon traffic" mean "upon receiving traffic"? >> Current: >> The maintenance is lazy, either reactive upon traffic or as >> slow background process. >> Perhaps: >> The maintenance is lazy; it is either reactive upon receiving >> traffic or a slow background process. >> --> >> Pascal > please use 'perhaps' >> 14) <!--[rfced] Does "join the dots" mean "connect" in these sentences? In >> the second sentence, are Storing Mode P-Routes deployed to >> connect segments to the Track Instance? >> Original: >> In the simplest mode of this specification, Storing-Mode P-Routes >> can be deployed to join the dots of a loose source routing header >> (SRH) in the main DODAG. >> Perhaps: >> In the simplest mode of this specification, Storing Mode P-Routes >> can be deployed to connect a loose SRH in the main DODAG. >> ... >> Original: >> As for the main DODAG, segments associated to the Track >> Instance may be deployed to join the dots using Storing-Mode >> P-Routes. >> Perhaps: >> As for the main DODAG, Storing Mode P-Routes may be deployed to >> connect segments to the Track Instance. >> --> >> Pascal > "join the dots of" means "complete the path between". >> Original: >> In the simplest mode of this specification, Storing-Mode P-Routes >> can be deployed to join the dots of a loose source routing header >> (SRH) in the main DODAG. >> Proposed: >> In the simplest mode of this specification, Storing-Mode P-Routes >> can be deployed to complete the path between the hops described in the >> loose source routing header >> (SRH) in the main DODAG. >> ... >> Original: >> As for the main DODAG, segments associated to the Track >> Instance may be deployed to join the dots using Storing-Mode >> P-Routes. >> Proposed: >> As for the main DODAG, segments associated to the Track >> Instance may be deployed to establish the complete path between loose >> Source-Routing hops using segments expressed as Storing-Mode >> P-Routes. >> 15) <!-- [rfced] Should "The first and strict order" and "The second strict >> and >> partial order" be updated as follows to "The first strict order" and "The >> second strict order", respectively? >> Original: >> The first and strict order relates to the forwarding method and the >> more specifically the origin of the information used in the next-hop >> computation. >> ... >> The second strict and partial order is between RPL Instances. >> Perhaps: >> The first strict order relates to the forwarding method and, more >> specifically, the origin of the information used in the next-hop >> computation. >> ... >> The second strict order is between RPL Instances. >> --> >> Pascal > please retain the original text for the second. Strict means < as >> opposed to <= . Partial means that not all are compared. >> Proposed: >> The first order is strict and complete, and relates to the forwarding >> method and, more >> specifically, the origin of the information used in the next-hop >> computation. >> ... >> The second order is strict and partial, and applies between RPL Instances. >> 16) <!--[rfced] We are having trouble parsing this sentence. Please >> clarify what defines a DODAG of underlays with the main Instance >> as the Root. >> Original: >> That order must be defined by the administrator for the RPL domain >> and defines a DODAG of underlays with the main Instance as Root. >> --> >> Pascal > >> Proposed: >> That order must be defined by the administrator for the RPL domain >> and defines a DODAG of underlay RPL instances with the main Instance as >> Root. >> 17) <!--[rfced] Please clarify what "it" refers to in "When it is not >> communicated". >> Original: >> When it is not communicated, the RPL nodes consider by default >> that all Track instances are children of the main instance, and >> they do not attempt to validate the order for nested Tracks, >> trusting the PCE implicitly. >> --> >> Pascal > "it" refers to "the DODAG of underlay instances", which is >> optionally provided >> Proposed: >> When the DODAG of underlay instances is not provided, the RPL nodes >> consider by default >> that all Track instances are children of the main instance, and >> they do not attempt to validate the order for nested Tracks, >> trusting the PCE implicitly. >> 18) <!-- [rfced] Is "coma-" here is correct? Should this be updated to >> "comma-" or >> something else? >> Original: >> We use "-to-", such as in C==>D==>E-to-F to represent >> coma-separated Targets, e.g., F is a Target for segment C==>D==>E. >> --> >> Pascal > please use "comma-" >> 19) <!--[rfced] We note that several of the tables have the same title; >> will this be confusing for readers? For instance, Tables 3, 6, 9, >> 15, 18, 19, and 20 are all titled "Packet Header Settings". >> Would you like to make these titles more descriptive like Table >> 12, which is titled "Packet Header Settings Between C and E"? If >> so, please provide the wording. If not, should the title of Table 12 >> be updated for consistency with the other titles (i.e., update >> as "Packet Header Settings")? >> Note that Tables 2, 5, 8, 11, 14, and 17 are all titled "RIB Settings", >> and Tables 1, 4, 7, 10, 13, and 16 are all titled "P-DAO Messages". >> --> >> Pascal > I'd leave as is. Michael ? >> 20) <!--[rfced] Please clarify the meaning of "participates to" in the >> following sentence. >> Current: >> Two protection paths of the same Track may cross at a common node >> that participates to a segment of each protection path or that >> may be joined by additional segments. >> --> >> Pascal> >> Proposed: >> Two protection paths of the same Track may cross at a common node >> that is a member of a segment of each protection path or >> may be joined by additional segments. >> 21) <!--[rfced] The following text is difficult to read. May we add >> parentheses as shown below for clarity? >> Original: >> Note that while this specification enables building both segments >> inside a protection path, for instance segment 2 above which is >> within protection path 1, and Inter-protection-path segments (i.e., >> North-South), for instance segment 5 above which joins protection >> path 1 and protection path 2, it does not signal to the Ingress which >> Inter-protection-path segments are available, so the use of North- >> South segments and associated path redundancy functions is currently >> limited. >> Perhaps: >> Note that while this specification enables building both segments >> inside a protection path, for instance, segment 2 above (which is >> within protection path 1) and Inter-protection-path segments (i.e., >> North-South) such as segment 5 above (which joins protection paths >> 1 and 2), it does not signal which Inter-protection-path segments >> are available to the Ingress, so the use of North-South segments >> and associated path redundancy functions is currently limited. >> --> >> Pascal > yes please >> 22) <!-- [rfced] Please clarify this section title. We are unsure what >> "Positioning" refers to. In addition, not all of the RFCs mentioned in >> the section are Standards Track documents, so another term like >> "Specifications" is more accurate. >> Original: >> 3.7.2. Positioning vs. Related IETF Standards >> Perhaps A: >> 3.7.2. Related IETF Specifications >> or >> Perhaps B: >> 3.7.2. Relationship to Other IETF Specifications >> --> >> Pascal > please use 'perhaps B' >> 23) <!--[rfced] Does "In that case" refer to when the PCE is collocated >> with the Root or when it resides in an external controller? What >> does "one possibility" refer to? >> Original: >> The PCE may be collocated with the Root, or may reside in an >> external Controller. In that case, the protocol between the Root >> and the PCE is out of scope and mapped to RPL inside the DODAG; one >> possibility is for the Root to transmit to the PCEs the information >> it received in RPL DAOs including all the SIOs that detail the >> parent/child and sibling information. >> --> >> Pascal > the latter case, external. "One possibility" means "One possible >> control protocol between the root and the external PCE" >> 24) <!--[rfced] May we revise this text to be two sentences to improve >> readability? >> Original: >> The RAW Architecture [RAW-ARCHI] extends the definition of Track, >> as being composed of forward directional segments and North-South >> bidirectional segments, to enable additional path diversity, using >> Packet ARQ, Replication, Elimination, and Overhearing (PAREO) >> functions over the available paths, to provide a dynamic balance >> between the reliability and availability requirements of the flows >> and the need to conserve energy and spectrum. >> Perhaps: >> The RAW architecture [RAW-ARCH] extends the definition of Track as >> being composed of forward directional segments and North-South >> bidirectional segments to enable additional path diversity using >> PAREO functions over the available paths. This provides a dynamic >> balance between the reliability and availability requirements of >> the flows and the need to conserve energy and spectrum. >> --> >> Pascal > We finally abandoned the term PAREO in RFC 9912. Please use PREOF >> instead. and replace references to PAREO The text above becomes: >> " >> The RAW architecture [RAW-ARCH] extends the definition of Track as >> being composed of forward directional segments and North-South >> bidirectional segments to enable additional path diversity using >> PREOF functions over the available paths. This provides a dynamic >> balance between the reliability and availability requirements of >> the flows and the need to conserve energy and spectrum. >> " >> 25) <!-- [rfced] Should the title of this section include "Amending" as the >> section discusses how this document both "Extends" and "Amends"? Or is >> the current okay? >> Current >> 4. Extending Existing RFCs >> Perhaps: >> 4. Extending and Amending Existing RFCs >> --> >> Pascal > please use 'Perhaps' >> 26) <!--[rfced] Is "participate" the intended word or would "function" be >> clearer/correct? >> Original: >> Those 6LRs will be unable to participate in the new mechanisms, >> but may also cause projected DAOs to be impossible to install. >> Perhaps: >> Those 6LRs will be unable to function in the new mechanisms >> and may also make the P-DAOs impossible to install. >> --> >> Pascal > please use 'Perhaps' >> 27) <!--[rfced] The titles of Sections 4.1, 4.2, and 4.3 do not parse. How >> may we update this for clarity? Is "RPL" necessary to include? >> Original: >> 4.1. Extending RPL RFC 6550 >> 4.2 Extending RPL RFC 6553 >> 4.3 Extending RPL RFC 8138 >> Perhaps: >> 4.1. Extending RFC 6550 >> 4.2 Extending RFC 6553 >> 4.3 Extending RFC 8138 >> --> >> Pascal > please use 'Perhaps' >> 28) <!--[rfced] Does "it" refer to the DAO? If so, may we rephrase the >> text as shown below for clarity? >> Original: >> The P-DAO message generalizes the DAO to signal to the Track >> Ingress that a Track for which it is the Root can be used to >> reach children and siblings of the Track Egress. >> Perhaps: >> The P-DAO message generalizes the DAO to signal the Track Ingress >> that a track, for which the DAO is the root, can be used to reach >> children and siblings of the Track Egress. >> --> >> Pascal > please use: >> " >> The P-DAO message generalizes the DAO to signal the Track Ingress >> that a track, for which the sender is the root, can be used to reach >> children and siblings of the Track Egress. >> " >> 29) <!--[rfced] We note the following variation - "MUST" occurs once in >> the first sentence and twice in the second. May we update the >> latter sentences to reflect two instances of "MUST" for >> consistency and clarity (i.e., update to "MUST be set to 0 by the >> sender and MUST be ignored by the receiver")? >> Original: >> (6 instances) >> ... MUST be set to 0 by the sender and MUST be ignored by the receiver ... >> (4 instances) >> ... MUST be set to 0 by the sender and ignored by the receiver ... >> --> >> Pascal > please use 'Perhaps' >> 30) <!--[rfced] FYI: We updated this sentence for clarity. Please let us >> know of any objection. >> Original: >> The SRH-6LoRH is signaled in the NSM-VIO, in a fashion that it is ready >> to be placed as is in the packet encapsulation by the Track Ingress. >> Perhaps: >> When the SRH-6LoRH is signaled in the NSM-VIO, it is ready to be >> placed as is in the packet encapsulation by the Track Ingress. >> --> >> Pascal: When is already present at the beginning of the paragraph . Please >> use >> " >> In that case, the SRH-6LoRH is signaled in the NSM-VIO, and it is expressed >> in a fashion that can be placed as is in the packet encapsulation by the >> Track Ingress. >> " >> 31) <!--[rfced] FYI: We updated "Type" to "6LoRH Type" in Section 4.3 to >> match the >> name of the field in Figure 12. Please let us know if that is incorrect. >> Original: >> Type: IANA is requested to define the same value of the type for >> both Elective and Critical forms. A type of 8 is suggested. >> Current: >> 6LoRH Type: IANA has defined the value 8 >> for both the Elective and Critical forms. >> --> >> Pascal > please use 'Perhaps' >> 32) <!--[rfced] Please clarify "sets up the new information" in this >> sentence. >> Original: >> The segment information indicated in the VIO deprecates any state >> for the segment indicated by the P-RouteID within the indicated >> Track and sets up the new information. >> --> >> Pascal > please replace >> OLD >> ' sets up the new information ' >> with >> NEW >> ' provides the new information about the segment ' >> 33) <!--[rfced] Is "so the routing can consider" the intending wording >> or would one of the following suggestions be more clear? >> Original: >> The SIO carries a flag (B) that is set when similar performance can be >> expected in both directions, so the routing can consider that the >> information provided for one direction is valid for both. >> Perhaps A: >> The SIO carries a flag (B) that is set when similar performance can >> be expected in both directions, so the routing can identify that >> the information provided for one direction is valid for both. >> or >> Perhaps B: >> The SIO carries a flag (B) that is set when similar performance can >> be expected in both directions; this flag indicates to the routing that >> the information provided for one direction is valid for both. >> --> >> Pascal > please use 'Perhaps B' >> 34) <!--[rfced] We note "Type" in Figure 17 but "Option Type" in the >> corresponding description in the running text. Should Figure 17 >> be updated to reflect "Option Type" for consistency with the >> running text? >> Current: >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Option Length |S|B|Flags|Comp.| Opaque | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Option Type: 0x11 for SIO (see Table 26). >> Perhaps: >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Option Type | Option Length |S|B|Flags|Comp.| Opaque | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Option Type: 0x11 for SIO (see Table 26). >> --> >> Pascal > please use 'Perhaps' >> 35) <!--[rfced] Should "MUST" be added to the latter part of this sentence >> (e.g., a P-DAO "MUST signal the full list of hops")? This would >> make it parallel with the first part of the sentence. >> Original: >> A P-DAO that creates a new Track segment MUST be sent to a GUA or a >> ULA of the segment Egress and MUST signal the full list of hops in >> segment; a P-DAO that updates (including deletes) a section of a >> segment MUST be sent to the first node after the modified segment and >> signal the full list of hops in the section starting at the node that >> immediately precedes the modified section. >> Perhaps: >> A P-DAO that creates a new Track segment MUST be sent to a GUA or a >> ULA of the segment Egress and MUST signal the full list of hops in >> a segment; a P-DAO that updates (including deletes) a section of a >> segment MUST be sent to the first node after the modified segment and >> MUST signal the full list of hops in the section starting at the node >> that immediately precedes the modified section. >> --> >> Pascal > earlier you eliminated the second MUST making it a common factor. >> Following that logic you could do: >> " A P-DAO that creates a new Track segment MUST be sent to a GUA or a >> ULA of the segment Egress and signal the full list of hops in >> segment; a P-DAO that updates (including deletes) a section of a >> segment MUST be sent to the first node after the modified segment and >> signal the full list of hops in the section starting at the node that >> immediately precedes the modified section >> " >> Either that or 'Perhaps' work for me. >> 36) <!-- [rfced] Figure 19 contains the non-ASCII character "°". Is this >> intentional/significant? Or should it be updated to "o", which is used in >> the rest of the figure? >> --> >> Pascal > it is not significant. It is just for visualization to show >> different devices. Your call on this. >> 37) <!--[rfced] Is "and results in" the intended wording here, or may we >> revise the sentence as shown below and use "Its function" instead >> for clarity? >> Original: >> A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and results in >> cleaning up existing state as opposed to refreshing an existing one or >> installing a new one. >> Perhaps: >> A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO. Its >> function is to clean up an existing state as opposed to refreshing it >> or installing a new one. >> --> >> Pascal > please use 'Perhaps' >> 38) <!--[rfced] In Section 6.7, we rephrased the second bullet point in >> order to connect it more clearly to the lead-in sentence. Please >> let us know if the update is agreeable or if you prefer otherwise. >> Original: >> * The preferred alternative in a network where 6LoWPAN Header >> Compression [RFC6282] is used is to leverage "IPv6 over Low-Power >> Wireless Personal Area Network (6LoWPAN) Paging Dispatch" >> [RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. >> Current: >> * To compress RPL artifacts in data packets as indicated in >> [RFC8138], the preferred alternative in a network where 6LoWPAN >> header compression [RFC6282] is used is to implement the method >> described in "IPv6 over Low-Power Wireless Personal Area Network >> (6LoWPAN) Paging Dispatch" [RFC8025]. >> --> >> Pascal > Please retain the original. Or a mix like >> " >> * In a network where 6LoWPAN Header Compression [RFC6282] is in use, >> it is preferred to implement "IPv6 over Low-Power >> Wireless Personal Area Network (6LoWPAN) Paging Dispatch" >> [RFC8025] and compress the RPL artifacts as indicated in [RFC8138]. >> " >> 39) <!--[rfced] May we update this sentence as shown below for clarity and >> easier readability? >> Original: >> The packet processing uses a precedence that favors self delivery >> or routing header handling when one is present, then delivery to >> direct neighbors, then to indirect neighbors, then routing along a >> segment along the Track, and finally as a last resort injecting the >> packet in another Track. >> Perhaps: >> Packet processing uses the following precedence: 1) self-delivery >> or routing header handling when one is present, 2) delivery to >> direct neighbors, 3) delivery to indirect neighbors, 4) routing >> along a segment along the Track, and 5) injecting the packet in >> another Track, as a last resort. >> --> >> Pascal > please use 'Perhaps' >> 40) <!-- [rfced] Will "either of the reasons above" be clear to readers? >> Does this >> mean "in any of the steps above"? >> Original: >> The node that drops a packet for either of the reasons above MUST >> send an ICMPv6 Error message [RFC4443] to the Root, with a new Code >> "Error in P-Route" (See Section 11.15). >> Perhaps: >> The node that drops a packet in any of the steps above MUST >> send an ICMPv6 Error message [RFC4443] to the Root, with a new Code >> "Error in P-Route" (See Section 11.15). >> --> >> Pascal > please use 'Perhaps' >> 41) <!--[rfced] May we revise this text into two sentences for easier >> readability and update "remove the leftover" to "the Root can >> remove the leftover" for clarity? >> Original: >> The Root can then repair by updating the broken segment and/or >> Tracks, and in the case of a broken segment, remove the leftover >> sections of the segment using SM-VIOs with a lifetime of 0 >> indicating the section to one or more nodes being removed (See >> Section 6.6). >> Perhaps: >> The Root can then repair by updating the broken segment and/or >> Tracks. In the case of a broken segment, the Root can remove the >> leftover sections of the segment using SM-VIOs with a lifetime of >> 0, indicating the section where one or more nodes are being removed >> (see Section 6.6). >> --> >> Pascal > please use >> " >> The Root can then repair by updating the broken segment and/or >> Tracks. In the case of a broken segment, the Root removes the >> leftover sections of the segment using SM-VIOs with a lifetime of >> 0, indicating the section where one or more nodes are being removed >> (see Section 6.6). >> " >> 42) <!--[rfced] We find "using [RFC8138] in the main DODAG" unclear. >> Please clarify what is being applied from RFC 8138 in the main >> DODAG. >> Original: >> When using [RFC8138] in the main DODAG operated in Non-Storing Mode >> in a 6LoWPAN LLN, a typical packet that circulates in the main DODAG >> is formatted as shown in Figure 20, representing the case where an >> IP-in-IP encapsulation is needed (see Table 19 of [RFC9008]): >> --> >> Pascal > please use >> " >> When the main DODAG in a 6LoWPAN LLN is operated in Non-Storing Mode and the >> data packets are compressed using [RFC8138, a typical packet that >> circulates in the main DODAG >> is formatted as shown in Figure 20, representing the case where an >> IP-in-IP encapsulation is needed (see Table 19 of [RFC9008]): >> " >> 43) <!--[rfced] This sentence is hard to parse. Please let us know if the >> suggested update captures the intended meaning or if you prefer >> otherwise. >> Original: >> At the head of the resulting sequence of bytes, the track Ingress >> then adds the RPI that carries the TrackID as RPLinstanceID as a P- >> RPI-6LoRH Header, as illustrated in Figure 12, using the TrackID as >> RPLInstanceID. >> Perhaps: >> At the head of the resulting sequence of bytes, the Track Ingress >> then adds the RPI that carries the P-RPI-6LoRH Header (as >> illustrated in Figure 12) and uses the TrackID as the RPLInstanceID. >> --> >> Pascal > please use >> " >> At the head of the resulting sequence of bytes, the track Ingress then adds >> a P-RPI-6LoRH Header to transport the RPI in its compressed form as >> illustrated in Figure 12. The RPI carries the TrackID as RPLinstanceID. >> " >> 44) <!--[rfced] Please clarify "at the expense of". Does this mean that >> route stretch is used rather than the shortest path routes? >> Original: >> RPL requires less resources than alternative IGPs like OSPF, ISIS, >> EIGRP, BABEL or RIP at the expense of a route stretch vs. the >> shortest path routes to a destination that those protocols compute. >> Perhaps: >> RPL requires fewer resources than alternative IGPs such as OSPF, IS-IS, >> the Enhanced Interior Gateway Routing Protocol (EIGRP), BABEL, or RIP >> when using route stretch rather than the shortest path routes to a >> destination that those protocols compute. >> --> >> Pascal > please use 'Perhaps' >> 45) <!--[rfced] Is "ANIMA" needed in this sentence or can it be removed or >> replaced with the title of RFC 8994? We note that the title of >> RFC 8994 is "An Autonomic Control Plane (ACP)", so we are not >> sure how "ANIMA" relates as it is not mentioned in Appendix >> A.9.4. >> Current: >> P-Routes add the capability to install shortest and/or constrained >> routes to special destinations such as discussed in Appendix A.9.4 >> of the ANIMA ACP [RFC8994]. >> Perhaps A: >> P-Routes add the capability to install the shortest and/or constrained >> routes to special destinations as discussed in Appendix A.9.4 >> of [RFC8994]. >> or >> Perhaps B: >> P-Routes add the capability to install the shortest and/or constrained >> routes to special destinations as discussed in Appendix A.9.4 of >> "An Autonomic Control Plane (ACP)" [RFC8994]. >> --> >> Pascal > please use 'Perhaps B' >> 46) <!--[rfced] Does "is that of" mean "a part of"? And does the Ingress >> node encapsulate the RPL Instance or the main DODAG? >> Original: >> The RPL Instance is that of the main DODAG, and the Ingress >> node that encapsulates is not the Root. >> Perhaps: >> The RPL Instance is a part of the main DODAG, and the Ingress >> node that encapsulates the RPL Instance is not the Root. >> --> >> Pascal > please use >> ' >> The RPL Instance is the one that runs the main DODAG, and the Ingress >> node that encapsulates the RPL Instance is not the Root. >> ' >> 47) <!--[rfced] How may we clarify "an order other than that of"? Is the >> intended meaning that the PLR's metrics are in a different order >> than the PCE's metrics? >> Original: >> The expectation is that the metrics that the PLR uses are of an >> order other than that of the PCE, because of the difference of >> time scale between routing and forwarding, more in [RAW-ARCHI]. >> Perhaps: >> The expectation is that the PLR's metrics will be in a different order >> than the PCE's metrics because of the difference in the timescale >> between routing and forwarding; see more in [RAW-ARCH]. >> --> >> Pascal > please use 'Perhaps' >> 48) <!--[rfced] Is "Target/Transit information tuples" correct, or should >> it be "Target/TIO tuples" for consistency? >> Original: >> Note that the Path Sequence and Lifetime in the TIO are selected by >> the Root and that the Target/Transit information tuples in the >> P-DAO are not those received by the Root in the DAO messages about >> the said Targets. >> Perhaps: >> Note that the Path Sequence and Lifetime in the TIO are selected by >> the Root and that the Target/TIO tuples in the P-DAO are not those >> received by the Root in the DAO messages about the said Targets. >> --> >> Pascal > please retain the original >> 49) <!--[rfced] Can these sentences be combined to reduce redundancy? >> Original: >> This section describes profiles that can be implemented separately >> and can be used to discriminate what an implementation can and cannot >> do. This section describes profiles that enable implementing only a >> portion of this specification to meet a particular use case. >> Perhaps: >> This section describes profiles that can be implemented separately, >> e.g., using only a portion of this specification to meet a particular use >> case, and can be used to discriminate what an implementation can >> and cannot do. >> --> >> Pascal > please use 'Perhaps' >> 50) <!--[rfced] Please clarify what "its" is referring to in the >> following. >> Original: >> Profile 3 and above leverage Local RPL Instances to build arbitrary >> Tracks Rooted at the Track Ingress and using its namespace for >> TrackID >> Perhaps: >> Profile 3 and above leverage Local RPL Instances to build arbitrary >> Tracks rooted at the Track Ingress, using the namespace of the >> Track Ingress for the TrackID. >> --> >> Pascal > please use 'Perhaps' >> 51) <!-- [rfced] FYI - We updated the "/" here to "or". Let us know if >> another >> meaning is intended. >> Original: >> Profile 2 is >> RECOMMENDED in a high speed / wired environment to enable Traffic >> Engineering and network automation. >> Perhaps: >> Profile 2 is >> RECOMMENDED in a high-speed or wired environment to enable Traffic >> Engineering and network automation. >> --> >> Pascal > please use >> " >> Profile 2 is >> RECOMMENDED in a high speed (e.g., wired) environment to enable Traffic >> Engineering and network automation. >> " >> 52) <!--[rfced] Please clarify "on top". Is it necessary to include in >> this sentence? >> Original: >> The other Profiles extend Profile 0 with selected capabilities >> that this specification introduces on top. >> Perhaps: >> The other profiles extend Profile 0 with selected capabilities >> that this specification introduces. >> --> >> Pascal > please use 'Perhaps' >> 53) <!--[rfced] Is "source routing" correct in these sentences, or should >> it be "source-routed" per Table 26? >> Current: >> Profile 2 extends Profile 0 with strict source routing Non-Storing >> Mode P-Routes along the main DODAG, which is the same as Profile 1 >> but using NSM-VIOs as opposed to SM-VIOs. >> Profile 4 extends Profile 2 with strict source routing Non-Storing >> Mode P-Routes to form forward Tracks that are inside the main >> DODAG but do not necessarily follow it. >> Perhaps: >> Profile 2 extends Profile 0 with strict source-routed Non-Storing >> Mode P-Routes along the main DODAG, which is the same as Profile 1 >> but using NSM-VIOs as opposed to SM-VIOs. >> Profile 4 extends Profile 2 with strict source-routed Non-Storing >> Mode P-Routes to form forward Tracks that are inside the main >> DODAG but do not necessarily follow it. >> --> >> Pascal > please use 'Perhaps' >> 54) <!--[rfced] FYI: We updated "In that case" to "With Profile 2" for >> clarity. Please let us know if that is not correct. >> Original: >> In that case, the Tracks MUST be installed as subTracks of the main >> DODAG, the main Instance MUST be used as TrackID. >> Current: >> With Profile 2, the Tracks MUST be installed as subTracks of the main >> DODAG, and the main Instance MUST be used as the TrackID. >> --> >> Pascal > OK >> 55) <!--[rfced] We are having trouble parsing this sentence; it reads as >> if 6TiSCH defined RFC 9031. Is the intended meaning that 6TiSCH >> is defined in RFC 9031? Please let us know how we may clarify the >> text. >> Original: >> 6TiSCH defined [RFC9031] with the RPL Root acting as 6LBR. >> --> >> Pascal > the 6TiSCH WG defined ... Let's reword, e.g.,: >> " >> The 6TiSCH Constrained Join Protocol (CoJP) [RFC9031] uses the RPL Root as >> 6LBR. >> " >> 56) <!--[rfced] We are having trouble parsing the latter part of this >> sentence (i.e., "by avoiding that a node appears twice"). How may >> we update this for clarity? >> Original: >> This specification suggests some validation of the VIO to prevent >> basic loops by avoiding that a node appears twice. >> Perhaps A: >> This specification suggests some validation of the VIO to prevent >> basic loops when a node appears twice. >> or >> Perhaps B: >> This specification suggests some validation of the VIO to prevent >> basic loops, i.e., by avoiding a node that appears twice. >> --> >> Pascal > please use 'Perhaps B' >> 57) <!-- [rfced] We have included some specific questions about the IANA >> text below. In addition to responding to those questions, please >> review all of the IANA-related updates carefully and let us know >> if any further updates are needed. >> a) Text relating to the "Mode of Operation" registry appears in Section 11.1 >> after the information for the "DODAG Configuration Option Flags for MOP 0..6" >> registry. May we create a new subsection for this text, perhaps titled "Mode >> of >> Operation"? >> Current: >> IANA has added this RFC as an additional reference for MOP 7 in the >> "Mode of Operation" registry under the "Routing Protocol for Low >> Power and Lossy Networks (RPL)" registry group [IANA-RPL]. >> Pascal > please leave as is >> b) In Table 26, may we include the expansions of "SM-VIO" and "NSM-VIO" for >> clarity and consistency with the running text? Note that we will communicate >> any updates to IANA. >> Current: >> 0x0F Stateful VIO (SM-VIO) >> 0x10 Source-Routed VIO (NSM-VIO) >> Perhaps: >> 0x0F Stateful Storing Mode VIO (SM-VIO) >> 0x10 Source-Routed Non-Storing Mode VIO (NSM-VIO) >> Pascal > please use 'Perhaps' >> c) In Section 5.3, should "stateful" and "source-routed" be included >> in the description for "Option Type" per Table 26? >> Original: >> Option Type: 0x0F for SM-VIO and 0x10 for NSM-VIO (see Table 26). >> Perhaps: >> Option Type: 0x0F for stateful SM-VIO and 0x10 for source-routed >> NSM-VIO (see Table 26). >> Please leave as is. stateful is not part of the name, it is a characteristic. >> d) In both the "PDR-ACK Acceptance Status Values" and "PDR-ACK Rejection >> Status Values" registries <https://www.iana.org/assignments/rpl/>, the first >> column is titled "Bit Number"; however, in Tables 28 and 29 of this document, >> the first column is titled "Value". Please let us know which term you prefer >> ("Bit Number" or "Value") and we will make the document and registries >> consistent. >> --> >> Pascal > great catch. This is a bug in the IANA registry, probably a cc of >> the previous entry. Please use 'value' >> 58) <!-- [rfced] Would you like the references to be alphabetized >> or left in their current order? >> --> >> Pascal > please leave as is >> 59) <!--[rfced] FYI: "draft-kuehlewind-update-tag" has been replaced by >> "draft-kuehlewind-rswg-updates-tag", so we have updated this >> reference entry accordingly. Please let us know of any objection. >> Original: >> [I-D.kuehlewind-update-tag] >> Kühlewind, M. and S. Krishnan, "Definition of new tags for >> relations between RFCs", Work in Progress, Internet-Draft, >> draft-kuehlewind-update-tag-04, 12 July 2021, >> <https://datatracker.ietf.org/doc/html/draft-kuehlewind- >> update-tag-04>. >> Current: >> [NEW-TAGS] >> Kühlewind, M. and S. Krishnan, "Definition of new tags for >> relations between RFCs", Work in Progress, Internet-Draft, >> draft-kuehlewind-rswg-updates-tag-02, 8 July 2024, >> <https://datatracker.ietf.org/doc/html/draft-kuehlewind- >> rswg-updates-tag-02>. >> --> >> Pascal > thanks >> 60) <!-- [rfced] FYI: We have updated this reference's URL to use the >> following URL, which points to the "IPv6 Low Power Personal Area >> Network Parameters" registry: >> <https://www.iana.org/assignments/_6lowpan-parameters>. Please >> let us know if this is incorrect. >> Original: >> [IANA-6LO] IETF, "IPv6 Low Power Personal Area Network Parameters registry", >> <https://www.iana.org/assignments/icmpv6-parameters/>. >> Current: >> [IANA-6LO] IANA, "IPv6 Low Power Personal Area Network Parameters", >> <https://www.iana.org/assignments/_6lowpan-parameters>. >> --> >> Pascal > thanks >> 61) <!-- [rfced] Some author comments are present in the XML. Please confirm >> that >> no updates related to these comments are outstanding. Note that the >> comments will be deleted prior to publication. >> --> >> Pascal > confirmed >> 62) <!-- [rfced] Terminology >> a) Throughout the text, the following terminology appears to be used >> inconsistently. Please review these occurrences and let us know if/how they >> may be made consistent. >> Complex Track vs. complex Track >> Pascal > please use Complex Track as per RFC 9030 >> Objective Function vs. objective function >> Pascal > please use "Objective Function" as per RFC 6550 >> Instance vs. instance >> [Note: is "topologies called instances" correct or should it be >> "Instances"? Should any other lowercase occurrences be uppercase?] >> Global Instance vs. global instance >> [Note: "Global RPL Instance" and "Global instance" used in RFC 6550 >> and "Global Instance 0" used in RFC 8138] >> Local Instance >> main Instance vs. main instance >> RPL Instance vs. RPL instance >> [Note: "RPL Instance" used in RFCs 6550, 6553, and 8138 and >> companion document draft-ietf-raw-technologies-17] >> Track Instance vs. Track instance >> Pascal > please use " Instance " as per RFC 6550 in all cases >> Rejection Status vs. rejection status >> [Note: "rejection status" used in RFC 6550) >> Pascal > please use "rejection status" as per RFC 6550 >> Root vs. root >> [Note: There are 7 lowercase instances, plus one within quoted text. >> Aside from the quoted text, should any of these be made uppercase >> for consistency?] >> Pascal > please use " Root " as per RFC 6550 in all cases >> Routing Header vs. routing header >> [Note: "Routing Header" used in RFC 8138. Also, after the first >> expansion, may we replace this term with "RH"?] >> Pascal > please use " Routing Header " as per RFC 8138 in all >> cases >> Segment ID (4) vs. SegmentID (6) >> Pascal > please use " SegmentID " in all cases >> Track ID (3) vs. TrackID (90) >> Pascal > please use " TrackID " in all cases >> Target (77) vs. target (11) >> Pascal > please leave the text as is >> Type of 4 vs. type 4 (also, type 3 and type 5) >> Pascal > please use "type 4" >> b) FYI: We updated the following terms to reflect the forms on the >> right for consistency. Please let us know of any objection. >> 6LoWPAN Header Compression -> 6LoWPAN header compression (per RFC 8138) >> 6LoWPAN Network -> 6LoWPAN network >> 6TiSCH Architecture -> 6TiSCH architecture >> Backbone -> backbone (per RFC 6550) >> base Object and base object -> Base Object >> Border Router and Border router -> border router (per RFC 6550) >> Code -> code (per RFC 6550) >> dataplane -> data plane (per companion document >> draft-ietf-raw-technologies-17) >> Destination Address -> destination address >> DODAG Configuration Option -> DODAG Configuration option (per RFC 6550) >> DODAG ID -> DODAGID >> Extension Header and extension Header -> extension header >> external Controller -> external controller >> global RPLInstanceID -> Global RPLInstanceID >> IPv6 Address -> IPv6 address >> IPv6 Header -> IPv6 header (per RFC 8138) >> Legacy -> legacy (per companion document draft-ietf-raw-technologies-17) >> Link-Layer security -> link-layer security (per RFC 9010) >> local RPL Instance -> Local RPL Instance (per RFC 6550 and companion >> document draft-ietf-raw-technologies-17) >> local RPLInstanceID -> Local RPLInstanceID (per companion document >> draft-ietf-raw-technologies-17) >> loose Source Routing -> loose source routing >> multihop -> multi-hop (per RFC 8930 and companion documents) >> Non-Storing mode and non-storing mode -> Non-Storing Mode >> Non-Storing P-DAO -> Non-Storing Mode P-DAO >> P-route -> P-Route >> Protection Path -> protection path (to match companion documents) >> Protection service -> protection service >> RAW Architecture -> RAW architecture (to match companion documents) >> Recovery Graph -> recovery graph (per companion document >> draft-ietf-raw-architecture-30) >> Routing Stretch -> routing stretch >> RPL InstanceID and RPLinstanceID -> RPLInstanceID >> RPL Network -> RPL network >> segment Lifetime of zero -> Segment Lifetime of 0 >> Sibling Information option -> Sibling Information Option >> Source Address -> source address (per RFC 6550) >> Source Route path -> source route path (per RFCs 6550 and 8138) >> Stand-Alone -> stand-alone >> Storing mode and storing mode -> Storing Mode >> Strict -> strict >> time scale -> timescale (per companion document >> draft-ietf-raw-architecture-30) >> track -> Track (5 instances) >> traffic Engineering -> Traffic Engineering (per companion documents) >> VIA Address -> Via address >> Via Information option -> Via Information Option >> Pascal > Absolutely great. please note that the companion drafts are RFC >> 9912 and RFC 9913 so this text will change >> c) Please review the following capitalization inconsistencies in the names of >> nodes and let us know how to update for consistency. Note that the first >> three >> terms below appeared in the companion document >> draft-ietf-raw-architecture-30, >> and the author chose to use "egress node", "ingress node", and "relay node" >> (all lowercase). If you would like to follow this pattern in this document, >> please also review instances of "Egress" and "Ingress" when not in the >> context of "Egress Node" and "Ingress Node" (e.g., "the Track Egress", "from >> Ingress to Egress") and let us know they should be lowercased as well. >> Pascal > the "Track Egress" is really the Track egress node so your proposal >> works there too. >> Note that "Root Node" and "Forwarding Node" did not appear in the companion >> documents. >> Egress Node vs. Egress node >> Ingress Node vs. Ingress node >> Relay Node vs. Relay node >> [Note: "relay node" used in RFC 8655] >> Pascal > Please use lowercase for "forwarding", "node", "ingress", and >> "egress" in all cases. Root is inherited from RFC 6550 so please leave it >> uppercase. >> Root Node >> Forwarding Node vs. forwarding Node >> d) Please let us know if/how we may make these terms consistent. >> Projected DAO-ACK vs. P-DAO-ACK >> [Note: Is "P-DAO-ACK" short for "Projected DAO-ACK" >> Pascal > yes >> or are these different terms? In Section 4.1.1, should the first mention >> of "P-DAO-ACK" be updated as "Projected DAO-ACK (P-DAO-ACK)"?] >> Pascal > Please use "Projected " on first use then P. >> routing stretch vs. route stretch >> Pascal > Please "routing stretch " >> RPL DODAG Configuration option vs. RPL configuration option vs. >> DODAG Configuration option >> Pascal > please use 'Configuration option' as per RFC 6550 in all cases >> RPL Storing Mode vs. Storing Mode >> Pascal > please use ' RPL Storing Mode " >> e.1) Please let us know if/how we may make the case for these terms >> consistent. >> Source Routing Header vs. >> source routing header >> [Note: Suggest uppercase to match RFCs 6554 and 8138.] >> Pascal > yes, please use uppercase >> Source Route Header vs. >> source route header vs. >> source-routed header >> [Note: Suggest uppercase. >> Pascal > yes, please use uppercase >> - Should "RPL" precede these instances to match use in >> RFC 6554 (e.g., "RPL Source Route Header"), or should any >> of these instances be "Source Routing Header" or "SRH"?] >> Pascal > yes, please add RPL to ensure clarity (vs. SRH in segment routing >> specs) >> e.2) Is the use of "(RPL) SRH" correct in the sentences below, or >> should it be "RPL Source Route Header" per RFC 6554? >> Original: >> In a Non-Storing mode RPL domain, the IPv6 RH used for source routing >> is the (RPL) SRH as defined in [RFC6554]. >> Perhaps: >> In a Non-Storing Mode RPL domain, the IPv6 RH used for source routing >> is the RPL Source Route Header as defined in [RFC6554]. >> Pascal > please use 'Perhaps' >> ... >> Original: >> As such, forwarding along segments as specified hereafter can be seen >> as a form of Segment Routing [RFC8402], but leveraging the (RPL) SRH >> for its operation. >> Perhaps: >> As such, forwarding along segments as specified hereafter can be seen >> as a form of Segment Routing [RFC8402] that leverages the RPL Source >> Route Header for its operation. >> Pascal > please use 'Perhaps' >> f) Regarding "Non-Storing Mode" vs. "Non-Storing Mode of Operation >> (MOP)" and "Non-Storing MOP", should any of the instances below be >> "Non-Storing Mode" or are they correct as is? >> Pascal > they refer to the same thing. When we speak we say "mode", and we >> mean RPL MOP. Please lowercase "mode" or leave the full MOP expanded or not. >> We note that RFC 6550 uses "Non-Storing mode" and "Non-Storing >> Mode of Operation". Please let us know if any further changes are >> needed to the case of "Mode" throughout the document. >> Current: >> Section 1: ... operated in RPL Non-Storing Mode of Operation (MOP) >> Section 3.2: ... RPL Storing Mode or Non-Storing Mode of Operation (MOP) >> ... compared to Non-Storing MOP >> Pascal > Good. For the latter you could say RPL Storing or Non-Storing Mode >> of Operation (MOP) >> g) May we make "Header" lowercase (form on the right) for the following >> terms to match use in RFC 8138? >> IP-in-IP 6LoRH Header -> IP-in-IP 6LoRH header >> P-RPI-6LoRH Header -> P-RPI-6LoRH header >> RPI-6LoRH Header -> RPI-6LoRH header >> Pascal > yes, please >> h) We note the inconsistent use of quote marks around flag names. >> Please review and let us know if you prefer single quotes or no >> quotes for consistency. >> Some examples: >> 'D' flag vs. D flag >> 'P' flag vs. P flag >> 'O', 'R', and 'F' flags vs. O, R, and F flags >> --> >> Pascal > this reflects inconsistencies in the references as well. I prefer >> with the quote if that's OK. >> 63) <!-- [rfced] Abbreviations >> a) FYI - We have added expansions for the following abbreviations per >> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review these and >> each expansion in the document carefully to ensure correctness. >> Deterministic Networking (DetNet) >> Enhanced Interior Gateway Routing Protocol (EIGRP) >> Operations, Administration, and Maintenance (OAM) >> Pascal > Thanks >> b) How may we expand the first mention of "P2P" below (in Section 1)? >> We note "P2P (Point-to-Point)" in Section 2.4.4 and "P2P (Peer-to- >> Peer)" in Section 3.3.2. Do all instances of "P2P" refer to >> "Point-to-Point" except for Section 3.3.2, or should "P2P" in Section >> 3.3.2 (and/or elsewhere) be made consistent? Please clarify. >> Pascal > Please use P2P for point to point, and leave peer-to-peer expanded >> with no initialism. >> Current: >> The Routing Protocol for Low Power and Lossy Networks (RPL) [RPL] >> is a Distance Vector protocol, which is well-suited for application >> in a variety of low energy Internet of Things (IoT) networks where >> constrained nodes cannot maintain the full view of the topology, >> and stretched P2P paths are acceptable versus the signaling and >> state overhead involved in maintaining the shortest paths across. >> Pascal > please remove "P2P" in that sentence. >> c) How may we expand one instance of "TID"? Perhaps "Transaction ID", >> "Track ID", or "TrackID"? >> Current: >> If the DAO-ACK is not received, the Root may retry the DAO with the >> same TID or tear down the route. >> Pascal > "TrackID" it is >> d) FYI: We updated the following expansions to the forms on the >> right for consistency. Please let us know of any objection. >> PCE Protocol (PCEP) -> PCE Communication Protocol (PCEP) (per RFC 5440) >> Segment Routing (SRv6) -> Segment Routing over IPv6 (SRv6) (per RFC 8754) >> Pascal > Thanks >> e) We note the following inconsistencies with the companion >> document. Please review and let us know if any changes to this >> document are necessary or if these variations are okay. >> "packet delivery ratio (PDR)" (in draft-ietf-raw-architecture-30) vs. >> "P-DAO Request (PDR)" (in this document) >> Pascal > I suggest we use PDAOReq and PDAOAck in this spec >> "Radio Access Network (RAN)" (in draft-ietf-raw-architecture-30) vs. >> "RPL-Aware Node (RAN)" (in this document) >> Pascal > please leave as is. This doc is in the RPL family and does not >> apply to 3GPP >> --> >> 64) <!-- [rfced] Please review the "Inclusive Language" portion of the online >> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> For example, please consider whether the following should be updated: >> - native >> In addition, please consider whether "traditional" (2 instances) >> should be updated for clarity. While the NIST website >> <https://web.archive.org/web/20250214092458/https://www.nist.gov/ >> nist-research-library/nist-technical-series-publications-author-instructions#table1> >> indicates that this term is potentially biased, it is also ambiguous. >> "Tradition" is a subjective term, as it is not the same for everyone. >> --> >> Pascal > please leave as is. >> Many thanks for this tremendous work! >> Pascal >> Thank you. >> Karen Moore and Rebecca VanRheenen >> RFC Production Center >> On Feb 27, 2026, at 1:55 PM, [email protected] wrote: >> *****IMPORTANT***** >> Updated 2026/02/27 >> RFC Author(s): >> -------------- >> Instructions for Completing AUTH48 >> Your document has now entered AUTH48. Once it has been reviewed and >> approved by you and all coauthors, it will be published as an RFC. >> If an author is no longer available, there are several remedies >> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >> You and you coauthors are responsible for engaging other parties >> (e.g., Contributors or Working Group) as necessary before providing >> your approval. >> Planning your review >> --------------------- >> Please review the following aspects of your document: >> * RFC Editor questions >> Please review and resolve any questions raised by the RFC Editor >> that have been included in the XML file as comments marked as >> follows: >> <!-- [rfced] ... --> >> These questions will also be sent in a subsequent email. >> * Changes submitted by coauthors >> Please ensure that you review any changes submitted by your >> coauthors. We assume that if you do not speak up that you >> agree to changes submitted by your coauthors. >> * Content >> Please review the full content of the document, as this cannot >> change once the RFC is published. Please pay particular attention to: >> - IANA considerations updates (if applicable) >> - contact information >> - references >> * Copyright notices and legends >> Please review the copyright notice and legends as defined in >> RFC 5378 and the Trust Legal Provisions >> (TLP – https://trustee.ietf.org/license-info). >> * Semantic markup >> Please review the markup in the XML file to ensure that elements of >> content are correctly tagged. For example, ensure that <sourcecode> >> and <artwork> are set correctly. See details at >> <https://authors.ietf.org/rfcxml-vocabulary>. >> * Formatted output >> Please review the PDF, HTML, and TXT files to ensure that the >> formatted output, as generated from the markup in the XML file, is >> reasonable. Please note that the TXT will have formatting >> limitations compared to the PDF and HTML. >> Submitting changes >> ------------------ >> To submit changes, please reply to this email using ‘REPLY ALL’ as all >> the parties CCed on this message need to see your changes. The parties >> include: >> * your coauthors >> * [email protected] (the RPC team) >> * other document participants, depending on the stream (e.g., >> IETF Stream participants are your working group chairs, the >> responsible ADs, and the document shepherd). >> * [email protected], which is a new archival mailing list >> to preserve AUTH48 conversations; it is not an active discussion >> list: >> * More info: >> >> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >> * The archive itself: >> https://mailarchive.ietf.org/arch/browse/auth48archive/ >> * Note: If only absolutely necessary, you may temporarily opt out >> of the archiving of messages (e.g., to discuss a sensitive matter). >> If needed, please add a note at the top of the message that you >> have dropped the address. When the discussion is concluded, >> [email protected] will be re-added to the CC list and >> its addition will be noted at the top of the message. >> You may submit your changes in one of two ways: >> An update to the provided XML file >> — OR — >> An explicit list of changes in this format >> Section # (or indicate Global) >> OLD: >> old text >> NEW: >> new text >> You do not need to reply with both an updated XML file and an explicit >> list of changes, as either form is sufficient. >> We will ask a stream manager to review and approve any changes that seem >> beyond editorial in nature, e.g., addition of new text, deletion of text, >> and technical changes. Information about stream managers can be found in >> the FAQ. Editorial changes do not require approval from a stream manager. >> Approving for publication >> -------------------------- >> To approve your RFC for publication, please reply to this email stating >> that you approve this RFC for publication. Please use ‘REPLY ALL’, >> as all the parties CCed on this message need to see your approval. >> Files >> ----- >> The files are available here: >> https://www.rfc-editor.org/authors/rfc9914.xml >> https://www.rfc-editor.org/authors/rfc9914.html >> https://www.rfc-editor.org/authors/rfc9914.pdf >> https://www.rfc-editor.org/authors/rfc9914.txt >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc9914-diff.html >> https://www.rfc-editor.org/authors/rfc9914-rfcdiff.html (side by side) >> For your convenience, we have also created an alt-diff file that will >> allow you to more easily view changes where text has been deleted or >> moved: >> https://www.rfc-editor.org/authors/rfc9914-alt-diff.html >> Diff of the XML: >> https://www.rfc-editor.org/authors/rfc9914-xmldiff1.html >> Tracking progress >> ----------------- >> The details of the AUTH48 status of your document are here: >> https://www.rfc-editor.org/auth48/rfc9914 >> Please let us know if you have any questions. >> Thank you for your cooperation, >> RFC Editor >> -------------------------------------- >> RFC9914 (draft-ietf-roll-dao-projection-40) >> Title : Root-initiated Routing State in RPL >> Author(s) : P. Thubert, Ed., R. Arvind Jadhav, M. Richardson >> WG Chair(s) : Ines Robles, Remous-Aris Koutsiamanis >> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde >> -- >> Pascal >> -- >> auth48archive mailing list -- [email protected] >> To unsubscribe send an email to [email protected] -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
