Hi Pascal, Janos, all, Thank you for sending along those additional updates. The updated files may be found at the end of this email.
Thanks for clarifying and providing that additional context regarding the superseded reference [IEEE Std 802.11ax]. Would it be suitable to proceed as follows? We will leave various references to [IEEE Std 802.11ax] as is and add additional text to the 3rd paragraph in Section 4.1, as seen below. Please let us know if either of these options works or if you have other proposed text. OLD: The IEEE Std 802.11ax-2021 defines additional scheduling capabilities that can enhance the timeliness performance in the 802.11 MAC and achieve lower-bounded latency. IEEE 802.11be introduces features to enhance the support for 802.1 TSN capabilities, especially those related to worst-case latency, reliability, and availability. NEW (new text appears at the end of the paragraph): The IEEE Std 802.11ax-2021 defines additional scheduling capabilities that can enhance the timeliness performance in the 802.11 MAC and achieve lower-bounded latency. IEEE 802.11be introduces features to enhance the support for 802.1 TSN capabilities, especially those related to worst-case latency, reliability, and availability. Note that IEEE Std 802.11ax-2021 has been incorporated into IEEE Std 802.11-2024. OR (new text appears closer to the reference): The IEEE Std 802.11ax-2021 (which has been incorporated into IEEE Std 802.11-2024) defines additional scheduling capabilities that can enhance the timeliness performance in the 802.11 MAC and achieve lower-bounded latency. IEEE 802.11be introduces features to enhance the support for 802.1 TSN capabilities, especially those related to worst-case latency, reliability, and availability. The AUTH48 status page for this document is available below: https://www.rfc-editor.org/auth48/rfc9913 — FILES (please refresh): — The updated files have been posted here: https://www.rfc-editor.org/authors/rfc9913.txt https://www.rfc-editor.org/authors/rfc9913.pdf https://www.rfc-editor.org/authors/rfc9913.html https://www.rfc-editor.org/authors/rfc9913.xml Diff files showing changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9913-auth48diff.html https://www.rfc-editor.org/authors/rfc9913-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9913-diff.html https://www.rfc-editor.org/authors/rfc9913-rfcdiff.html (side by side) Thank you, Kaelin Foody RFC Production Center > On Feb 19, 2026, at 3:34 AM, Pascal Thubert <[email protected]> wrote: > > Hello Kaelin and Janos; > > Please see below: > > Le mer. 18 févr. 2026 à 21:19, Kaelin Foody <[email protected]> a > écrit : > All, > > Thank you all for your thorough responses and reviews. > > We have updated the document to reflect responses from Pascal, Dave, Xavi, > Corinna, and Janos thus far. You may find the updated files at the end of > this email. > > We only await responses to questions 29-37. > > Pending questions are noted on the AUTH48 status page for this document below: > https://www.rfc-editor.org/auth48/rfc9913 > > > In addition, we have a few follow-up notes and questions: > > a) For question #43 below, how should we proceed with updating the superseded > reference [IEEE Std 802.11ax]? > > We ask because we are not certain if [IEEE Std 802.3-2022] is the same IEEE > standard as [IEEE Std 802.11ax]. > > A list of the active versions that replaced IEEE Std 802.11ax is available > here: https://ieeexplore.ieee.org/document/9442429/versions. > > > 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) > > <JF> > > The most recent revision of 802.3 has been completed in 2022. > > Please update the reference to IEEE Std 802.3-2022 > > I think these URLs work: > > https://standards.ieee.org/ieee/802.3/10422/ > > https://standards.ieee.org/ieee/802.3/10422/ > > </JF> > > > > > > Original: > > [IEEE Std 802.11ax] > > IEEE standard for Information Technology, "802.11ax: > > Enhancements for High Efficiency WLAN", 2021, > > <https://ieeexplore.ieee.org/document/9442429>. > > —> > > Pascal > As janos explained, amendments like 11ax are retrofitted in the next > version of the main spec they amend. Reading the question carefully, IEEE std > 802.3 is not the right target. The version of the spec that supersedes 11ax > is the next version of IEEE std 802.11 that Janos indicates in his answer. > IEEE std 802.3 is a different standard. > Note that in sections 4.1 and 4.2, the references to .11ax (and then .11be) > are voluntary and should remain as is, pointing to the amendments as opposed > to the main spec, since they indicate with which amendment and when the > functionality was introduced. Please do not change the references to .11ax > and .11be > OTOH, it is certainly sensible to indicate at the end of the 3rd paragraph of > section 4.1 that .11ax is now retrofitted and maintained in the main spec .11 > spec with the appropriate reference as Janos indicates. > > > b) All of the items below have already been updated accordingly, but please > review for accuracy: > > - For question #2 below, we have made Pascal’s requested update, but have > made slight adjustments to the punctuation for readability. Please review > these changes in the Abstract and let us know any objections. > > > 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. > > --> > > Pascal> Many replace "/" by "and more specifically" since RAW is a subset > > of detnet > > > - For question #5 below, we have left these titles as is, but we have added > "Wireless Local Area Networks (WLAN)" to the title of Section 4 per Janos’s > note. > > Pascal > Agreed > > > > 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) > > --> > > > > Pascal> I'd rather retain the original titles. Wi-Fiis a subset of 802.11 > > and the text really deals with .11 > > <JF> > > I agree with Pascal, better to keep 802.11. > > If text is wanted, then the title of the 802.11 standard could be added to > > have: > > 4. IEEE 802.11 Wireless Local Area Networks (WLAN) > > </JF> > > > Pascal > Agreed > > > - For question #51 below, note that we have updated these terms per Xavi’s > rationale. > > > 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. > > > > XV: Please align terminology with RFC 9030 and others usage: > > channelOffset > > slotOffset > > slotframe > > timeSlot > > > Pascal > Agreed > > > - For item #39 below, note that we will sort the references alphabetically > once AUTH48 is complete and all other items have been closed (as to not make > the diffs difficult to read). > > > 39) <!-- [rfced] Would you like the references to be alphabetized > > or left in their current order? > > --> > > > > Answer: This does not matter for us. It is your choice > > > > Pascal > many thanks! I believe that with the sentence discussed above at the > end of the 3rd paragraph of section 4.1, the document will be ready for > publication. > > Many thanks! > > Pascal > > > > > > — FILES (please refresh): — > > The updated files have been posted here: > https://www.rfc-editor.org/authors/rfc9913.txt > https://www.rfc-editor.org/authors/rfc9913.pdf > https://www.rfc-editor.org/authors/rfc9913.html > https://www.rfc-editor.org/authors/rfc9913.xml > > Diff files showing changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9913-auth48diff.html > https://www.rfc-editor.org/authors/rfc9913-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9913-diff.html > https://www.rfc-editor.org/authors/rfc9913-rfcdiff.html (side by side) > > > Thank you, > > Kaelin Foody > RFC Production Center > > > > On Feb 16, 2026, at 4:21 PM, Janos Farkas > > <[email protected]> wrote: > > > > Hi, > > Indeed, many thanks for your efforts on this document! > > Please find some notes from me marked with <JF> in-line. > > Best regards, > > Janos > > From: Pascal Thubert <[email protected]> > > Sent: Tuesday, February 10, 2026 4:32 PM > > To: [email protected] > > Cc: [email protected]; [email protected]; > > [email protected]; Janos Farkas <[email protected]>; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected] > > Subject: Re: AUTH48: RFC-to-be 9913 <draft-ietf-raw-technologies-17> for > > your review > > Dear RFC Editor, > > Many thanks for your hard and deep work on this document. Please find > > below the answers of the questions I tagged for myself and for all author: > > 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. > > --> > > Pascal> Many replace "/" by "and more specifically" since RAW is a subset > > of detnet > > > > 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). > > --> > > Pascal> OK > > > > 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> OK > > 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) > > --> > > > > Pascal> I'd rather retain the original titles. Wi-Fiis a subset of 802.11 > > and the text really deals with .11 > > <JF> > > I agree with Pascal, better to keep 802.11. > > If text is wanted, then the title of the 802.11 standard could be added to > > have: > > 4. IEEE 802.11 Wireless Local Area Networks (WLAN) > > </JF> > > 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] > > --> > > Pascal> OK > > > > 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) > > <JF> > > The most recent revision of 802.3 has been completed in 2022. > > Please update the reference to IEEE Std 802.3-2022 > > I think these URLs work: > > https://standards.ieee.org/ieee/802.3/10422/ > > https://standards.ieee.org/ieee/802.3/10422/ > > </JF> > > > > > > Original: > > [IEEE Std 802.11ax] > > IEEE standard for Information Technology, "802.11ax: > > Enhancements for High Efficiency WLAN", 2021, > > <https://ieeexplore.ieee.org/document/9442429>. > > --> > > > > For the 4 items above, OK to use the updated reference and happy that you > > are now using dates in recurring IEEE specs like IEEE802.11 > > 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. > > Pascal> many thanks, no objection > > > > 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>. > > Pascal> all OK on my side > > > > 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>. > > Pascal> many thanks, sorry the pages change. > > > > 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>. > > Pascal> OK > > > > 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>. > > --> > > > > Pascal> OK > > > > > > 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"). > > --> > > > > Pascal> yes, please use 'Perhaps' > > > > 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. --> > > Pascal> I'll do that offline > > > > 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. > > --> > > > > Pascal> yes, please use <sup>. Looks good > > > > 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. > > --> > > > > > > Pascal> I'll trust you on this. "As a result" seems good to me. > > 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. > > --> > > Pascal> Please keep the original text. The meaning is different. > > <JF> > > I also prefer the original text. > > </JF> > > > > 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)? > > Pascal> Please use "ms" which is the SI standard. I believe the right > > format is like "10ms" as opposed to "10 ms". > > > > b) Will readers know what "1us" is here? Does this refer to microsecond > > (i.e., > > )? 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. > > --> > > Pascal> 1μs is SI standard so people will understand it. I believe us was > > used because of a restriction. If µs is usable please use it. > > <JF> > > I agree with Pascal. > > </JF> > > > > > > 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. > > Pascal> Please use ChannelOffset > > > > slotoffset vs. slotOffset > > Note: "slotoffset" is used in RFCs 8480, 9030, and 9033. > > Pascal> Please use "slotoffset" > > > > slotFrame vs. slotframe > > Note: "slotframe" is used in RFC 9030. > > Pascal> Please use "slotframe" > > timeSlot vs. timeslot > > Note: "timeSlot" is used in RFC 9030. > > Pascal> Please use "timeSlot" > > > > b) We see one instance each of the terms below document. Should these be > > updated to either "DetNet or RAW" or "DetNet and RAW"? > > Pascal> we may use RAW only since RAW is part of and implies DetNet. > > 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. > > > > Pascal> OK > > 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. > > --> > > Pascal> OK > > > > 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"?) > > Pascal> yes to all > > > > 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) > > Pascal> yes to all > > > > 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". > > Pascal> yes to all > > > > 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 > > Pascal> please leave the text as is. These are different sections for > > different technologies so the reader should not be confused. > > > > 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 > > > > --> > > Pascal> please expand the first in each section. A reader might read only > > one section. > > <JF> > > I agree with Pascal. > > Just FYI: > > Actually there has been a terminology change for Precision Time Protocol > > (PTP) based time synchronization; however, the only term remains unchanged > > is Grandmaster. > > A summary is given in page 7 in > > https://www.ieee802.org/1/files/public/docs2022/dr-Rodrigues-editors-update-0922-v02.pdf > > IEEE 1588 is the standard for PTP. > > The P1588g project has made the terminology change for IEEE 1588 PTP. > > There are profiles of IEEE 1588, e.g., IEEE 802.1AS. The P802.1ASdr project > > has made the terminology change for 802.1AS. 802.1ASdr has been > > incorporated to the base standard by now. That is the most recent revision: > > IEEE Std 802.1AS-2025 (https://standards.ieee.org/ieee/802.1AS/11968/) now > > only has the revised inclusive terminology, which includes Grandmaster. > > The 5G System supports 802.1AS and some other IEEE 1588 based time sync > > solutions. So the current text is fine. > > </JF> > > > > 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> please leave the text as is. These are external terminologies not > > text we control. > > All the best! > > -- Pascal > > > > > -- > Pascal -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
