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]
