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