Dear co authors There's quite a bit of work in front of us here. Please review the request by the RFC editor, and make sure you reply as requested, keeping all the CC.
In order to progress swiftly, I'm splitting the email so that each of us is responsible to reply on the piece he authored. I'll mark the subset of the email for which one is responsible by placing it between <one's first name> and </one's first name>. There are cases where everybody's input is specially welcome; I used <all> </all> tagging to indicate that. @Xavi: for some of the 6TiSCH questions I provide a tentative answer with a tag Pascal>, please review and validate. @Janos: there's a question below about using abbreviations like UL and DL. My default answer would be to expand at first use and then always use UL/DL, but I'll refer to you if you have a different advice. @all: Please retain only that piece in your reply and cover all the items you can. For those you cannot address directly, please create a separate thread and I'll do my best to help. Please see below: Le mar. 10 févr. 2026 à 07:09, <[email protected]> a écrit : > 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. --> > > > <Pascal> > 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]. > --> > > </Pascal> <all> > 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) > --> > > </all> <Dave> > > 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. > --> > > </Dave> -------------------- <Xavi> > > 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. > --> > > Pascal> That's a oups, please use RFC 6550. > > 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. > --> > > Pascal> The second sentence should go away since the first is more specific. For the first, maybe: " The concept of a Track in 6TiSCH is the same as the concept of a recovery graph in the RAW architecture, applied to wireless communication. " Please remove completely the first sentence of 5.2.1 " 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]. " note that in RAW, draft-ietf-raw-architecture says: " RAW also reuses terminology defined for 6TiSCH in [6TiSCH-ARCHI <https://www.rfc-editor.org/info/rfc9030>] and equates the 6TiSCH concept of a Track with that of a recovery graph. " > > 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. > --> > > Pascal> what about " In the case of IEEE 802.15.4, this means 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. > --> > > Pascal> please use "Perhaps" > > 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. > --> > > Pascal> OK > > 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? > --> > > Pascal> Looks like a leftover to be removed > > 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. > > --> > > </Xavi> <Janos> > > 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. > --> > > </Janos> <Corinna> > > 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? > --> > > > </Corinna> <Pascal> > 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... > --> > > > </Pascal> Many thanks to yall in advance! Pascal 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 > > -- Pascal
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
