Hi authors, Thank you all for your replies and approvals. We have received all necessary approvals for this document.
Once RFC-to-be 9914 completes AUTH48, this document will be published along with the rest of the documents in Cluster 538. The status of all documents in Cluster 538 is available here: https://www.rfc-editor.org/cluster_info.php?cid=C538 The AUTH48 status page for this document is available here: http://www.rfc-editor.org/auth48/rfc9913 Please let us know if you have any questions in the meantime. All the best, Kaelin Foody RFC Production Center > > On Feb 20, 2026, at 3:29 AM, Xavi Vilajosana Guillen <[email protected]> > wrote: > > +1 > > Xavier Vilajosana > Vicerector de Recerca, Transferència i Emprenedoria > Professor ICREA Academia > ORCID 0000-0002-3020-427X > +34 680 585 888 > Universitat Oberta de Catalunya > > > On Fri, Feb 20, 2026 at 8:56 AM Dr. Corinna Schmitt > <[email protected]> wrote: > I approve as well, > Corinna > > > Am 19.02.26 um 19:11 schrieb Pascal Thubert: >> 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: >> >>> 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 >> > >> > > -- > ****************************************************** > > Prof. Dr. Corinna Schmitt > Secure Communication Systems (SeCoSys) > > Research Institute CODE > Universität der Bundeswehr München > > Werner-Heisenberg-Weg 39 > 85577 Neubiberg, Germany > > Email: [email protected] > Mobil: +49 (0)1514 4821490 > https://www.unibw.de/code > https://www.corinna-schmitt.de > > Aquest missatge pot ser confidencial i s'adreça exclusivament al seu > destinatari. Si l'has rebut per error, si us plau, comunica-ho contestant el > missatge i elimina'l. > El responsable de les dades és la UOC. La finalitat és mantenir la relació > contractual o atendre la teva sol·licitud d'acord amb la relació contractual > que mantens amb la UOC o, si escau, l'interès legítim de la UOC a donar-te'n > resposta. Les dades es conservaran fins que expirin els terminis de > prescripció aplicables i només es comunicaran a tercers per al compliment > d'obligacions legals, quan sigui necessari per a l'execució de la relació > contractual i als proveïdors autoritzats. > Pots exercir els teus drets en protecció de dades adreçant-te a > [email protected], contactant amb la persona delegada de protecció de dades a > [email protected], així com presentant una reclamació davant l'APDCAT.Este mensaje > se dirige exclusivamente a su destinatario y puede contener información > confidencial. Si lo has recibido por error, por favor, comunícalo contestando > el mensaje y elimínalo. > El responsable de los datos es la UOC. La finalidad es mantener la relación > contractual o atender tu solicitud de acuerdo con la relación contractual que > mantienes con la UOC, o si procede, el interés legítimo de la UOC a darte > respuesta. Los datos se conservarán hasta que expiren los plazos de > prescripción aplicables y solo se comunicarán a terceros para el cumplimiento > de obligaciones legales, cuando sea necesario para la ejecución de la > relación contractual y a los proveedores autorizados. > Puedes ejercer tus derechos de protección de datos dirigiéndote a > [email protected], contactando con la persona delegada de protección de datos > en [email protected], así como presentando una reclamación ante la APDCAT. > > This message may be confidential and is intended solely for the addressee. If > you have received it in error, please reply to the message to let us know and > then destroy it. > The UOC is the data controller. The purpose of processing your data is to > maintain your contractual relationship with the UOC, to respond to your > request based on your contractual relationship with the UOC, or to pursue the > UOC's legitimate interest in responding to you. Data will be stored until the > applicable statutes of limitation expire and will only be disclosed to third > parties to comply with legal obligations, or to authorized providers, or when > necessary for the performance of the contractual relationship. > You can exercise your data protection rights by writing to [email protected], > by contacting the data protection officer at [email protected], or by lodging a > complaint with APDCAT (the Catalan Data Protection Authority). -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
