Hello Kaelin Many thanks ! Please see below:
> Le 13 févr. 2026 à 18:08, Kaelin Foody <[email protected]> a écrit : > > Hi Ketan, Pascal, > > Ketan - > > Thank you for your prompt reply. We have marked your approval as AD on this > document’s AUTH48 status page below: > https://www.rfc-editor.org/auth48/rfc9912 > > > Pascal - > > Thank you for your quick turnaround and thorough reply! We have updated the > files as requested; you may find these updated files at the end of this email. > > We have a few follow-up questions: > >> 13) <!-- [rfced] Introductory text >> >> a) Sections 3.4 and 3.5 contain introductory sentences. We have updated them >> as shown below. Please let us know any concerns. >> >> Original: >> This document reuses the terminology in section 2 of [RFC8557] and >> section 4.1.2 of [DetNet-ARCHI] for deterministic networking and >> deterministic networks. >> ... >> In the context of the RAW work, Reliability and Availability are >> defined as follows: >> >> Current: >> This document reuses the terminology in Section 2 of [RFC8557] and >> in Section 4.1.2 of [DetNet-ARCHI] for deterministic networking and >> deterministic networks. This document also uses the following terms. >> ... >> This document uses the following terms relating to reliability and >> availability in the context of the RAW work. >> >> Pascal> It is a bit more than this. As pointed in the original text we do >> define Reliability and Availability for our own use and for the lack of an >> IETF standard definition > > a) Thank you for providing context for the item above. Would the following > update better reflect your meaning? > > Perhaps: > > In the context of the RAW work, reliability and availability are > defined as follows, along with the following other terms. > Perfect ! > >> 14) <!-- [rfced] Will "a subsecond to seconds duration" be clear to readers? >> >> Original: >> In the context of RAW, a link flaps when the reliability of the >> wireless connectivity drops abruptly for a short period of time, >> typically of a subsecond to seconds duration. >> >> Perhaps: >> In the context of RAW, a link flaps when the reliability of the >> wireless connectivity drops abruptly for a short period of time, >> typically a duration of a subsecond or a second. >> --> >> >> Pascal> the new text fails to show we're talking about a range of duration, >> which can be "smaller than a second" all the way to possibly "multiple >> seconds". For now I prefer the original but another proposal is welcome > > b) Thank you for clarifying. Would the following update be more accurate? > > Perhaps: > > In the context of RAW, a link flaps when the reliability of the > wireless connectivity drops abruptly for a short period of time, > typically a duration of a subsecond to seconds. Yes > > >> 45) <!-- [rfced] Terminology: >> >> b) We note the following capitalization inconsistencies in the names of >> nodes. Please review and let us know how to update for consistency. >> >> RAW Node >> RAW node >> >> Ingress Node >> Ingress node >> >> Egress Node >> Egress node >> >> DetNet Edge nodes >> DetNet Edge Nodes >> edge nodes >> >> DetNet Transit Nodes >> DetNet Transit nodes >> transit node >> >> DetNet Relay Node >> >> Pascal > please use lowercase for "node" in every usage above > > c) We have made “node” lowercase in all usages above as requested. Please let > us know how/if "Edge", "Transit", and "Relay" (as seen above) should be made > consistent as well. > Yes, please follow rfc 8655 which uses lowercase > > d) We could not find responses for the three items below. Please review and > let us know your preferences: > >> 11) <!-- [rfced] Section 3.1: If no objections, we will update this section >> to use >> <dl> instead of a separate subsection for each abbreviation. Note that >> this aligns with the format used in draft-ietf-roll-dao-projection-40 >> (also part of Cluster 538) and is more typical in the RFC Series. >> --> Ok > > >> 26) <!-- [rfced] FYI - To make this text easier to read and understand, we >> updated >> the "e.g., using redundancy..." phrase to be two separate sentences. Please >> review and let us know any objections. >> >> Original: >> Packet loss cannot be fully avoided and the systems are built to resist >> some loss, e.g., using redundancy with Retries (as in HARQ), Packet >> Replication and Elimination (PRE) FEC, Network Coding (e.g., using FEC with >> SCHC [RFC8724] fragments), or, in a typical control loop, by linear >> interpolation from the previous measurements. >> >> Current: >> Packet loss cannot be fully >> avoided, and the systems are built to resist some loss. This can be >> done by using redundancy with retries (as in HARQ), Packet >> Replication and Elimination (PRE) FEC, and Network Coding (e.g., >> using FEC with Static Context Header Compression (SCHC) [RFC8724] >> fragments). Also, in a typical control loop, linear interpolation >> from the previous measurements can be used. >> --> > Ok > >> 34) <!-- [rfced] Please review the paragraphs before Figure 6 (strict model) >> and >> Figure 7 (loose model) and let us know if any changes are needed to place >> text about the loose model together before Figure 7. >> --> > > I believe it is ok as is. Again many thanks Kaelin! Pascal > — FILES (please refresh): — > > The updated files have been posted here: > https://www.rfc-editor.org/authors/rfc9912.txt > https://www.rfc-editor.org/authors/rfc9912.pdf > https://www.rfc-editor.org/authors/rfc9912.html > https://www.rfc-editor.org/authors/rfc9912.xml > > Diff files showing changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9912-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9912-auth48rfcdiff.html (AUTH48 changes > side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9912-diff.html (all changes) > https://www.rfc-editor.org/authors/rfc9912-rfcdiff.html (all changes side by > side) > > > Thanks for your time. > > All the best, > > Kaelin Foody > RFC Production Center > > >> On Feb 11, 2026, at 10:50 AM, Pascal Thubert <[email protected]> >> wrote: >> >> Dear Kaelin and Rebecca; >> >> This is a big draft and a lot of work for us all. Many thanks for taking the >> challenge and for your hard work on it! >> >> Please see below: >> >> >> >> Le mar. 10 févr. 2026 à 06:53, <[email protected]> a écrit : >> Pascal and AD*, >> >> *AD, please see question #1 below. >> >> Pascal, while reviewing this document during AUTH48, please resolve (as >> necessary) the following questions, which are also in the source file. >> >> >> 1) <!-- [rfced] *AD, Janos Farkas (document shepherd) sent an email to the >> RPC on >> 2026 Jan 16 saying that the reference [6TiSCH-ARCHI] should be moved from the >> normative references section to the informative references section. We >> made this change, but please review and let us know if you approve. We >> consider changes to normative references to be "beyond editorial". >> --> >> >> >> Pascal> OK >> >> 2) <!-- [rfced] Please note that the title of the document has been updated >> as >> follows. We have added the abbreviation "RAW" to align with the title of >> draft-ietf-raw-technologies-17 (RFC-to-be 9913). >> >> Original: >> Reliable and Available Wireless Architecture >> >> Current: >> Reliable and Available Wireless (RAW) Architecture >> --> >> >> >> >> Pascal> OK >> >> 3) <!-- [rfced] We have removed "Without Affiliation" from the document >> header >> and Author's Addresses section to align with draft-ietf-raw-technologies >> and draft-ietf-roll-dao-projection. >> >> Note: Per Section 4.1.2 of RFC 7322 ("RFC Style Guide"), an author's >> affiliation may be left blank or include "Independent", "Individual >> Contributor", "Retired", or a similar term. Please let us know if you prefer >> to use one of these terms instead, and we will apply that to all documents in >> this cluster. >> --> >> >> >> >> Pascal> "Independent" is perfect >> >> 4) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search. --> >> >> >> DetNet >> >> 5) <!-- [rfced] May we update "ack-based" to either "acknowledgment-based" or >> "ACK-based" in the text below to clarify its meaning? >> >> Original: >> >> Redundant transmissions: Though feasible on any technology, >> proactive (forward) and reactive (ack-based) error correction are >> typical to the wireless media. >> >> Perhaps: >> >> Redundant transmissions: Though feasible on any technology, >> proactive (forward) and reactive (acknowledgment-based) error correction >> is >> typical for wireless media. >> --> >> >> >> >> Pascal> Please use "perhaps" >> >> 6) <!-- [rfced] Should "translate taking" here be updated to "translate to >> taking"? >> >> Original: >> From a DetNet perspective, this may translate taking into account >> how transmission from one node may interfere with the transmission >> of another node attached to the same wireless sub-layer network. >> >> Perhaps: >> From a DetNet perspective, this may translate to taking into account >> how transmission from one node may interfere with the transmission >> of another node attached to the same wireless sub-layer network. >> --> >> >> >> Pascal> Please use "perhaps" >> >> 7) <!-- [rfced] Will readers understand what "It" refers to in the second >> sentence (e.g., to "path", "mechanism", "RAW")? Also, how may we clarify >> "ala"? >> >> Original: >> The mechanisms used to establish a path is not unique to, or >> necessarily impacted by, RAW. It is expected to be the product of >> the DetNet Controller Plane >> [I-D.ietf-detnet-controller-plane-framework], and may use a Path >> computation Element (PCE) [RFC4655] or the DetNet Yang Data Model >> [RFC9633], or may be computed in a distributed fashion ala Resource >> ReSerVation Protocol (RSVP) [RFC2205]. >> >> Perhaps: >> The mechanism used to establish a path is not unique to, or >> necessarily impacted by, RAW. The mechanism is expected to be the product >> of >> the DetNet Controller Plane [DetNet-PLANE]; it may use a Path >> Computation Element (PCE) [RFC4655] or the DetNet YANG data model >> [RFC9633], or it may be computed in a distributed fashion as per the >> Resource ReSerVation Protocol (RSVP) [RFC2205]. >> --> >> >> Pascal> Please use "perhaps" >> >> 8) <!-- [rfced] Will readers know what "IETF art of Protection" is? Also, is >> a >> reference needed in this sentence? >> >> Original: >> RAW inherits and >> augments the IETF art of Protection as seen in DetNet and Traffic >> Engineering. >> --> >> >> >> Pascal> Please replace "protection" with "path protection". A possible >> reference would be the TEAS WG as a whole. >> >> >> 9) <!-- [rfced] For clarity, we have replaced the comma in the text below >> with >> "for". Please review to ensure this update does not change your meaning. >> >> Original: >> >> RAW also reuses terminology defined for MPLS in [RFC4427] such as the >> term recovery as covering both Protection and Restoration, a number >> of recovery types. >> >> Current: >> >> RAW also reuses terminology defined for MPLS in [RFC4427] such as the >> term "recovery" to cover both protection and restoration for a number >> of recovery types. >> --> >> >> >> Pascal> OK >> >> >> 10) <!-- [rfced] This sentence appears at the end of Section 3. Please >> review the >> placement, and let us know if this should be added to (or moved to >> follow) the third paragraph in Section 3, which also discusses recovery >> graphs. >> >> Original: >> The concept of recovery graph is agnostic to the underlying >> technology and applies but is not limited to any full or partial >> wireless mesh. RAW specifies strict and loose recovery graphs >> depending on whether the path is fully controlled by RAW or traverses >> an opaque network where RAW cannot observe and control the individual >> hops. >> --> >> >> >> Pascal> Please move after the third paragraph in Section 3 >> >> 11) <!-- [rfced] Section 3.1: If no objections, we will update this section >> to use >> <dl> instead of a separate subsection for each abbreviation. Note that >> this aligns with the format used in draft-ietf-roll-dao-projection-40 >> (also part of Cluster 538) and is more typical in the RFC Series. >> --> >> >> >> 12) <!-- [rfced] May we update these section titles to use the plural >> "Links" and >> "Paths"? >> >> Original: >> 3.2. Link and Direction >> 3.3. Path and Recovery Graphs >> >> Perhaps: >> 3.2. Links and Direction >> 3.3. Paths and Recovery Graphs >> --> >> >> >> >> >> Pascal> Please retain the "original" >> 13) <!-- [rfced] Introductory text >> >> a) Sections 3.4 and 3.5 contain introductory sentences. We have updated them >> as shown below. Please let us know any concerns. >> >> Original: >> This document reuses the terminology in section 2 of [RFC8557] and >> section 4.1.2 of [DetNet-ARCHI] for deterministic networking and >> deterministic networks. >> ... >> In the context of the RAW work, Reliability and Availability are >> defined as follows: >> >> Current: >> This document reuses the terminology in Section 2 of [RFC8557] and >> in Section 4.1.2 of [DetNet-ARCHI] for deterministic networking and >> deterministic networks. This document also uses the following terms. >> ... >> This document uses the following terms relating to reliability and >> availability in the context of the RAW work. >> >> >> >> >> Pascal> It is a bit more than this. As pointed in the original text we do >> define Reliability and Availability for our own use and for the lack of an >> IETF standard definition >> >> b) Should Sections 3.2 and 3.3 contain similar introductory sentences? If so, >> please provide the text. >> >> Perhaps: >> This document uses the following terms relating to links and direction >> in the context of RAW. >> ... >> This document uses the following terms relating to paths and recovery graphs >> in the context of RAW. >> --> >> >> >> Pascal > OK >> >> 14) <!-- [rfced] Will "a subsecond to seconds duration" be clear to readers? >> >> Original: >> In the context of RAW, a link flaps when the reliability of the >> wireless connectivity drops abruptly for a short period of time, >> typically of a subsecond to seconds duration. >> >> Perhaps: >> In the context of RAW, a link flaps when the reliability of the >> wireless connectivity drops abruptly for a short period of time, >> typically a duration of a subsecond or a second. >> --> >> >> >> Pascal> the new text fails to show we're talking about a range of duration, >> which can be "smaller than a second" all the way to possibly "multiple >> seconds". For now I prefer the original but another proposal is welcome >> >> 15) <!-- [rfced] FYI - We updated the direct quotes in Section 3.3.1 to >> exactly >> match the text in Section 1.3.3 of [INT-ARCHI] and Section 2 of >> [RFC9473]. >> --> >> >> >> >> Pascal > OK >> >> 16) <!-- [rfced] Section 3.3.2: Please clarify "represents not an actual but >> a >> potential" in this text. >> >> Original: >> >> A networking graph that can be followed to transport packets with >> equivalent treatment, associated with usage metadata; as opposed to >> the definition of a path above, a recovery graph represents not an >> actual but a potential, it is not necessarily a linear sequence like >> a simple path, and is not necessarily fully traversed (flooded) by >> all packets of a flow like a DetNet Path. >> >> Perhaps: >> >> A recovery graph is a networking graph that can be followed to transport >> packets with >> equivalent treatment and is associated with usage metadata. In contrast to >> the definition of a path above, a recovery graph represents a >> potential path, not an actual one. Also, a recovery graph is not >> necessarily a >> linear sequence like >> a simple path and is not necessarily fully traversed (flooded) by >> all packets of a flow like a DetNet Path. >> >> --> >> >> >> Pascal> Please use "perhaps" >> >> 17) <!-- [rfced] Is "coalescence of the collection" redundant? Also, how may >> we >> revise "for which a flow is assigned to the recovery graph" to improve >> clarity? >> >> Original: >> Refining further, a recovery graph is defined as the coalescence of >> the collection of all the feasible DetNet Paths that a packet for >> which a flow is assigned to the recovery graph may be forwarded >> along. >> >> Perhaps: >> Refining further, a recovery graph is defined as the coalescence of >> all the feasible DetNet Paths that a packet with an assigned flow >> may be forwarded along. >> --> >> >> >> Pascal> Please use "perhaps" >> >> 18) <!-- [rfced] The bulleted list in Section 3.3.2 lists the properties of a >> recovery graph. We have the following questions. >> >> a) Is "graph of a recovery graph" correct here? >> >> Original: >> * The graph of a recovery graph is reversible, meaning that packets >> can be routed against the flow of data packets, e.g., to carry OAM >> measurements or control messages back to the Ingress. >> >> Perhaps: >> * A recovery graph is reversible, meaning that packets >> can be routed against the flow of data packets, e.g., to carry OAM >> measurements or control messages back to the Ingress. >> >> >> >> Pascal> Please use "perhaps" >> >> b) In the first bullet below, should "that graph" be updated to "a recovery >> graph"? In the second bullet below, should "of the graph" be updated to "of a >> recovery graph"? Or is the current correct in both instances? >> >> Original: >> * The vertices of that graph are DetNet Relay Nodes that operate at >> the DetNet Service sub-layer and provide the PREOF functions. >> >> * The topological edges of the graph are strict sequences of DetNet >> Transit nodes that operate at the DetNet Forwarding sub-layer. >> >> Perhaps: >> * The vertices of a recovery graph are DetNet Relay Nodes that operate at >> the DetNet Service sub-layer and provide the PREOF functions. >> >> * The topological edges of a recovery graph are strict sequences of DetNet >> Transit nodes that operate at the DetNet Forwarding sub-layer. >> --> >> >> >> >> Pascal> Please use "perhaps" >> >> 19) <!-- [rfced] FYI - For Figure 3, we moved the information about the >> segments >> and paths out of the figure. >> --> >> >> >> >> Pascal> OK >> >> 20) <!-- [rfced] FYI - To improve clarity, we moved the first sentence below >> to a >> parenthetical within the second sentence. Please let us know any >> objections. >> >> Original: >> See section 3.3 of [DetNet-DP]. The classic IP 5-tuple that >> identifies a flow comprises the source IP, destination IP, source >> port, destination port, and the upper layer protocol (ULP). DetNet >> uses a 6-tuple where the extra field is the DSCP field in the packet. >> The IPv6 flow label is not used for that purpose. >> >> Perhaps: >> The classic IP 5-tuple that >> identifies a flow comprises the source IP, destination IP, source >> port, destination port, and the Upper-Layer Protocol (ULP). DetNet >> uses a 6-tuple where the extra field is the Differentiated Services >> Code Point (DSCP) field in the packet (see Section 3.3 of [DetNet-DP]). >> The IPv6 flow label is not used for that purpose. >> --> >> >> >> >> Pascal> Please use "perhaps" >> >> 21) <!-- [rfced] Updates to Section 3.4.5 >> >> a) We made some updates to this sentence (see Current text below). Would >> adding a citation to [TSN] also be helpful here (see Perhaps text below)? >> Also, please review "the efforts at IEEE 802"? Is the intended meaning "the >> IEEE efforts"? >> >> Original: >> 3.4.5. TSN >> >> TSN stands for Time-Sensitive Networking and denotes the efforts at >> IEEE 802 for deterministic networking, originally for use on >> Ethernet. >> >> Current: >> 3.4.5. Time-Sensitive Networking >> >> Time-Sensitive Networking (TSN) denotes the efforts at IEEE 802 regarding >> for deterministic networking, originally for use on >> Ethernet. See [TSN]. >> >> Perhaps: >> 3.4.5. Time-Sensitive Networking >> >> Time-Sensitive Networking (TSN) denotes the IEEE efforts regarding >> for deterministic networking, originally for use on >> Ethernet. See [TSN]. >> >> >> >> Pascal> Please use "perhaps" >> >> b) May we update "the selected RAW technologies [RAW-TECHNOS]" as follows? Or >> is another meaning intended? >> >> Original: >> Wireless TSN (WTSN) denotes extensions of the TSN work on >> wireless media such as the selected RAW technologies [RAW-TECHNOS]. >> >> Perhaps: >> Wireless TSN (WTSN) denotes extensions of the TSN work on >> wireless media, such as the RAW technologies described in [RAW-TECHNOS]. >> --> >> >> >> Pascal> Please use "perhaps" >> >> 22) <!-- [rfced] This sentence is difficult to parse. How does "the >> application >> flow" connect to the rest of the sentence? >> >> Original: >> >> In the context of RAW, an SLA (service level agreement) is a contract >> between a provider (the network) and a client, the application flow, >> defining measurable metrics such as latency boundaries, consecutive >> losses, and packet delivery ratio (PDR). >> >> Perhaps: >> >> In the context of RAW, a Service Level Agreement (SLA) is a contract >> between a provider (the network) and a client that defines the application >> flow >> and measurable metrics such as latency boundaries, consecutive >> losses, and Packet Delivery Ratio (PDR). >> >> Or: >> >> In the context of RAW, a Service Level Agreement (SLA) is a contract >> between a provider (the network) and a client (the application flow) that >> defines >> measurable metrics such as latency boundaries, consecutive >> losses, and Packet Delivery Ratio (PDR). >> --> >> >> >> >> Pascal> Please use "Or" >> >> 23) <!-- [rfced] Will "losses in a row as time series" be clear to readers? >> >> Original: >> It can be for instance, the statistics of >> individual losses and losses in a row as time series. >> >> Perhaps: >> For instance, it can be the statistics of >> individual losses or losses in a row during a certain amount of time. >> --> >> >> >> Pascal> Please use "perhaps" >> >> 24) <!-- [rfced] This sentence may be difficult to read because of the >> parentheticals. Also, does the text starting with "an uptime >> state..." refer to availability or mission readiness? Please review. >> >> Original: >> Availability is the probability of an items (e.g., a network's) >> mission readiness (e.g., to provide an SLA), an uptime state with the >> likelihood of a recoverable downtime state. >> >> Perhaps: >> Availability is the probability of an item's >> mission readiness (e.g., probability of a network to provide an SLA); >> it is an uptime state with the >> likelihood of a recoverable downtime state. >> --> >> >> Pascal > Please remove completely "an uptime state with the likelihood of a >> recoverable downtime state". The formula is given in the next sentence >> anyway. >> >> 25) <!-- [rfced] FYI - We updated these sentences as follows to improve >> readability of "it is thus required to use" and "it is also required to >> use". Let us know any concerns. >> >> Original: >> For high availability, it is thus required to use >> physically link-disjoint and node-disjoint paths; in the wireless >> space, it is also required to use the highest possible degree of >> diversity (time, space, code, frequency, and channel width) in the >> transmissions over the air to combat the additional causes of >> transmission loss. >> >> Perhaps: >> Thus, for high availability, the use of >> physically link-disjoint and node-disjoint paths is required; in the >> wireless >> space, the use of the highest possible degree of >> diversity (time, space, code, frequency, and channel width) in the >> transmissions over the air is also required to combat the additional causes >> of >> transmission loss. >> --> >> >> >> >> Pascal> Please use "perhaps" >> >> 26) <!-- [rfced] FYI - To make this text easier to read and understand, we >> updated >> the "e.g., using redundancy..." phrase to be two separate sentences. Please >> review and let us know any objections. >> >> Original: >> Packet loss cannot be fully avoided and the systems are built to resist >> some loss, e.g., using redundancy with Retries (as in HARQ), Packet >> Replication and Elimination (PRE) FEC, Network Coding (e.g., using FEC with >> SCHC [RFC8724] fragments), or, in a typical control loop, by linear >> interpolation from the previous measurements. >> >> Perhaps: >> Packet loss cannot be fully >> avoided, and the systems are built to resist some loss. This can be >> done by using redundancy with retries (as in HARQ), Packet >> Replication and Elimination (PRE) FEC, and Network Coding (e.g., >> using FEC with Static Context Header Compression (SCHC) [RFC8724] >> fragments). Also, in a typical control loop, linear interpolation >> from the previous measurements can be used. >> --> >> >> >> >> 27) <!-- [rfced] Would updating the text starting with "as a guarantee that >> this..." as follows make this test more clear and concise? >> >> Original: >> But the linear interpolation method cannot resist multiple >> consecutive losses, and a high MTBF is desired as a guarantee that >> this does not happen, in other words that the number of losses-in- >> a-row can be bounded. >> >> Perhaps: >> However, the linear interpolation method cannot resist multiple >> consecutive losses, and a high MTBF is desired as a guarantee that >> the number of losses in a row is bounded. >> --> >> >> >> Pascal> Please use "perhaps" >> >> >> 28) <!-- [rfced] The following text points to Section 5.9.5 of RFC 8175 >> [DLEP]; however, RFC 8175 does not have a Section 5.9.5. What section >> would you like to point to? >> >> Original: >> In that case, what is really desired is a >> Maximum Consecutive Loss (MCL). (See also Section 5.9.5 of [DLEP].) >> --> >> >> Please remove "(See also Section 5.9.5 of [DLEP].)" >> >> >> 29) <!-- [rfced] Will readers understand "as an MTBF as a proxy" in this >> sentence? >> Also, please confirm that Section 7.4 of [RFC8578] is correct here. We do >> not see "reliability", "MTBF", or "MCL" in that section. >> >> Original: >> Engineers that build automated processes may use the network >> reliability expressed in nines as an MTBF as a proxy to indicate an >> MCL, e.g., as described in section 7.4 of the "Deterministic >> Networking Use Cases" [RFC8578]. >> >> Perhaps: >> Engineers that build automated processes may use the network >> reliability expressed in nines as the MTBF and as a proxy to indicate an >> MCL, e.g., as described in Section 7.4 of the "Deterministic >> Networking Use Cases" [RFC8578]. >> >> Or: >> Engineers that build automated processes may use the network >> reliability expressed in nines as the MTBF, which is then used as a >> proxy to indicate an >> MCL, e.g., as described in Section 7.4 of the "Deterministic >> Networking Use Cases" [RFC8578]. >> --> >> >> >> Pascal> Please use "perhaps" >> >> >> >> >> >> >> . Section 7.4 has a requirement for " o Low packet loss (with a bounded >> number of consecutive lost packets)", which is what we want to point at >> >> >> 30) <!-- [rfced] Please review the series in this sentences (i.e., "on >> diverse >> radio channels... and diverse PHY technologies ... , or diverse >> codes"). Should this be a series of two items or three items? >> >> Original: >> A single packet may be sent at different times (time diversity) over >> diverse paths (spatial diversity) that rely on diverse radio channels >> (frequency diversity) and diverse PHY technologies, e.g., narrowband >> vs. spread spectrum, or diverse codes. >> >> Perhaps (two items): >> A single packet may be sent at different times (time diversity) over >> diverse paths (spatial diversity) that rely either on diverse radio channels >> (frequency diversity) and diverse PHY technologies (e.g., narrowband >> versus spread spectrum) or on diverse codes. >> >> Or (three items): >> A single packet may be sent at different times (time diversity) over >> diverse paths (spatial diversity) that rely on diverse radio channels >> (frequency diversity), diverse PHY technologies (e.g., narrowband >> versus spread spectrum), or diverse codes. >> --> >> >> >> Pascal > What about >> A single packet may be sent at different times (time diversity) over >> diverse paths (spatial diversity) that rely on diverse radio channels >> (frequency diversity) leveraging diverse PHY technologies (e.g., narrowband >> versus spread spectrum or diverse codes). >> >> 31) <!-- [rfced] Is "point of local reaction" correct here? We ask because >> we see >> "Point of Local Repair" elsewhere in the document, including in Section >> 6.5 (mentioned in this sentence). >> >> Original: >> The PLR (see Section 6.5) is a point of >> local reaction to provide additional agility against transmission >> loss. >> >> Perhaps: >> The PLR (see Section 6.5) >> provides additional agility against transmission >> loss. >> --> >> >> Pascal> Please use "perhaps" . >> >> 32) <!-- [rfced] How may we update "includes may be a time-aggregated (e.g., >> statistical) fashion" for clarity? >> >> Original: >> The information that the orientation function reports to the routing >> function includes may be a time-aggregated, e.g., statistical >> fashion, to match the longer-term operation of the routing function. >> >> Perhaps: >> The information that the orientation function reports to the routing >> function may be time aggregated (e.g., statistical), >> to match the longer-term operation of the routing function. >> --> >> >> Pascal> Please use "perhaps" . >> >> 33) <!-- [rfced] Will readers understand what "it" refers to in this >> sentence? >> >> Original: >> RAW improves the reliability of transmissions and the availability of >> the communication resources, and should be seen as a dynamic >> optimization of the use of redundancy to maintain it within certain >> boundaries. >> >> Perhaps: >> RAW improves the reliability of transmissions and the availability of >> the communication resources and should be seen as a dynamic >> optimization of the use of redundancy to maintain reliability and >> availability >> within certain boundaries. >> --> >> >> >> Pascal> added "metrics" as follows >> RAW improves the reliability of transmissions and the availability of >> the communication resources and should be seen as a dynamic >> optimization of the use of redundancy to maintain reliability and >> availability metrics >> within certain boundaries. >> >> >> 34) <!-- [rfced] Please review the paragraphs before Figure 6 (strict model) >> and >> Figure 7 (loose model) and let us know if any changes are needed to place >> text about the loose model together before Figure 7. >> --> >> >> >> 35) <!-- [rfced] FYI - We have adjusted the titles of Figures 6 and 7 to >> make them >> consistent with one another; please review. >> >> Original: >> >> Figure 6: (Strict) RAW over DetNet >> Figure 7: Loose RAW >> >> >> Current: >> >> Figure 6: RAW over DetNet (Strict Model) >> Figure 7: RAW over DetNet (Loose Model) >> --> >> >> >> Pascal> OK >> >> >> 36) <!-- [rfced] Some of the items in the numbered list in Section 6 are >> complete >> sentences and others are not. How may we update to create parallel >> structure? >> >> Original: >> 1. Operational Plane measurement protocols for OAM to observe (like >> the first O in OODA) some or all hops along a recovery graph as >> well as the end-to-end packet delivery. >> >> 2. The DetNet Controller Plane establish primary and protection >> paths for use by the RAW Network Plane. ... >> >> 3. A PLR operates at the DetNet Service sub-layer and hosts the >> decision function (like the D in OODA) of which DetNet Paths to >> use for the future packets that are routed within the recovery >> graph. >> >> 4. Service protection actions that are actuated or triggered over >> the LL API by the PLR to increase the reliability of the end-to- >> end transmissions. ... >> >> Perhaps (make #1 and #4 into complete sentences): >> 1. Operational Plane measurement protocols allow OAM to observe (like >> the first "O" in "OODA") some or all hops along a recovery graph as >> well as the end-to-end packet delivery. >> >> 2. The DetNet Controller Plane establishes primary and protection >> paths for use by the RAW Network Plane. ... >> >> 3. A PLR operates at the DetNet Service sub-layer and hosts the >> decision function (like the D in OODA). The decision function determines >> which DetNet Paths will be >> used for future packets that are routed within the recovery >> graph. >> >> 4. Service protection actions are actuated or triggered over >> the LL API by the PLR to increase the reliability of the end-to- >> end transmissions. ... >> --> >> >> >> Pascal> Please use "perhaps". >> >> 37) <!-- [rfced] How may we clarify "builds reports to the routing function"? >> >> Original: >> The interaction between the network nodes and the routing function is >> handled by the orientation function, which builds reports to the >> routing function and sends control information in a digested form ... >> >> Perhaps: >> The interaction between the network nodes and the routing function is >> handled by the orientation function, which builds reports for the >> routing function and sends control information in a digested form ... >> >> Or: >> The interaction between the network nodes and the routing function is >> handled by the orientation function, which reports to the >> routing function and sends control information in a digested form ... >> --> >> >> >> Pascal> Please use "Or". >> >> 38) <!-- [rfced] Will readers understand what "Assurance" means here? We do >> not >> see this used elsewhere in the document. >> >> Original: >> Finally, the RAW Service sub-layer Assurance may observe the >> individual PREOF operation of a DetNet Relay Node to ensure that it >> is conforming; >> --> >> >> >> Pascal > Please replace "Assurance " with "Service Assurance" >> >> 39) <!-- [rfced] What is being connected by "either" in the phrase "either >> or a >> collection of those access links". How should this text be clarified? >> >> Original: >> ; still the RAW OAM measures the end-to-end latency and delivery >> ratio for packets sent via RAN 1, RAN 2, and RAN 3, and determines >> whether a packet should be sent over either or a collection of those >> access links. >> --> >> >> >> Pascal > Please replace " either " with " either access link " (I mean we >> use a single or a collection of the possible links.) >> >> 40) <!-- [rfced] This sentence does not parse. Please clarify. >> >> Original: >> The OODA Loop controls, within the redundant solutions that are proposed by >> the routing function, which is used for each packet to provide a Reliable >> and >> Available service while minimizing the waste of constrained resources. >> >> Perhaps: >> Within the redundant solutions that are proposed by >> the routing function, the OODA Loop controls what is used for each packet >> and >> provides a reliable and >> available service while minimizing the waste of constrained resources. >> --> >> >> Pascal> Please use "perhaps". >> >> >> 41) <!-- [rfced] This sentence is difficult to follow. We updated as shown >> below. >> Please review and to confirm that the updated text accurately conveys the >> intended meaning. >> >> Original: >> The PLR operates on metrics that evolve faster, but that need to be >> advertised at a fast rate but only locally, within the recovery >> graph, and reacts on the metric updates by changing the DetNet path >> in use for the affected flows. >> >> Updated: >> The PLR operates on metrics that evolve quickly and need to be >> advertised at a fast rate (but only locally, within the recovery >> graph), and the PLR reacts to the metric updates by changing the DetNet path >> in use for the affected flows. >> --> >> >> >> >> Pascal> OK >> >> 42) <!-- [rfced] Please clarify "more typical to wireless than wired". >> >> Original: >> The LL API enriches the DetNet protection services (PREOF) with >> potential possibility to interact with lower-layer one-hop >> reliability functions that are more typical to wireless than wired, >> including ARQ, FEC, and other techniques such as overhearing and >> constructive interferences. >> >> Perhaps: >> The LL API enriches the DetNet protection services (PREOF) with the >> possibility to interact with lower-layer, one-hop >> reliability functions that are more typical with wireless links than with >> wired ones, >> including ARQ, FEC, and other techniques such as overhearing and >> constructive interferences. >> --> >> >> >> Pascal> Please use "perhaps". >> >> >> 43) <!-- [rfced] Should "may typically select" be updated to "may select" or >> "typically selects"? >> >> Original: >> A RAW policy may typically select the cheapest collection of links >> that matches the requested SLA, e.g., use free Wi-Fi vs. paid 3GPP >> access. >> >> Perhaps: >> A RAW policy may select the cheapest collection of links >> that matches the requested SLA, e.g., use free Wi-Fi vs. paid 3GPP >> access. >> >> Or: >> A RAW policy typically selects the cheapest collection of links >> that matches the requested SLA, e.g., use free Wi-Fi vs. paid 3GPP >> access. >> --> >> >> >> Pascal> Please use "Or". >> >> 44) <!-- [rfced] Would you like the references to be alphabetized >> or left in their current order? >> --> >> >> >> Pascal> Please do >> >> 45) <!-- [rfced] Terminology: >> >> a) "sub-layer" (with hyphen) is used consistently in this document, but >> "sublayer" (no hyphen) is used in the other documents in cluster 538 >> (draft-ietf-raw-technologies and draft-ietf-roll-dao-projection). May we >> update usage in this document to align with the other documents in the >> cluster? Note that we see mixed usage in past RFCs; for example, RFC 9030 >> uses "sublayer", but RFC 8655 uses "sub-layer". >> >> >> Pascal> Ideally we'd update draft-ietf-raw-technologies to use hyphen if >> that's possible? DAO projection may remain as is by consistency to RFC 9030. >> >> b) We note the following capitalization inconsistencies in the names of >> nodes. Please review and let us know how to update for consistency. >> >> RAW Node >> RAW node >> >> Ingress Node >> Ingress node >> >> Egress Node >> Egress node >> >> DetNet Edge nodes >> DetNet Edge Nodes >> edge nodes >> >> DetNet Transit Nodes >> DetNet Transit nodes >> transit node >> >> DetNet Relay Node >> >> >> Pascal > please use lowercase for "node" in every usage above >> >> c) We also note inconsistencies in the terms below throughout the text. >> Should >> these be uniform? If so, please let us know which form is preferred. >> >> RAW OAM >> RAW / OAM >> >> DetNet Path >> DetNet path >> >> Protection Path >> protection path >> >> path selection >> Path selection (i.e., DetNet Path selection) >> Path Selection (i.e., RAW Path Selection) >> >> Control Loop >> control loop >> >> OODA Loop >> OODA loop >> >> Segment >> segment >> >> Ingress >> ingress >> >> Egress >> egress >> >> DetNet Forwarding sub-layer >> DetNet forwarding sub-layer >> >> Controller Plane >> controller plane >> >> >> Pascal > Please use >> >> RAW OAM >> DetNet path >> protection path >> path selection >> control loop >> OODA loop >> segment >> ingress >> egress >> DetNet forwarding sub-layer >> Controller Plane >> >> d) FYI - We updated "gNb" to "gNB" to align with usage in RFC-to-be 9913 aka >> draft-ietf-raw-technologies-17 and other documents in the RFC Series. >> --> >> >> >> Pascal > OK >> >> 46) <!-- [rfced] Abbreviations >> >> a) Below is the first instance of "PHY" in this document. How should this be >> expanded? As "Physical"? >> >> Original: >> Furthermore, the different RAW technologies are equipped with >> different reliability features, e.g., short range broadcast, >> Multiple-User, Multiple-Input, and Multiple-Output (MUMIMO), PHY rate >> and other Modulation Coding Scheme (MCS) adaptation, coding and >> retransmissions methods, constructive interference and overhearing, >> see [RAW-TECHNOS] for details. >> >> >> >> Pascal> please change "PHY" to "physical layer (PHY)" >> b) FYI - We updated the expansion of SNR as follows to align with the >> expansion used in previous RFCs. >> >> Original: >> Signal-Noise Ratio >> >> Updated: >> Signal-to-Noise Ratio >> >> >> >> Pascal > OK >> >> >> c) FYI - We have added expansions for abbreviations upon first use >> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >> expansion in the document carefully to ensure correctness. >> >> Deterministic Networking (DetNet) >> Dynamic Link Exchange Protocol (DLEP) >> Differentiated Services Code Point (DSCP) >> Static Context Header Compression (SCHC) >> Bidirectional Forwarding Detection (BFD) >> Media Access Control (MAC) >> --> >> >> >> >> Pascal > OK >> >> 47) <!-- [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. >> >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> --> >> >> >> >> >> Pascal > OK >> >> Then again, many thanks! >> >> all the best, >> >> Pascal > >> On Feb 11, 2026, at 10:50 AM, Pascal Thubert <[email protected]> >> wrote: >> >> Dear Kaelin and Rebecca; >> >> This is a big draft and a lot of work for us all. Many thanks for taking the >> challenge and for your hard work on it! >> >> Please see below: >> >> >> >> Le mar. 10 févr. 2026 à 06:53, <[email protected]> a écrit : >> Pascal and AD*, >> >> *AD, please see question #1 below. >> >> Pascal, while reviewing this document during AUTH48, please resolve (as >> necessary) the following questions, which are also in the source file. >> >> >> 1) <!-- [rfced] *AD, Janos Farkas (document shepherd) sent an email to the >> RPC on >> 2026 Jan 16 saying that the reference [6TiSCH-ARCHI] should be moved from the >> normative references section to the informative references section. We >> made this change, but please review and let us know if you approve. We >> consider changes to normative references to be "beyond editorial". >> --> >> >> >> Pascal> OK >> >> 2) <!-- [rfced] Please note that the title of the document has been updated >> as >> follows. We have added the abbreviation "RAW" to align with the title of >> draft-ietf-raw-technologies-17 (RFC-to-be 9913). >> >> Original: >> Reliable and Available Wireless Architecture >> >> Current: >> Reliable and Available Wireless (RAW) Architecture >> --> >> >> >> >> Pascal> OK >> >> 3) <!-- [rfced] We have removed "Without Affiliation" from the document >> header >> and Author's Addresses section to align with draft-ietf-raw-technologies >> and draft-ietf-roll-dao-projection. >> >> Note: Per Section 4.1.2 of RFC 7322 ("RFC Style Guide"), an author's >> affiliation may be left blank or include "Independent", "Individual >> Contributor", "Retired", or a similar term. Please let us know if you prefer >> to use one of these terms instead, and we will apply that to all documents in >> this cluster. >> --> >> >> >> >> Pascal> "Independent" is perfect >> >> 4) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search. --> >> >> >> DetNet >> >> 5) <!-- [rfced] May we update "ack-based" to either "acknowledgment-based" or >> "ACK-based" in the text below to clarify its meaning? >> >> Original: >> >> Redundant transmissions: Though feasible on any technology, >> proactive (forward) and reactive (ack-based) error correction are >> typical to the wireless media. >> >> Perhaps: >> >> Redundant transmissions: Though feasible on any technology, >> proactive (forward) and reactive (acknowledgment-based) error >> correction is >> typical for wireless media. >> --> >> >> >> >> Pascal> Please use "perhaps" >> >> 6) <!-- [rfced] Should "translate taking" here be updated to "translate to >> taking"? >> >> Original: >> From a DetNet perspective, this may translate taking into account >> how transmission from one node may interfere with the transmission >> of another node attached to the same wireless sub-layer network. >> >> Perhaps: >> From a DetNet perspective, this may translate to taking into account >> how transmission from one node may interfere with the transmission >> of another node attached to the same wireless sub-layer network. >> --> >> >> >> Pascal> Please use "perhaps" >> >> 7) <!-- [rfced] Will readers understand what "It" refers to in the second >> sentence (e.g., to "path", "mechanism", "RAW")? Also, how may we clarify >> "ala"? >> >> Original: >> The mechanisms used to establish a path is not unique to, or >> necessarily impacted by, RAW. It is expected to be the product of >> the DetNet Controller Plane >> [I-D.ietf-detnet-controller-plane-framework], and may use a Path >> computation Element (PCE) [RFC4655] or the DetNet Yang Data Model >> [RFC9633], or may be computed in a distributed fashion ala Resource >> ReSerVation Protocol (RSVP) [RFC2205]. >> >> Perhaps: >> The mechanism used to establish a path is not unique to, or >> necessarily impacted by, RAW. The mechanism is expected to be the product >> of >> the DetNet Controller Plane [DetNet-PLANE]; it may use a Path >> Computation Element (PCE) [RFC4655] or the DetNet YANG data model >> [RFC9633], or it may be computed in a distributed fashion as per the >> Resource ReSerVation Protocol (RSVP) [RFC2205]. >> --> >> >> Pascal> Please use "perhaps" >> >> 8) <!-- [rfced] Will readers know what "IETF art of Protection" is? Also, is >> a >> reference needed in this sentence? >> >> Original: >> RAW inherits and >> augments the IETF art of Protection as seen in DetNet and Traffic >> Engineering. >> --> >> >> >> Pascal> Please replace "protection" with "path protection". A possible >> reference would be the TEAS WG as a whole. >> >> >> 9) <!-- [rfced] For clarity, we have replaced the comma in the text below >> with >> "for". Please review to ensure this update does not change your meaning. >> >> Original: >> >> RAW also reuses terminology defined for MPLS in [RFC4427] such as the >> term recovery as covering both Protection and Restoration, a number >> of recovery types. >> >> Current: >> >> RAW also reuses terminology defined for MPLS in [RFC4427] such as the >> term "recovery" to cover both protection and restoration for a number >> of recovery types. >> --> >> >> >> Pascal> OK >> >> >> 10) <!-- [rfced] This sentence appears at the end of Section 3. Please >> review the >> placement, and let us know if this should be added to (or moved to >> follow) the third paragraph in Section 3, which also discusses recovery >> graphs. >> >> Original: >> The concept of recovery graph is agnostic to the underlying >> technology and applies but is not limited to any full or partial >> wireless mesh. RAW specifies strict and loose recovery graphs >> depending on whether the path is fully controlled by RAW or traverses >> an opaque network where RAW cannot observe and control the individual >> hops. >> --> >> >> >> Pascal> Please move after the third paragraph in Section 3 >> >> 11) <!-- [rfced] Section 3.1: If no objections, we will update this section >> to use >> <dl> instead of a separate subsection for each abbreviation. Note that >> this aligns with the format used in draft-ietf-roll-dao-projection-40 >> (also part of Cluster 538) and is more typical in the RFC Series. >> --> >> >> >> 12) <!-- [rfced] May we update these section titles to use the plural >> "Links" and >> "Paths"? >> >> Original: >> 3.2. Link and Direction >> 3.3. Path and Recovery Graphs >> >> Perhaps: >> 3.2. Links and Direction >> 3.3. Paths and Recovery Graphs >> --> >> >> >> >> >> Pascal> Please retain the "original" >> 13) <!-- [rfced] Introductory text >> >> a) Sections 3.4 and 3.5 contain introductory sentences. We have updated them >> as shown below. Please let us know any concerns. >> >> Original: >> This document reuses the terminology in section 2 of [RFC8557] and >> section 4.1.2 of [DetNet-ARCHI] for deterministic networking and >> deterministic networks. >> ... >> In the context of the RAW work, Reliability and Availability are >> defined as follows: >> >> Current: >> This document reuses the terminology in Section 2 of [RFC8557] and >> in Section 4.1.2 of [DetNet-ARCHI] for deterministic networking and >> deterministic networks. This document also uses the following terms. >> ... >> This document uses the following terms relating to reliability and >> availability in the context of the RAW work. >> >> >> >> >> Pascal> It is a bit more than this. As pointed in the original text we do >> define Reliability and Availability for our own use and for the lack of an >> IETF standard definition >> >> b) Should Sections 3.2 and 3.3 contain similar introductory sentences? If so, >> please provide the text. >> >> Perhaps: >> This document uses the following terms relating to links and direction >> in the context of RAW. >> ... >> This document uses the following terms relating to paths and recovery >> graphs >> in the context of RAW. >> --> >> >> >> Pascal > OK >> >> 14) <!-- [rfced] Will "a subsecond to seconds duration" be clear to readers? >> >> Original: >> In the context of RAW, a link flaps when the reliability of the >> wireless connectivity drops abruptly for a short period of time, >> typically of a subsecond to seconds duration. >> >> Perhaps: >> In the context of RAW, a link flaps when the reliability of the >> wireless connectivity drops abruptly for a short period of time, >> typically a duration of a subsecond or a second. >> --> >> >> >> Pascal> the new text fails to show we're talking about a range of duration, >> which can be "smaller than a second" all the way to possibly "multiple >> seconds". For now I prefer the original but another proposal is welcome >> >> 15) <!-- [rfced] FYI - We updated the direct quotes in Section 3.3.1 to >> exactly >> match the text in Section 1.3.3 of [INT-ARCHI] and Section 2 of >> [RFC9473]. >> --> >> >> >> >> Pascal > OK >> >> 16) <!-- [rfced] Section 3.3.2: Please clarify "represents not an actual but >> a >> potential" in this text. >> >> Original: >> >> A networking graph that can be followed to transport packets with >> equivalent treatment, associated with usage metadata; as opposed to >> the definition of a path above, a recovery graph represents not an >> actual but a potential, it is not necessarily a linear sequence like >> a simple path, and is not necessarily fully traversed (flooded) by >> all packets of a flow like a DetNet Path. >> >> Perhaps: >> >> A recovery graph is a networking graph that can be followed to transport >> packets with >> equivalent treatment and is associated with usage metadata. In contrast to >> the definition of a path above, a recovery graph represents a >> potential path, not an actual one. Also, a recovery graph is not >> necessarily a >> linear sequence like >> a simple path and is not necessarily fully traversed (flooded) by >> all packets of a flow like a DetNet Path. >> >> --> >> >> >> Pascal> Please use "perhaps" >> >> 17) <!-- [rfced] Is "coalescence of the collection" redundant? Also, how may >> we >> revise "for which a flow is assigned to the recovery graph" to improve >> clarity? >> >> Original: >> Refining further, a recovery graph is defined as the coalescence of >> the collection of all the feasible DetNet Paths that a packet for >> which a flow is assigned to the recovery graph may be forwarded >> along. >> >> Perhaps: >> Refining further, a recovery graph is defined as the coalescence of >> all the feasible DetNet Paths that a packet with an assigned flow >> may be forwarded along. >> --> >> >> >> Pascal> Please use "perhaps" >> >> 18) <!-- [rfced] The bulleted list in Section 3.3.2 lists the properties of a >> recovery graph. We have the following questions. >> >> a) Is "graph of a recovery graph" correct here? >> >> Original: >> * The graph of a recovery graph is reversible, meaning that packets >> can be routed against the flow of data packets, e.g., to carry OAM >> measurements or control messages back to the Ingress. >> >> Perhaps: >> * A recovery graph is reversible, meaning that packets >> can be routed against the flow of data packets, e.g., to carry OAM >> measurements or control messages back to the Ingress. >> >> >> >> Pascal> Please use "perhaps" >> >> b) In the first bullet below, should "that graph" be updated to "a recovery >> graph"? In the second bullet below, should "of the graph" be updated to "of a >> recovery graph"? Or is the current correct in both instances? >> >> Original: >> * The vertices of that graph are DetNet Relay Nodes that operate at >> the DetNet Service sub-layer and provide the PREOF functions. >> >> * The topological edges of the graph are strict sequences of DetNet >> Transit nodes that operate at the DetNet Forwarding sub-layer. >> >> Perhaps: >> * The vertices of a recovery graph are DetNet Relay Nodes that operate at >> the DetNet Service sub-layer and provide the PREOF functions. >> >> * The topological edges of a recovery graph are strict sequences of DetNet >> Transit nodes that operate at the DetNet Forwarding sub-layer. >> --> >> >> >> >> Pascal> Please use "perhaps" >> >> 19) <!-- [rfced] FYI - For Figure 3, we moved the information about the >> segments >> and paths out of the figure. >> --> >> >> >> >> Pascal> OK >> >> 20) <!-- [rfced] FYI - To improve clarity, we moved the first sentence below >> to a >> parenthetical within the second sentence. Please let us know any >> objections. >> >> Original: >> See section 3.3 of [DetNet-DP]. The classic IP 5-tuple that >> identifies a flow comprises the source IP, destination IP, source >> port, destination port, and the upper layer protocol (ULP). DetNet >> uses a 6-tuple where the extra field is the DSCP field in the packet. >> The IPv6 flow label is not used for that purpose. >> >> Perhaps: >> The classic IP 5-tuple that >> identifies a flow comprises the source IP, destination IP, source >> port, destination port, and the Upper-Layer Protocol (ULP). DetNet >> uses a 6-tuple where the extra field is the Differentiated Services >> Code Point (DSCP) field in the packet (see Section 3.3 of [DetNet-DP]). >> The IPv6 flow label is not used for that purpose. >> --> >> >> >> >> Pascal> Please use "perhaps" >> >> 21) <!-- [rfced] Updates to Section 3.4.5 >> >> a) We made some updates to this sentence (see Current text below). Would >> adding a citation to [TSN] also be helpful here (see Perhaps text below)? >> Also, please review "the efforts at IEEE 802"? Is the intended meaning "the >> IEEE efforts"? >> >> Original: >> 3.4.5. TSN >> >> TSN stands for Time-Sensitive Networking and denotes the efforts at >> IEEE 802 for deterministic networking, originally for use on >> Ethernet. >> >> Current: >> 3.4.5. Time-Sensitive Networking >> >> Time-Sensitive Networking (TSN) denotes the efforts at IEEE 802 regarding >> for deterministic networking, originally for use on >> Ethernet. See [TSN]. >> >> Perhaps: >> 3.4.5. Time-Sensitive Networking >> >> Time-Sensitive Networking (TSN) denotes the IEEE efforts regarding >> for deterministic networking, originally for use on >> Ethernet. See [TSN]. >> >> >> >> Pascal> Please use "perhaps" >> >> b) May we update "the selected RAW technologies [RAW-TECHNOS]" as follows? Or >> is another meaning intended? >> >> Original: >> Wireless TSN (WTSN) denotes extensions of the TSN work on >> wireless media such as the selected RAW technologies [RAW-TECHNOS]. >> >> Perhaps: >> Wireless TSN (WTSN) denotes extensions of the TSN work on >> wireless media, such as the RAW technologies described in [RAW-TECHNOS]. >> --> >> >> >> Pascal> Please use "perhaps" >> >> 22) <!-- [rfced] This sentence is difficult to parse. How does "the >> application >> flow" connect to the rest of the sentence? >> >> Original: >> >> In the context of RAW, an SLA (service level agreement) is a contract >> between a provider (the network) and a client, the application flow, >> defining measurable metrics such as latency boundaries, consecutive >> losses, and packet delivery ratio (PDR). >> >> Perhaps: >> >> In the context of RAW, a Service Level Agreement (SLA) is a contract >> between a provider (the network) and a client that defines the application >> flow >> and measurable metrics such as latency boundaries, consecutive >> losses, and Packet Delivery Ratio (PDR). >> >> Or: >> >> In the context of RAW, a Service Level Agreement (SLA) is a contract >> between a provider (the network) and a client (the application flow) that >> defines >> measurable metrics such as latency boundaries, consecutive >> losses, and Packet Delivery Ratio (PDR). >> --> >> >> >> >> Pascal> Please use "Or" >> >> 23) <!-- [rfced] Will "losses in a row as time series" be clear to readers? >> >> Original: >> It can be for instance, the statistics of >> individual losses and losses in a row as time series. >> >> Perhaps: >> For instance, it can be the statistics of >> individual losses or losses in a row during a certain amount of time. >> --> >> >> >> Pascal> Please use "perhaps" >> >> 24) <!-- [rfced] This sentence may be difficult to read because of the >> parentheticals. Also, does the text starting with "an uptime >> state..." refer to availability or mission readiness? Please review. >> >> Original: >> Availability is the probability of an items (e.g., a network's) >> mission readiness (e.g., to provide an SLA), an uptime state with the >> likelihood of a recoverable downtime state. >> >> Perhaps: >> Availability is the probability of an item's >> mission readiness (e.g., probability of a network to provide an SLA); >> it is an uptime state with the >> likelihood of a recoverable downtime state. >> --> >> >> Pascal > Please remove completely "an uptime state with the likelihood of a >> recoverable downtime state". The formula is given in the next sentence >> anyway. >> >> 25) <!-- [rfced] FYI - We updated these sentences as follows to improve >> readability of "it is thus required to use" and "it is also required to >> use". Let us know any concerns. >> >> Original: >> For high availability, it is thus required to use >> physically link-disjoint and node-disjoint paths; in the wireless >> space, it is also required to use the highest possible degree of >> diversity (time, space, code, frequency, and channel width) in the >> transmissions over the air to combat the additional causes of >> transmission loss. >> >> Perhaps: >> Thus, for high availability, the use of >> physically link-disjoint and node-disjoint paths is required; in the >> wireless >> space, the use of the highest possible degree of >> diversity (time, space, code, frequency, and channel width) in the >> transmissions over the air is also required to combat the additional >> causes of >> transmission loss. >> --> >> >> >> >> Pascal> Please use "perhaps" >> >> 26) <!-- [rfced] FYI - To make this text easier to read and understand, we >> updated >> the "e.g., using redundancy..." phrase to be two separate sentences. Please >> review and let us know any objections. >> >> Original: >> Packet loss cannot be fully avoided and the systems are built to resist >> some loss, e.g., using redundancy with Retries (as in HARQ), Packet >> Replication and Elimination (PRE) FEC, Network Coding (e.g., using FEC with >> SCHC [RFC8724] fragments), or, in a typical control loop, by linear >> interpolation from the previous measurements. >> >> Perhaps: >> Packet loss cannot be fully >> avoided, and the systems are built to resist some loss. This can be >> done by using redundancy with retries (as in HARQ), Packet >> Replication and Elimination (PRE) FEC, and Network Coding (e.g., >> using FEC with Static Context Header Compression (SCHC) [RFC8724] >> fragments). Also, in a typical control loop, linear interpolation >> from the previous measurements can be used. >> --> >> >> >> >> 27) <!-- [rfced] Would updating the text starting with "as a guarantee that >> this..." as follows make this test more clear and concise? >> >> Original: >> But the linear interpolation method cannot resist multiple >> consecutive losses, and a high MTBF is desired as a guarantee that >> this does not happen, in other words that the number of losses-in- >> a-row can be bounded. >> >> Perhaps: >> However, the linear interpolation method cannot resist multiple >> consecutive losses, and a high MTBF is desired as a guarantee that >> the number of losses in a row is bounded. >> --> >> >> >> Pascal> Please use "perhaps" >> >> >> 28) <!-- [rfced] The following text points to Section 5.9.5 of RFC 8175 >> [DLEP]; however, RFC 8175 does not have a Section 5.9.5. What section >> would you like to point to? >> >> Original: >> In that case, what is really desired is a >> Maximum Consecutive Loss (MCL). (See also Section 5.9.5 of [DLEP].) >> --> >> >> Please remove "(See also Section 5.9.5 of [DLEP].)" >> >> >> 29) <!-- [rfced] Will readers understand "as an MTBF as a proxy" in this >> sentence? >> Also, please confirm that Section 7.4 of [RFC8578] is correct here. We do >> not see "reliability", "MTBF", or "MCL" in that section. >> >> Original: >> Engineers that build automated processes may use the network >> reliability expressed in nines as an MTBF as a proxy to indicate an >> MCL, e.g., as described in section 7.4 of the "Deterministic >> Networking Use Cases" [RFC8578]. >> >> Perhaps: >> Engineers that build automated processes may use the network >> reliability expressed in nines as the MTBF and as a proxy to indicate an >> MCL, e.g., as described in Section 7.4 of the "Deterministic >> Networking Use Cases" [RFC8578]. >> >> Or: >> Engineers that build automated processes may use the network >> reliability expressed in nines as the MTBF, which is then used as a >> proxy to indicate an >> MCL, e.g., as described in Section 7.4 of the "Deterministic >> Networking Use Cases" [RFC8578]. >> --> >> >> >> Pascal> Please use "perhaps" >> >> >> >> >> >> >> . Section 7.4 has a requirement for " o Low packet loss (with a bounded >> number of consecutive lost packets)", which is what we want to point at >> >> >> 30) <!-- [rfced] Please review the series in this sentences (i.e., "on >> diverse >> radio channels... and diverse PHY technologies ... , or diverse >> codes"). Should this be a series of two items or three items? >> >> Original: >> A single packet may be sent at different times (time diversity) over >> diverse paths (spatial diversity) that rely on diverse radio channels >> (frequency diversity) and diverse PHY technologies, e.g., narrowband >> vs. spread spectrum, or diverse codes. >> >> Perhaps (two items): >> A single packet may be sent at different times (time diversity) over >> diverse paths (spatial diversity) that rely either on diverse radio >> channels >> (frequency diversity) and diverse PHY technologies (e.g., narrowband >> versus spread spectrum) or on diverse codes. >> >> Or (three items): >> A single packet may be sent at different times (time diversity) over >> diverse paths (spatial diversity) that rely on diverse radio channels >> (frequency diversity), diverse PHY technologies (e.g., narrowband >> versus spread spectrum), or diverse codes. >> --> >> >> >> Pascal > What about >> A single packet may be sent at different times (time diversity) over >> diverse paths (spatial diversity) that rely on diverse radio channels >> (frequency diversity) leveraging diverse PHY technologies (e.g., narrowband >> versus spread spectrum or diverse codes). >> >> 31) <!-- [rfced] Is "point of local reaction" correct here? We ask because >> we see >> "Point of Local Repair" elsewhere in the document, including in Section >> 6.5 (mentioned in this sentence). >> >> Original: >> The PLR (see Section 6.5) is a point of >> local reaction to provide additional agility against transmission >> loss. >> >> Perhaps: >> The PLR (see Section 6.5) >> provides additional agility against transmission >> loss. >> --> >> >> Pascal> Please use "perhaps" . >> >> 32) <!-- [rfced] How may we update "includes may be a time-aggregated (e.g., >> statistical) fashion" for clarity? >> >> Original: >> The information that the orientation function reports to the routing >> function includes may be a time-aggregated, e.g., statistical >> fashion, to match the longer-term operation of the routing function. >> >> Perhaps: >> The information that the orientation function reports to the routing >> function may be time aggregated (e.g., statistical), >> to match the longer-term operation of the routing function. >> --> >> >> Pascal> Please use "perhaps" . >> >> 33) <!-- [rfced] Will readers understand what "it" refers to in this >> sentence? >> >> Original: >> RAW improves the reliability of transmissions and the availability of >> the communication resources, and should be seen as a dynamic >> optimization of the use of redundancy to maintain it within certain >> boundaries. >> >> Perhaps: >> RAW improves the reliability of transmissions and the availability of >> the communication resources and should be seen as a dynamic >> optimization of the use of redundancy to maintain reliability and >> availability >> within certain boundaries. >> --> >> >> >> Pascal> added "metrics" as follows >> RAW improves the reliability of transmissions and the availability of >> the communication resources and should be seen as a dynamic >> optimization of the use of redundancy to maintain reliability and >> availability metrics >> within certain boundaries. >> >> >> 34) <!-- [rfced] Please review the paragraphs before Figure 6 (strict model) >> and >> Figure 7 (loose model) and let us know if any changes are needed to place >> text about the loose model together before Figure 7. >> --> >> >> >> 35) <!-- [rfced] FYI - We have adjusted the titles of Figures 6 and 7 to >> make them >> consistent with one another; please review. >> >> Original: >> >> Figure 6: (Strict) RAW over DetNet >> Figure 7: Loose RAW >> >> >> Current: >> >> Figure 6: RAW over DetNet (Strict Model) >> Figure 7: RAW over DetNet (Loose Model) >> --> >> >> >> Pascal> OK >> >> >> 36) <!-- [rfced] Some of the items in the numbered list in Section 6 are >> complete >> sentences and others are not. How may we update to create parallel >> structure? >> >> Original: >> 1. Operational Plane measurement protocols for OAM to observe (like >> the first O in OODA) some or all hops along a recovery graph as >> well as the end-to-end packet delivery. >> >> 2. The DetNet Controller Plane establish primary and protection >> paths for use by the RAW Network Plane. ... >> >> 3. A PLR operates at the DetNet Service sub-layer and hosts the >> decision function (like the D in OODA) of which DetNet Paths to >> use for the future packets that are routed within the recovery >> graph. >> >> 4. Service protection actions that are actuated or triggered over >> the LL API by the PLR to increase the reliability of the end-to- >> end transmissions. ... >> >> Perhaps (make #1 and #4 into complete sentences): >> 1. Operational Plane measurement protocols allow OAM to observe (like >> the first "O" in "OODA") some or all hops along a recovery graph as >> well as the end-to-end packet delivery. >> >> 2. The DetNet Controller Plane establishes primary and protection >> paths for use by the RAW Network Plane. ... >> >> 3. A PLR operates at the DetNet Service sub-layer and hosts the >> decision function (like the D in OODA). The decision function >> determines >> which DetNet Paths will be >> used for future packets that are routed within the recovery >> graph. >> >> 4. Service protection actions are actuated or triggered over >> the LL API by the PLR to increase the reliability of the end-to- >> end transmissions. ... >> --> >> >> >> Pascal> Please use "perhaps". >> >> 37) <!-- [rfced] How may we clarify "builds reports to the routing function"? >> >> Original: >> The interaction between the network nodes and the routing function is >> handled by the orientation function, which builds reports to the >> routing function and sends control information in a digested form ... >> >> Perhaps: >> The interaction between the network nodes and the routing function is >> handled by the orientation function, which builds reports for the >> routing function and sends control information in a digested form ... >> >> Or: >> The interaction between the network nodes and the routing function is >> handled by the orientation function, which reports to the >> routing function and sends control information in a digested form ... >> --> >> >> >> Pascal> Please use "Or". >> >> 38) <!-- [rfced] Will readers understand what "Assurance" means here? We do >> not >> see this used elsewhere in the document. >> >> Original: >> Finally, the RAW Service sub-layer Assurance may observe the >> individual PREOF operation of a DetNet Relay Node to ensure that it >> is conforming; >> --> >> >> >> Pascal > Please replace "Assurance " with "Service Assurance" >> >> 39) <!-- [rfced] What is being connected by "either" in the phrase "either >> or a >> collection of those access links". How should this text be clarified? >> >> Original: >> ; still the RAW OAM measures the end-to-end latency and delivery >> ratio for packets sent via RAN 1, RAN 2, and RAN 3, and determines >> whether a packet should be sent over either or a collection of those >> access links. >> --> >> >> >> Pascal > Please replace " either " with " either access link " (I mean we >> use a single or a collection of the possible links.) >> >> 40) <!-- [rfced] This sentence does not parse. Please clarify. >> >> Original: >> The OODA Loop controls, within the redundant solutions that are proposed by >> the routing function, which is used for each packet to provide a Reliable >> and >> Available service while minimizing the waste of constrained resources. >> >> Perhaps: >> Within the redundant solutions that are proposed by >> the routing function, the OODA Loop controls what is used for each packet >> and >> provides a reliable and >> available service while minimizing the waste of constrained resources. >> --> >> >> Pascal> Please use "perhaps". >> >> >> 41) <!-- [rfced] This sentence is difficult to follow. We updated as shown >> below. >> Please review and to confirm that the updated text accurately conveys the >> intended meaning. >> >> Original: >> The PLR operates on metrics that evolve faster, but that need to be >> advertised at a fast rate but only locally, within the recovery >> graph, and reacts on the metric updates by changing the DetNet path >> in use for the affected flows. >> >> Updated: >> The PLR operates on metrics that evolve quickly and need to be >> advertised at a fast rate (but only locally, within the recovery >> graph), and the PLR reacts to the metric updates by changing the DetNet >> path >> in use for the affected flows. >> --> >> >> >> >> Pascal> OK >> >> 42) <!-- [rfced] Please clarify "more typical to wireless than wired". >> >> Original: >> The LL API enriches the DetNet protection services (PREOF) with >> potential possibility to interact with lower-layer one-hop >> reliability functions that are more typical to wireless than wired, >> including ARQ, FEC, and other techniques such as overhearing and >> constructive interferences. >> >> Perhaps: >> The LL API enriches the DetNet protection services (PREOF) with the >> possibility to interact with lower-layer, one-hop >> reliability functions that are more typical with wireless links than with >> wired ones, >> including ARQ, FEC, and other techniques such as overhearing and >> constructive interferences. >> --> >> >> >> Pascal> Please use "perhaps". >> >> >> 43) <!-- [rfced] Should "may typically select" be updated to "may select" or >> "typically selects"? >> >> Original: >> A RAW policy may typically select the cheapest collection of links >> that matches the requested SLA, e.g., use free Wi-Fi vs. paid 3GPP >> access. >> >> Perhaps: >> A RAW policy may select the cheapest collection of links >> that matches the requested SLA, e.g., use free Wi-Fi vs. paid 3GPP >> access. >> >> Or: >> A RAW policy typically selects the cheapest collection of links >> that matches the requested SLA, e.g., use free Wi-Fi vs. paid 3GPP >> access. >> --> >> >> >> Pascal> Please use "Or". >> >> 44) <!-- [rfced] Would you like the references to be alphabetized >> or left in their current order? >> --> >> >> >> Pascal> Please do >> >> 45) <!-- [rfced] Terminology: >> >> a) "sub-layer" (with hyphen) is used consistently in this document, but >> "sublayer" (no hyphen) is used in the other documents in cluster 538 >> (draft-ietf-raw-technologies and draft-ietf-roll-dao-projection). May we >> update usage in this document to align with the other documents in the >> cluster? Note that we see mixed usage in past RFCs; for example, RFC 9030 >> uses "sublayer", but RFC 8655 uses "sub-layer". >> >> >> Pascal> Ideally we'd update draft-ietf-raw-technologies to use hyphen if >> that's possible? DAO projection may remain as is by consistency to RFC 9030. >> >> b) We note the following capitalization inconsistencies in the names of >> nodes. Please review and let us know how to update for consistency. >> >> RAW Node >> RAW node >> >> Ingress Node >> Ingress node >> >> Egress Node >> Egress node >> >> DetNet Edge nodes >> DetNet Edge Nodes >> edge nodes >> >> DetNet Transit Nodes >> DetNet Transit nodes >> transit node >> >> DetNet Relay Node >> >> >> Pascal > please use lowercase for "node" in every usage above >> >> c) We also note inconsistencies in the terms below throughout the text. >> Should >> these be uniform? If so, please let us know which form is preferred. >> >> RAW OAM >> RAW / OAM >> >> DetNet Path >> DetNet path >> >> Protection Path >> protection path >> >> path selection >> Path selection (i.e., DetNet Path selection) >> Path Selection (i.e., RAW Path Selection) >> >> Control Loop >> control loop >> >> OODA Loop >> OODA loop >> >> Segment >> segment >> >> Ingress >> ingress >> >> Egress >> egress >> >> DetNet Forwarding sub-layer >> DetNet forwarding sub-layer >> >> Controller Plane >> controller plane >> >> >> Pascal > Please use >> >> RAW OAM >> DetNet path >> protection path >> path selection >> control loop >> OODA loop >> segment >> ingress >> egress >> DetNet forwarding sub-layer >> Controller Plane >> >> d) FYI - We updated "gNb" to "gNB" to align with usage in RFC-to-be 9913 aka >> draft-ietf-raw-technologies-17 and other documents in the RFC Series. >> --> >> >> >> Pascal > OK >> >> 46) <!-- [rfced] Abbreviations >> >> a) Below is the first instance of "PHY" in this document. How should this be >> expanded? As "Physical"? >> >> Original: >> Furthermore, the different RAW technologies are equipped with >> different reliability features, e.g., short range broadcast, >> Multiple-User, Multiple-Input, and Multiple-Output (MUMIMO), PHY rate >> and other Modulation Coding Scheme (MCS) adaptation, coding and >> retransmissions methods, constructive interference and overhearing, >> see [RAW-TECHNOS] for details. >> >> >> >> Pascal> please change "PHY" to "physical layer (PHY)" >> b) FYI - We updated the expansion of SNR as follows to align with the >> expansion used in previous RFCs. >> >> Original: >> Signal-Noise Ratio >> >> Updated: >> Signal-to-Noise Ratio >> >> >> >> Pascal > OK >> >> >> c) FYI - We have added expansions for abbreviations upon first use >> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >> expansion in the document carefully to ensure correctness. >> >> Deterministic Networking (DetNet) >> Dynamic Link Exchange Protocol (DLEP) >> Differentiated Services Code Point (DSCP) >> Static Context Header Compression (SCHC) >> Bidirectional Forwarding Detection (BFD) >> Media Access Control (MAC) >> --> >> >> >> >> Pascal > OK >> >> 47) <!-- [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. >> >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> --> >> >> >> >> >> Pascal > OK >> >> Then again, many thanks! >> >> all the best, >> >> Pascal > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
