Hi Kaelin & Rebecca, You have my approval for (1).
Thanks, Ketan On Tue, Feb 10, 2026 at 11:23 AM <[email protected]> wrote: > 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". > --> > > > 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 > --> > > > 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. > --> > > > 4) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> > > > 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. > --> > > > 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. > --> > > > 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]. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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 > --> > > > 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. > > > 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. > --> > > > 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. > --> > > > 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]. > --> > > > 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. > > --> > > > 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. > --> > > > 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. > > > 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. > --> > > > 19) <!-- [rfced] FYI - For Figure 3, we moved the information about the > segments > and paths out of the figure. > --> > > > 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. > --> > > > 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]. > > > 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]. > --> > > > 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). > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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].) > --> > > > 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]. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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) > --> > > > 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. ... > --> > > > 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 ... > --> > > > 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; > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 44) <!-- [rfced] Would you like the references to be alphabetized > or left in their current order? > --> > > > 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". > > > 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 > > > 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 > > > 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. > --> > > > 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. > > > 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 > > > 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) > --> > > > 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. > --> > > > Thank you. > > Kaelin Foody and Rebecca VanRheenen > RFC Production Center > > > > *****IMPORTANT***** > > Updated 2026/02/09 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * [email protected] (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * [email protected], which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > [email protected] will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9912.xml > https://www.rfc-editor.org/authors/rfc9912.html > https://www.rfc-editor.org/authors/rfc9912.pdf > https://www.rfc-editor.org/authors/rfc9912.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9912-diff.html > https://www.rfc-editor.org/authors/rfc9912-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9912-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9912 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9912 (draft-ietf-raw-architecture-30) > > Title : Reliable and Available Wireless Architecture > Author(s) : P. Thubert > WG Chair(s) : Lou Berger, János Farkas > > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
