Hi Pascal and Janos, Thank you for your quick reply. We have updated the document and will continue with the publication process.
Thank you, Sandy Ginoza RFC Production Center > On Apr 10, 2026, at 1:29 PM, Janos Farkas <[email protected]> wrote: > > I agree. > Thank you, > Best regards, > Janos > > -----Original Message----- > From: Pascal Thubert <[email protected]> > Sent: Friday, April 10, 2026 21:40 > To: Sandy Ginoza <[email protected]> > Cc: Janos Farkas <[email protected]>; Editor RFC > <[email protected]>; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; Carlos > Jesus Bernardos Cano <[email protected]>; Roman Danyliw <[email protected]>; > [email protected] > Subject: Re: Final question - Re: AUTH48: RFC-to-be 9913 > <draft-ietf-raw-technologies-17> for your review > > I’m good with the proposed change, Sandy. > > Many thanks ! > > Pascal > >> Le 10 avr. 2026 à 17:36, Sandy Ginoza <[email protected]> a écrit >> : >> >> Hi all, >> >> As we prepare this document for publication, we noticed the use of >> “guaranteeably” which does not appear in most dictionaries. Please consider >> whether this sentence may be updated. >> >> Current from Section 6.2: >> The 5G Radio Access Network (5G RAN) with its NR interface includes >> several features to achieve Quality of Service (QoS), such as a >> guaranteeably low latency or tolerable packet error rates for >> selected data flows. >> >> Perhaps: >> The 5G Radio Access Network (5G RAN) with its NR interface includes >> several features to achieve Quality of Service (QoS), such as >> guaranteed low latency or tolerable packet error rates for >> selected data flows. >> >> We will wait to hear from you before continuing with publication. Note that >> a reply from at least one author is sufficient at this time. >> >> Thank you, >> Sandy Ginoza >> RFC Production Center >> >> >> >>> On Feb 19, 2026, at 10:11 AM, Pascal Thubert <[email protected]> >>> wrote: >>> >>> This is perfect Kaelin. I approve this RFC for publication. >>> I’m not sure the other authors are all very aware that they need to >>> explicitly approve as well. Let this be a reminder. >>> >>> Many thanks ! >>> >>> Pascal >>> >>>>> Le 19 févr. 2026 à 17:41, Kaelin Foody <[email protected]> a >>>>> écrit : >>>> >>>> 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: >>>>>> http://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] >>>>>> http://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]
