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]
