Hi Pascal, For this requested change, would this update be agreeable?
Current (Section 2.4.5): A Track is a networking graph that can be followed to transport packets with equivalent treatment; as opposed to the definition of a path above, a Track is not necessarily linear. Perhaps: A Track is a networking graph that can be followed to transport packets with equivalent treatment; as opposed to other definitions of a path (see [INT-ARCH] and Section 3.1.1 of [RAW-ARCH]), a Track is not necessarily linear. Best regards, Karen Moore RFC Production Center > On Mar 6, 2026, at 11:43 PM, Pascal Thubert <[email protected]> wrote: > > Hello again Karen > > It might be that the text in 2.4.5 > “ > as opposed to the definition of a path above > > “ > Becomes unreadable when the quotes on 2.4.3 are removed which is not yet > visible in the posted html version. > > If so maybe we could replace it with : > “ > As opposed to other definitions found in the art > “ > or something similar and again quote the section. On path in the RAW > architecture ? > > All the best, > > Pascal > >> Le 7 mars 2026 à 08:19, Pascal Thubert <[email protected]> a écrit : >> >> 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]
