Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!-- [rfced] Should "/" here be updated to "or" or "and"? Original: This document surveys the short and middle range radio technologies that are suitable to provide a Deterministic Networking / Reliable and Available Wireless (RAW) service over, presents the characteristics that RAW may leverage, and explores the applicability of the technologies to carry deterministic flows, as of its time of publication. Perhaps: This document surveys the short- and middle-range radio technologies over which providing Deterministic Networking (DetNet) or Reliable and Available Wireless (RAW) service is suitable, presents the characteristics that RAW may leverage, and explores the applicability of the technologies to carry deterministic flows, as of the time of publication. --> 3) <!-- [rfced] The series in this sentence is difficult to read because of the many commas. We have updated to use semicolons to separate the items in the series as shown below; please review for accuracy. Original: The control loop involves communication monitoring through Operations, Administration and Maintenance (OAM), path control through a Path computation Element (PCE) and a runtime distributed Path Selection Engine (PSE) and extended packet replication, elimination, and ordering functions (PREOF). Current: The control loop involves communication monitoring through Operations, Administration, and Maintenance (OAM); path control through a Path Computation Element (PCE) and a runtime distributed Path Selection Engine (PSE); and extended Packet Replication, Elimination, and Ordering Functions (PREOF). --> 4) <!-- [rfced] We updated this text to point to Section 3 instead of Section 2 of draft-ietf-raw-architecture (RFC-to-be 9912). Please confirm. Original: This document uses the terminology and acronyms defined in Section 2 of [RFC8655] and Section 2 of [I-D.ietf-raw-architecture]. Updated: This document uses the terminology and acronyms defined in Section 2 of [RFC8655] and Section 3 of [RFC9912]. --> 5) <!-- [rfced] Please review the titles of Sections 4-7 (the sections for the technologies reviewed by this document). Would it be helpful to readers to update the titles of Sections 4 and 5 as shown below? Note that the suggested aligns with the last sentence in the abstract and a similar sentence in the Introduction. Original: 4. IEEE 802.11 5. IEEE 802.15.4 Timeslotted Channel Hopping 6. 5G 7. L-band Digital Aeronautical Communications System Perhaps: 4. Wi-Fi 5. Time-Slotted Channel Hopping (TSCH) 6. 5G 7. L-band Digital Aeronautical Communications System (LDACS) --> 6) <!-- [rfced] Please clarify "for uses case with". Original: In parallel, the Avnu Alliance [Avnu], which focuses on applications of TSN for real time data, formed a workgroup for uses case with TSN capabilities over wireless, leveraging both 3GPP and IEEE Std 802.11 standards. Perhaps: In parallel, the Avnu Alliance [Avnu], which focuses on applications of TSN for real-time data, formed a workgroup to investigate TSN capabilities over wireless, leveraging both 3GPP and IEEE Std 802.11 standards. --> 7) <!-- [rfced] Will readers understand what "the latter" is here? Original: To achieve the latter, the reliability must be handled at an upper layer that can select Wi-Fi and other wired or wireless technologies for parallel transmissions. --> 8) <!-- [rfced] Should "AIEEE802.11-2016" be updated to "IEEE802.11-2016" (no "A")? If "AIEEE802.11-2016" is correct, is a reference needed? If so, please provide it. Original: Stream Reservation Protocol (part of [IEEE Std 802.1Qat]): AIEEE802.11-2016 --> 9) <!-- [rfced] How may we revise the phrase "to increase efficiency, control and reduce latency" to clarify how the word "control" should be understood? Original: The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax amendment [IEEE Std 802.11ax], which includes specific capabilities to increase efficiency, control and reduce latency. Perhaps: The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax amendment [IEEE Std 802.11ax], which includes specific capabilities to increase efficiency and to control and reduce latency. Or: The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax amendment [IEEE Std 802.11ax], which includes specific capabilities to increase efficiency and control and to reduce latency. --> 10) <!-- [rfced] Would you like to update the following long sentence to be a bulleted list? Or do you prefer the original? Original: Such flexibility can be leveraged to support time-sensitive applications with bounded latency, especially in a managed network where stations can be configured to operate under the control of the AP, in a controlled environment (which contains only devices operating on the unlicensed band installed by the facility owner and where unexpected interference from other systems and/or radio access technologies only sporadically happens), or in a deployment where channel/link redundancy is used to reduce the impact of unmanaged devices/ interference. Perhaps: Such flexibility can be leveraged to support time-sensitive applications with bounded latency, especially: * in a managed network where stations can be configured to operate under the control of the AP, * in a controlled environment (which contains only devices operating on the unlicensed band installed by the facility owner and where unexpected interference from other systems and/or radio access technologies only sporadically happens), or * in a deployment where channel and link redundancy is used to reduce the impact of unmanaged devices and interference. --> 11) <!-- [rfced] How may we clarify "and potential solution directions"? Original: The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) provided detailed information on use cases, issues and potential solution directions to improve support for time-sensitive applications in 802.11. Perhaps: The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) provided detailed information on use cases, issues, and a potential solution to improve support for time-sensitive applications in 802.11. --> 12) <!-- [rfced] We were unable to find RPL explicitly mentioned in RFC 8480. Should this citation be updated? Perhaps to [RFC6550]? Original: RPL [RFC8480] provides the routing structure, enabling the 6TiSCH devices to establish the links with well connected neighbours and thus forming the acyclic network graphs. --> 13) <!-- [rfced] In the two instances below, may we update "the application to wireless" to "applied to" as follows? Also, should these sentences be more closely aligned? In particular, should the phrases "concept of a recovery graph in the RAW architecture" and "concept of a DetNet architecture protection path applied to 6TiSCH networks" be aligned? Original: A Track at 6TiSCH is the application to wireless of the concept of a Recovery Graph in the RAW architecture. ... A Track in the 6TiSCH Architecture [RFC9030] is the application to 6TiSCH networks of the concept of a protection path in the "Detnet architecture" [RFC8655]. Perhaps: In 6TiSCH, a Track is the concept of a recovery graph in the RAW architecture applied to wireless. ... In the 6TiSCH architecture [RFC9030], a Track is the concept of a DetNet architecture protection path applied to 6TiSCH networks. --> 14) <!-- [rfced] FYI - We have added the verb "occurs" for clarity in the text below. Please review. Original: Each device has its own perspective of when the send or receive and on which channel the transmission happens. Current: Each device has its own perspective of when the send or receive occurs and on which channel the transmission happens. --> 15) <!-- [rfced] How may we revise "at the MAC introducing" to increase clarity? Original: Part of these reliability challenges are addressed at the MAC introducing redundancy and diversity, thanks to channel hopping, scheduling and ARQ policies. Perhaps: Part of these reliability challenges are addressed at the MAC layer by introducing redundancy and diversity, thanks to channel hopping, scheduling, and ARQ policies. --> 16) <!-- [rfced] Should "simplest and fastest" be updated to "simplest and fastest operation" (or something similar)? Original: Track Forwarding is the simplest and fastest. Perhaps: Track Forwarding is the simplest and fastest operation. --> 17) <!-- [rfced] Will "this means effectively broadcast" be clear to readers? Original: In the case of IEEE802.15.4, this means effectively broadcast, so that along the Track the short address for the destination of the frame is set to 0xFFFF. Perhaps: In the case of IEEE 802.15.4, this effectively means that the address is broadcast, so that the short address for the destination of the frame is set to 0xFFFF along the Track. --> 18) <!-- [rfced] Please clarify "to trade-off performance to reliability". Does the suggested text below convey the intended meaning? Original: As a low power technology targeting industrial scenarios radio transducers provide low data rates (typically between 50kbps to 250kbps) and robust modulations to trade-off performance to reliability. Perhaps: As a low-power technology targeting industrial scenarios, radio transducers provide low data rates (typically between 50 kbps to 250 kbps) and robust modulations to trade off performance for reliability. --> 19) <!-- [rfced] Should "tight control to latency" be updated to "tight control of latency" (i.e., "of" rather than "to")? Or is the current okay? Original: This provides a tight control to latency along a Track. Perhaps: This provides a tight control of latency along a Track. --> 20) <!-- [rfced] How may we update the the text starting with "in particular..." to clarify what is provided to a PCE? Original: Rather, an Operation Control System (OCS) invoked through a Human/Machine Interface (HMI) provides the Traffic Specification, in particular in terms of latency and reliability, and the end nodes, to a PCE. Perhaps: Rather, an Operation Control System (OCS) invoked through a Human/Machine Interface (HMI) provides the traffic specification (in particular, in terms of latency and reliability) and the end nodes to a PCE. Or: Rather, an Operation Control System (OCS) invoked through a Human/Machine Interface (HMI) provides the traffic specification (in particular, in terms of latency, reliability, and the end nodes) to a PCE. --> 21) <!-- [rfced] Will readers understand "(to be)" in this sentence? Should it be removed or clarified? Original: For that case, the expectation is that a protocol that flows along a Track (to be), in a fashion similar to classical Traffic Engineering (TE) [CCAMP], may be used to update the state in the devices. Perhaps (remove "to be"): For that case, the expectation is that a protocol that flows along a Track, in a fashion similar to classical Traffic Engineering (TE) [CCAMP], may be used to update the state in the devices. --> 22) <!-- [rfced] What is meant by "Stream Management Entity" above Figure 2? Should this be expanded into a complete sentence or handled in some other way? --> 23) <!-- [rfced] We have moved the text below from the title of Figure 4 and added it to the text introducing the figure. Please review. Also, please clarify "twice" here. Would updating as follows (move "twice", add colon, and add "once") convey the intended meaning? Original: S transmits twice the same data packet, to its Destination Parent (DP) (A) and to its Alternate Parent (AP) (B). Perhaps: In the figure above, S transmits the same data packet twice: once to its Destination Parent (DP) (A) and once to its Alternate Parent (AP) (B). --> 24) <!-- [rfced] Please clarify the text starting with ", and does not need". Original: As it goes, 6TiSCH expects that timeSlots corresponding to copies of a same packet along a Track are correlated by configuration, and does not need to process the sequence numbers. Perhaps: As it goes, 6TiSCH expects that timeSlots corresponding to copies of the same packet along a Track are correlated by configuration, so processing the sequence numbers is not needed. --> 25) <!-- [rfced] FYI - We added "policies that" after "for instance" in the text below. Please confirm that this is correct. Original: The PCE should be able to compute Tracks that will implement policies on how the energy is consumed, for instance balance between nodes and ensure that the spent energy does not exceeded the scavenged energy over a period of time. Perhaps: The PCE should be able to compute Tracks that will implement policies on how the energy is consumed, for instance, policies that balance between nodes and ensure that the spent energy does not exceed the scavenged energy over a period of time. --> 26) <!-- [rfced] Should "device perspective" here be updated to "device's perspective" (with 's)? Or is another meaning intended? Original: The slotFrame is a device perspective of a transmission schedule; there can be more than one with different priorities so in case of a contention the highest priority applies. --> 27) <!-- [rfced] We were unable to find a section titled "SlotFrames and Priorities" in RFC 9030. Should the text below reference Section 4.3.5 of RFC 9030 (titled "Slotframes and CDU Matrix") instead? Original: Elaboration on that concept can be found in section "SlotFrames and Priorities" of [RFC9030], and figures 17 and 18 of [RFC9030] illustrate that projection. Perhaps: Elaboration on that concept can be found in Section 4.3.5 of [RFC9030], and Figures 17 and 18 of [RFC9030] illustrate that projection. --> 28) <!-- [rfced] Will "When thereupon UL resources are scheduled to the UE" be clear to readers? Original: When thereupon UL resources are scheduled to the UE, the UE can transmit its data and may include a buffer status report, indicating the exact amount of data per logical channel still left to be sent. Perhaps: When UL resources are scheduled, the UE can transmit its data and may include a buffer status report that indicates the exact amount of data per logical channel still left to be sent. --> 29) <!-- [rfced] Please clarify "This way, e.g., " in the second sentence below. Also, in the third sentence, what does "partly Release 16" mean? The first sentence below is included for context. Original: To support QoS enforcement in the case of mixed traffic with different QoS requirements, several features have recently been introduced. This way, e.g., different periodical critical QoS flows can be served together with best effort transmissions, by the same UE. Among others, these features (partly Release 16) are: Perhaps: To support QoS enforcement in the case of mixed traffic with different QoS requirements, several features have recently been introduced. These features allow different periodical critical QoS flows to be served, together with best-effort transmissions, by the same UE. These features (partly discussed in Release 16) include the following: --> 30) <!-- [rfced] Please clarify "such that the meet their QoS requirements". Original: 3GPP Release 16 includes integration of 5G with TSN, i.e., specifies functions for the 5G System (5GS) to deliver TSN streams such that the meet their QoS requirements. Perhaps: 3GPP Release 16 includes integration of 5G with TSN, i.e., specifies functions for the 5G System (5GS) to deliver TSN streams so that the QoS requirements are met. --> 31) <!-- [rfced] May we update this sentence for clarity? We suggest moving "from the rest of the network" to appear before "the 5GS" and adding parentheses around the "in particular..." phrase. Original: A key aspect of the integration is the 5GS appears from the rest of the network as a set of TSN bridges, in particular, one virtual bridge per User Plane Function (UPF) on the user plane. Perhaps: A key aspect of the integration is that, from the rest of the network, the 5GS appears as a set of TSN bridges (in particular, one virtual bridge per User Plane Function (UPF) on the user plane). --> 32) <!-- [rfced] Please clarify "hence, can be integrated" in these list items. Original: 3. low latency, hence, can be integrated with Scheduled Traffic [IEEE802.1Qbv] 4. reliability, hence, can be integrated with FRER [IEEE802.1CB] Perhaps: 3. low latency, which allows integration with Scheduled Traffic [IEEE802.1Qbv] 4. reliability, which allows integration with FRER [IEEE802.1CB] --> 33) <!-- [rfced] How may we update the text starting with "making it general for TSC with..." to improve readability? Original: More extensions and flexibility were added to the time synchronization service making it general for TSC with additional support of other types of clocks and time distribution such as boundary clock, transparent clock peer- to-peer, transparent clock end-to-end, aside from the time-aware system used for TSN. Perhaps: More extensions and flexibility were added to the time synchronization service, making it general for TSC and providing additional support for other types of clocks and time distribution such as boundary clocks and transparent clocks (both peer- to-peer and end-to-end) aside from the time-aware system used for TSN. --> 34) <!-- [rfced] In the text below, please confirm that "Figure 11" is correct. We ask because we do not see "UPF" or "Virtual TSN Bridge granularity" in Figure 11 of this document. Original: The study provides details on how the 5GS is exposed by the Time Sensitive Communication and Time Synchronization Function (TSCTSF) to the DetNet controller as a router on a per UPF granularity (similarly to the per UPF Virtual TSN Bridge granularity shown in Figure 11). --> 35) <!-- [rfced] Should "Figure 9" be updated to "Figure 8" in the sentence below? The text indicates a single UE. Also, we do not see Figure 8 discussed or introduced elsewhere in the text. Original: Redundant user plane paths can be provided based on the dual connectivity architecture, where the UE sets up two PDU sessions towards the same data network, and the 5G system makes the paths of the two PDU sessions independent as illustrated in Figure 9. --> 36) <!-- [rfced] Would adding citations for "FRER or as PREOF specifications" here be helpful to the reader? If so, please let us know which references to include. Original: There is no single point of failure in this solution, which also includes RHF outside of the 5G system, e.g., as per FRER or as PREOF specifications. --> 37) <!-- [rfced] How may we clarify "make 5G equally supporting"? Also, should "FRER of TSN and PREOF of DetNet" be updated to "FRER in TSN and PREOF in DetNet"? Original: Note that the abstraction provided by the RHF and the location of the RHF being outside of the 5G system make 5G equally supporting integration for reliability both with FRER of TSN and PREOF of DetNet as they both rely on the same concept. Perhaps: Note that the abstraction provided by the RHF and the location of the RHF outside of the 5G system allow 5G to support integration for reliability with both FRER in TSN and PREOF in DetNet, as they both rely on the same concept. --> 38) <!-- [rfced] FYI - We moved the first sentence below to appear before Figures 11 and 12. Let us know any concerns. Original: This fixed frame structure allows for a reliable and dependable transmission of data. Next, the LDACS medium access layer is introduced: --> 39) <!-- [rfced] Would you like the references to be alphabetized or left in their current order? --> 40) <!-- [rfced] Note that we removed spaces from some citation tags per Section 3.5 of RFC 7322 ("RFC Style Guide"). For example: Original: [IEEE Std 802.15.4] Updated: [IEEE802.15.4] --> 41) <!-- [rfced] This reference points to a superseded version of IEEE Std 802.11; the most recent version was approved in 2024. May we update this reference to point to the most current version? See: https://ieeexplore.ieee.org/document/9363693 (superseded) https://ieeexplore.ieee.org/document/10979691 (most current) Original: [IEEE Std 802.11] IEEE standard for Information Technology, "IEEE Standard 802.11 - IEEE Standard for Information Technology - Telecommunications and information exchange between systems Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.", <https://ieeexplore.ieee.org/document/9363693>. --> 42) <!-- [rfced] This reference points to a superseded IEEE Std from 2018. The newest version of this IEEE Std was published in 2022. May we update this reference to point to the most recent version of the standard? See: https://ieeexplore.ieee.org/document/8457469 (superseded) https://ieeexplore.ieee.org/document/9844436 (most current) Original: [IEEE802.3] IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018, <https://ieeexplore.ieee.org/document/8457469>. --> 43) <!-- [rfced] This reference has been superseded, but we cannot locate a more recent version. Please review and let us know if any updates are needed or if the current is correct. See: https://ieeexplore.ieee.org/document/9442429 (superseded) Original: [IEEE Std 802.11ax] IEEE standard for Information Technology, "802.11ax: Enhancements for High Efficiency WLAN", 2021, <https://ieeexplore.ieee.org/document/9442429>. --> 44) <!-- [rfced] Note that we have made substantial updates to the References section of this document for consistency and access. We have added URLs and/or DOIs, and we have corrected some incorrect reference information such as missing authors, incorrect dates, etc. We have already updated the references below as follows. Please review for accuracy and let us know if you have any objections. a) Based on the context of the citations to this reference, we updated this reference entry to point to the 2015 revision. Original: [IEEE Std 802.15.4] IEEE standard for Information Technology, "IEEE Std 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks". Updated: [IEEE802.15.4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Std 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, <https://doi.org/10.1109/IEEESTD.2016.7460875>. b) We updated this reference entry as shown below as it is now published as an IEEE standard. Original: [IEEE 802.11be] IEEE standard for Information Technology, "802.11be: Extreme High Throughput PAR", <https://mentor.ieee.org/802.11/dcn/18/11-18-1231-04-0eht- eht-draft-proposed-par.docx>. Updated: [IEEE802.11be] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 2: Enhancements for Extremely High Throughput (EHT)", IEEE Std 802.11be-2024, DOI 10.1109/IEEESTD.2024.11090080, <https://ieeexplore.ieee.org/document/11090080>. c) The original URL for this reference pointed to a page that results in a 404 error. We have updated the URL and reference to point to the home page for ISA100 Wireless. Original: [ISA100.11a] ISA/IEC, "ISA100.11a, Wireless Systems for Automation, also IEC 62734", 2011, <http://www.isa100wci.org/en- US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch- WEB-ETSI.aspx>. Updated: [ISA100.11a] ISA, "ISA100 Wireless", ANSI/ISA-100.11a-2011 (IEC 26743), <https://isa100wci.org/about-isa100-wireless?_gl=1*19xrxgo *_up*MQ..*_ga*NDczNjkxOTQ1LjE3NjI0NjQ2NDk.*_ga_L2KSW4EHCS* czE3NjI0NjQ2NDkkbzEkZzEkdDE3NjI0NjQ3MzQkajYwJGwwJGgw>. d) The original URL for this reference redirects to a page for the FieldComm Group (https://www.fieldcommgroup.org/). Original URL: www.hartcomm.org There is a specific page for WirelessHART here: https://www.fieldcommgroup.org/technologies/wirelesshart. However, this does not match the original title of this reference. The original title of this reference seems to be pointing to IEC 62951, which can be found at this URL: https://webstore.iec.ch/en/publication/24433 We have updated this reference based of the information available at the redirected URL to point to FieldComm Group's page for WirelessHART. Please let us know if you would prefer to point to the IEC page. Original: [WirelessHART] www.hartcomm.org, "Industrial Communication Networks - Wireless Communication Network and Communication Profiles - WirelessHART - IEC 62591", 2010. Updated: [WirelessHART] FieldComm Group, "WirelessHART", <https://www.fieldcommgroup.org/technologies/ wirelesshart>. e) The original title for this reference doesn't match the title at the URL. We have updated this reference to match the URL. Original: [IMT2020] "ITU towards IMT for 2020 and beyond", <https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-2020/Pages/default.aspx>. Updated: [IMT2020] ITU, "IMT-2020 (a.k.a. "5G")", <https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-2020/Pages/default.aspx>. f) The original URL for this reference results in a 404 error. We found the following URL, which matches the information for this reference, but M. Schnell is not the author of this article. We have updated the reference accordingly. Original: [SCH19] Schnell, M., "DLR tests digital communications technologies combined with additional navigation functions for the first time", 3 March 2019, <https://www.dlr.de/dlr/en/desktopdefault.aspx/tabid- 10081/151_read-32951/#/gallery/33877>. Current: [SCH19] German Aerospace Center (DLR), "DLR tests digital communications technologies combined with additional navigation functions for the first time", 27 March 2019, <https://www.dlr.de/en/latest/ news/2019/01/20190327_modern-technology-for-the-flight- deck>. --> 45) <!-- [rfced] In the Contributors section, would you like to point to specific section numbers? This would create links in the HTML and PDF outputs. Also, is Section 4 the "Wi-Fi section"? Will this be clear to readers? Current: * Georgios Z. Papadopoulos: Contributed to the TSCH section * Nils Maeurer: Contributed to the LDACS section * Thomas Graeupl: Contributed to the LDACS section * Torsten Dudda, Alexey Shapin, and Sara Sandberg: Contributed to the 5G section * Rocco Di Taranto: Contributed to the Wi-Fi section * Rute Sofia: Contributed to the Introduction and Terminology sections Perhaps: * Georgios Z. Papadopoulos contributed to Section 5 ("IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH)"). * Nils Maeurer and Thomas Graeupl contributed to Section 7 ("L-Band Digital Aeronautical Communications System (LDACS)"). * Torsten Dudda, Alexey Shapin, and Sara Sandberg contributed to Section 6 ("5G"). * Rocco Di Taranto contributed to Section 4 ("IEEE 802.11"). * Rute Sofia contributed to Section 1 ("Introduction") and Section 2 ("Terminology"). --> 46) <!-- [rfced] Some author comments are present in the XML. Please confirm that no updates related to these comments are needed. Note that these comments will be deleted prior to publication. --> 47) <!-- [rfced] Would you like to make use of <sup> for superscript for the two instances of "10^-5" in this document? We updated the first instance so you can see what this looks like; please review in the HTML. Note that in the HTML and PDF, it appears as superscript; in the text output, <sup> generates a^b, which is used in the original document. --> 48) <!-- [rfced] Please review "It results that" in these sentences. Would either removing this phrase or updating to "As a result", "Thus," (or something else) improve these sentences? Note that how to update may depend on context, so please review each instance in context. Original: It results that a frame that is received in a RX-cell of a Track with a destination MAC address set to this node as opposed to broadcast must be extracted from the Track and delivered to the upper layer (a frame with an unrecognized MAC address is dropped at the lower MAC layer and thus is not received at the 6top sublayer). ... It results that a frame that is received over a layer-3 bundle may be in fact associated with a Track. ... It results that the tagging that is used for a DetNet flow outside the 6TiSCH Low Power Lossy Network (LLN) must be swapped into 6TiSCH formats and back as the packet enters and then leaves the 6TiSCH network. ... It results that a node will maintain only a small number of peering information, and will not be able to store many packets waiting to be forwarded. --> 49) <!-- [rfced] Would you like to update "wide-area" and "local-area" in these sentences to "WAN" and "LAN", respectively? Or do you prefer the current? Current: With these three cornerstones, NR is a complete solution supporting the connectivity needs of consumers, enterprises, and the public sector for both wide-area and local-area (e.g., indoor) deployments. ... The 5G system allows deployment in a vast spectrum range, addressing use cases in both wide-area and local-area networks. Perhaps: With these three cornerstones, NR is a complete solution supporting the connectivity needs of consumers, enterprises, and the public sector for both WAN and LAN (e.g., indoor) deployments. ... The 5G system allows deployment in a vast spectrum range, addressing use cases in both WANs and LANs. --> 50) <!-- [rfced] Units of measure: a) We see both "ms" and "msec" used in the document. Would you like to use one form consistently or update to "millisecond" (or the plural "milliseconds" depending on context)? b) Will readers know what "1us" is here? Does this refer to microsecond (i.e., μs)? If so, may we update to use "microsecond" for clarity? Also, would updating to "in 1us accuracy level" to "with an accuracy level of 1 microsecond" improve readability? Original: NR supports accurate reference time synchronization in 1us accuracy level. Perhaps: NR supports accurate reference time synchronization with an accuracy level of 1 microsecond. --> 51) <!-- [rfced] Terminology: a) We note inconsistencies in the terms below throughout the text. Should these be uniform? If so, please let us know which form is preferred. ChannelOffset vs. channeloffset vs. channelOffset Note: "channelOffset" is used in RFCs 8480, 9030, and 9033. slotoffset vs. slotOffset Note: "slotoffset" is used in RFCs 8480, 9030, and 9033. slotFrame vs. slotframe Note: "slotframe" is used in RFC 9030. timeSlot vs. timeslot Note: "timeSlot" is used in RFC 9030. b) We see one instance each of the terms below document. Should these be updated to either "DetNet or RAW" or "DetNet and RAW"? DetNet/RAW RAW/DetNet c) FYI - This document uses a mix of British and American spellings. We updated to American spelling for consistency per Section 3.1 of RFC 7322 ("RFC Style Guide"). Note that we updated the spellings of the following words: utiliz*, neighbor, signaling, and analog. d) Some text includes "802.X" that is not prefaced by "IEEE" or "IEEE Std". Are any updated needed for these? Or is the current okay? The document includes many instances; some examples below. Original: While previous 802.11 generations, such as 802.11n and 802.11ac, have focused mainly on improving peak throughput, more recent generations are also considering other performance vectors ... ... 802.11 WLANs can also be part of a 802.1Q bridged networks with enhancements enabled by the 802.11ak amendment retrofitted in IEEE Std 802.11-2020. ... Traffic classification based on 802.1Q VLAN tags is also supported in 802.11. Other 802.1 TSN capabilities such as 802.1Qbv and 802.1CB, which are media agnostic, can already operate over 802.11. Perhaps: While previous IEEE 802.11 generations, such as IEEE 802.11n and IEEE 802.11ac, have focused mainly on improving peak throughput, more recent generations are also considering other performance vectors ... ... IEEE 802.11 WLANs can also be part of IEEE 802.1Q bridged networks with enhancements enabled by the IEEE 802.11ak amendment retrofitted in IEEE Std 802.11-2020. ... Traffic classification based on IEEE 802.1Q VLAN tags is also supported in IEEE 802.11. Other IEEE 802.1 TSN capabilities such as IEEE 802.1Qbv and IEEE 802.1CB, which are media agnostic, can already operate over IEEE 802.11. --> 52) <!-- [rfced] Abbreviations: a) How may we expand the following abbreviations? BPSK (perhaps "Binary Phase-Shift Keying"?) QPSK (perhaps "Quadrature Phase-Shift Keying"?) SAP (perhaps "Service Access Point"?) VDL (perhaps "VHF Digital Link"?) b) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Federal Communications Commission (FCC) Carrier Sense Multiple Access (CSMA) Highway Addressable Remote Transducer Protocol (HART) Routing Protocol for Low-Power and Lossy Networks (RPL) Signal-to-Noise Ratio (SNR) station (STA) Personal Area Network (PAN) gNodeB (gNB) c) FYI - "L1" and"L3" were used only once in the document, and "L2" was only used twice. We updated to use the expanded forms "Layer 1", "Layer 2", and "Layer 3". d) This document contains these similar abbreviations. Will these cause any confusion for readers? If so, we can update the 8 instances of "GS" to the expansion "ground station" (and maybe also update instances of "AS" to "aircraft station" as they are often used in the same text). We will go with your preference here. 5GS - 5G System GS - Ground Station e) We note that this document switches between using the expanded and abbreviated forms of the terms below. Would you like to expand the first instance and then use the abbreviated form thereafter? Or do you prefer the current? physical vs. PHY (for the layer) uplink vs. UL downlink vs. DL forward link vs. FL reverse link vs. RL --> 53) <!-- [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. For example, please consider whether the following should be updated: a) "master" Original: ...possibility for the TSN grandmaster clock to reside on the UE side. ... The European ATM Master Plan foresees... b) "native" Original: Moreover, providing IP service is native to 5G and 3GPP... ... NR is designed with native support of antenna arrays utilizing... --> Thank you. Kaelin Foody and Rebecca VanRheenen RFC Production Center On Feb 9, 2026, at 9:59 PM, [email protected] wrote: *****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/rfc9913.xml https://www.rfc-editor.org/authors/rfc9913.html https://www.rfc-editor.org/authors/rfc9913.pdf https://www.rfc-editor.org/authors/rfc9913.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9913-diff.html https://www.rfc-editor.org/authors/rfc9913-rfcdiff.html (side by side) Alt-diff of the text (allows you to more easily view changes where text has been deleted or moved): https://www.rfc-editor.org/authors/rfc9913-alt-diff.html Diff of the XML: https://www.rfc-editor.org/authors/rfc9913-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9913 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9913 (draft-ietf-raw-technologies-17) Title : Reliable and Available Wireless (RAW) Technologies Author(s) : P. Thubert, Ed., D. Cavalcanti, X. Vilajosana, C. Schmitt, J. Farkas 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]
