Hi Janos, Pascal,
Thank you both for your replies. You may find the updated files at the end of
this email.
We have one follow-up note:
> 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.
> -->
>
> <JF>
> The text could be updated to:
> "RAW inherits and augments the IETF recovery such as seen in DetNet and
> Traffic Engineering, e.g., RFC 8655 and RFC 4090."
>
> Note that this is also in-line with the use of term "recovery" in the cited
> text in item 9).
>
> </JF>
For item #8 above, we have updated as follows (per Janos’s request and to align
more closely with the text in item #9).
Please review and let us know if this update is suitable:
Current:
RAW inherits and augments the IETF term "recovery" as seen in DetNet and
Traffic Engineering, e.g., [DetNet-ARCHI] and [RFC4090].
Upon careful review, please contact us with any further updates or with your
approval of the document in its current form.
Please review the document carefully to ensure satisfaction as we do not make
changes once it has been published as an RFC.
The AUTH48 status page for this document is available here:
https://www.rfc-editor.org/auth48/rfc9912
— 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 between the last and current version:
https://www.rfc-editor.org/authors/rfc9912-lastdiff.html
https://www.rfc-editor.org/authors/rfc9912-lastrfcdiff.html (side by side)
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)
Thank you,
Kaelin Foody
RFC Production Center
> On Feb 16, 2026, at 2:48 PM, Janos Farkas
> <[email protected]> wrote:
>
> Hi,
>
> Many thanks for your efforts with this draft!
>
> Please find below some ideas from my side, marked by <JF>.
>
> Best regards,
> János
>
>
> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: Tuesday, February 10, 2026 6:54 AM
> To: [email protected]
> Cc: [email protected]; [email protected]; [email protected];
> Janos Farkas <[email protected]>; [email protected];
> [email protected]
> Subject: [AD] Re: AUTH48: RFC-to-be 9912 <draft-ietf-raw-architecture-30> for
> your review
>
> 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.
> -->
>
> <JF>
> The text could be updated to:
> "RAW inherits and augments the IETF recovery such as seen in DetNet and
> Traffic Engineering, e.g., RFC 8655 and RFC 4090."
>
> Note that this is also in-line with the use of term "recovery" in the cited
> text in item 9).
>
> </JF>
>
>
> 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].
>
> <JF>
> I'd suggest to keep it "IEEE 802" because IEEE is very broad and 802 gives a
> hint/mark. (IEEE includes, e.g., publication not just Standards Association.
> SA is very broad too.)
> </JF>
>
>
> 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].
> -->
>
> <JF>
> I think the intent with this sentence is:
> "Wireless TSN (WTSN) denotes extensions of the TSN work on wireless, e.g.,
> the RAW technologies described in [RAW-TECHNOS]."
>
> What I'm getting to is that, for WTSN, some people may chose some wireless
> technologies that are not listed in [RAW-TECHNOS]."
> </JF>
>
>
> 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]
