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. > 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. > 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. 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. > --> > 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. > --> > 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. > --> — 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]
