Approved. Thanks for all the improvements. Dave
-----Original Message----- From: Pascal Thubert <[email protected]> Sent: Thursday, February 19, 2026 10:11 AM To: Kaelin Foody <[email protected]> Cc: Janos Farkas <[email protected]>; [email protected]; Cavalcanti, Dave <[email protected]>; [email protected]; [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 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 >>> Pascal> 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 >>> Pascal> 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]
