Dear all, I did a pass on mine 12) <!-- [rfced] We were unable to find RPL explicitly mentioned in RFC 8480. Should this citation be updated? Perhaps to [RFC6550]?
Original: RPL [RFC8480] provides the routing structure, enabling the 6TiSCH devices to establish the links with well connected neighbours and thus forming the acyclic network graphs. --> XV: use [RFC6550] 13) <!-- [rfced] In the two instances below, may we update "the application to wireless" to "applied to" as follows? Also, should these sentences be more closely aligned? In particular, should the phrases "concept of a recovery graph in the RAW architecture" and "concept of a DetNet architecture protection path applied to 6TiSCH networks" be aligned? Original: A Track at 6TiSCH is the application to wireless of the concept of a Recovery Graph in the RAW architecture. ... A Track in the 6TiSCH Architecture [RFC9030] is the application to 6TiSCH networks of the concept of a protection path in the "Detnet architecture" [RFC8655]. Perhaps: In 6TiSCH, a Track is the concept of a recovery graph in the RAW architecture applied to wireless. ... In the 6TiSCH architecture [RFC9030], a Track is the concept of a DetNet architecture protection path applied to 6TiSCH networks. --> XV: Accept 14) <!-- [rfced] FYI - We have added the verb "occurs" for clarity in the text below. Please review. Original: Each device has its own perspective of when the send or receive and on which channel the transmission happens. Current: Each device has its own perspective of when the send or receive occurs and on which channel the transmission happens. --> XV: Accept 15) <!-- [rfced] How may we revise "at the MAC introducing" to increase clarity? Original: Part of these reliability challenges are addressed at the MAC introducing redundancy and diversity, thanks to channel hopping, scheduling and ARQ policies. Perhaps: Part of these reliability challenges are addressed at the MAC layer by introducing redundancy and diversity, thanks to channel hopping, scheduling, and ARQ policies. --> XV: Accept 16) <!-- [rfced] Should "simplest and fastest" be updated to "simplest and fastest operation" (or something similar)? Original: Track Forwarding is the simplest and fastest. Perhaps: Track Forwarding is the simplest and fastest operation. --> XV: Accept 17) <!-- [rfced] Will "this means effectively broadcast" be clear to readers? Original: In the case of IEEE802.15.4, this means effectively broadcast, so that along the Track the short address for the destination of the frame is set to 0xFFFF. Perhaps: In the case of IEEE 802.15.4, this effectively means that the address is broadcast, so that the short address for the destination of the frame is set to 0xFFFF along the Track. --> XV: Accept 18) <!-- [rfced] Please clarify "to trade-off performance to reliability". Does the suggested text below convey the intended meaning? Original: As a low power technology targeting industrial scenarios radio transducers provide low data rates (typically between 50kbps to 250kbps) and robust modulations to trade-off performance to reliability. Perhaps: As a low-power technology targeting industrial scenarios, radio transducers provide low data rates (typically between 50 kbps to 250 kbps) and robust modulations to trade off performance for reliability. --> XV: Accept 19) <!-- [rfced] Should "tight control to latency" be updated to "tight control of latency" (i.e., "of" rather than "to")? Or is the current okay? Original: This provides a tight control to latency along a Track. Perhaps: This provides a tight control of latency along a Track. --> XV: Accept 20) <!-- [rfced] How may we update the the text starting with "in particular..." to clarify what is provided to a PCE? Original: Rather, an Operation Control System (OCS) invoked through a Human/Machine Interface (HMI) provides the Traffic Specification, in particular in terms of latency and reliability, and the end nodes, to a PCE. Perhaps: Rather, an Operation Control System (OCS) invoked through a Human/Machine Interface (HMI) provides the traffic specification (in particular, in terms of latency and reliability) and the end nodes to a PCE. Or: Rather, an Operation Control System (OCS) invoked through a Human/Machine Interface (HMI) provides the traffic specification (in particular, in terms of latency, reliability, and the end nodes) to a PCE. --> XV: the latest -> Rather, an Operation Control System (OCS) invoked through a Human/Machine Interface (HMI) provides the traffic specification (in particular, in terms of latency, reliability, and the end nodes) to a PCE. 21) <!-- [rfced] Will readers understand "(to be)" in this sentence? Should it be removed or clarified? Original: For that case, the expectation is that a protocol that flows along a Track (to be), in a fashion similar to classical Traffic Engineering (TE) [CCAMP], may be used to update the state in the devices. Perhaps (remove "to be"): For that case, the expectation is that a protocol that flows along a Track, in a fashion similar to classical Traffic Engineering (TE) [CCAMP], may be used to update the state in the devices. --> XV: Accept 22) <!-- [rfced] What is meant by "Stream Management Entity" above Figure 2? Should this be expanded into a complete sentence or handled in some other way? --> XV: I think it can be removed. 23) <!-- [rfced] We have moved the text below from the title of Figure 4 and added it to the text introducing the figure. Please review. Also, please clarify "twice" here. Would updating as follows (move "twice", add colon, and add "once") convey the intended meaning? Original: S transmits twice the same data packet, to its Destination Parent (DP) (A) and to its Alternate Parent (AP) (B). Perhaps: In the figure above, S transmits the same data packet twice: once to its Destination Parent (DP) (A) and once to its Alternate Parent (AP) (B). --> XV: Accept 24) <!-- [rfced] Please clarify the text starting with ", and does not need". Original: As it goes, 6TiSCH expects that timeSlots corresponding to copies of a same packet along a Track are correlated by configuration, and does not need to process the sequence numbers. Perhaps: As it goes, 6TiSCH expects that timeSlots corresponding to copies of the same packet along a Track are correlated by configuration, so processing the sequence numbers is not needed. --> XV: Accept 25) <!-- [rfced] FYI - We added "policies that" after "for instance" in the text below. Please confirm that this is correct. Original: The PCE should be able to compute Tracks that will implement policies on how the energy is consumed, for instance balance between nodes and ensure that the spent energy does not exceeded the scavenged energy over a period of time. Perhaps: The PCE should be able to compute Tracks that will implement policies on how the energy is consumed, for instance, policies that balance between nodes and ensure that the spent energy does not exceed the scavenged energy over a period of time. --> XV: Accept 26) <!-- [rfced] Should "device perspective" here be updated to "device's perspective" (with 's)? Or is another meaning intended? Original: The slotFrame is a device perspective of a transmission schedule; there can be more than one with different priorities so in case of a contention the highest priority applies. --> XV: Yes update please 27) <!-- [rfced] We were unable to find a section titled "SlotFrames and Priorities" in RFC 9030. Should the text below reference Section 4.3.5 of RFC 9030 (titled "Slotframes and CDU Matrix") instead? Original: Elaboration on that concept can be found in section "SlotFrames and Priorities" of [RFC9030], and figures 17 and 18 of [RFC9030] illustrate that projection. Perhaps: Elaboration on that concept can be found in Section 4.3.5 of [RFC9030], and Figures 17 and 18 of [RFC9030] illustrate that projection. --> XV: Accept 28) <!-- [rfced] Will "When thereupon UL resources are scheduled to the UE" be clear to readers? Original: When thereupon UL resources are scheduled to the UE, the UE can transmit its data and may include a buffer status report, indicating the exact amount of data per logical channel still left to be sent. Perhaps: When UL resources are scheduled, the UE can transmit its data and may include a buffer status report that indicates the exact amount of data per logical channel still left to be sent. XV: Accept 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 Many thanks for the detailed review. kind regards Xavier Vilajosana Vicerector de Recerca, Transferència i Emprenedoria Professor ICREA Academia ORCID 0000-0002-3020-427X <https://orcid.org/0000-0002-3020-427X> +34 680 585 888 Universitat Oberta de Catalunya [image: UOC] <http://www.uoc.edu/> On Tue, Feb 10, 2026 at 4:58 PM Cavalcanti, Dave <[email protected]> wrote: > Thanks for the suggestions, here are the inputs on my items: > > > > > 6) <!-- [rfced] Please clarify "for uses case with". > > Original: > In parallel, the Avnu Alliance [Avnu], which focuses on applications > of TSN for real time data, formed a workgroup for uses case with TSN > capabilities over wireless, leveraging both 3GPP and IEEE Std 802.11 > standards. > > Perhaps: > In parallel, the Avnu Alliance [Avnu], which focuses on applications > of TSN for real-time data, formed a workgroup to investigate TSN > capabilities over wireless, leveraging both 3GPP and IEEE Std 802.11 > standards. > --> > > *Dave: OK* > > 7) <!-- [rfced] Will readers understand what "the latter" is here? > > Original: > To achieve the latter, the reliability must be handled at an upper > layer that can select Wi-Fi and other wired or wireless technologies > for parallel transmissions. > --> > *Dave: this should be okay as is.* > > 8) <!-- [rfced] Should "AIEEE802.11-2016" be updated to "IEEE802.11-2016" > (no > "A")? If "AIEEE802.11-2016" is correct, is a reference needed? If so, > please provide it. > > Original: > Stream Reservation Protocol (part of [IEEE Std 802.1Qat]): > AIEEE802.11-2016 > --> > *Dave*: IEEE802.11-2016 is good. Here is the reference: > > "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," in *IEEE Std > 802.11-2016 (Revision of IEEE Std 802.11-2012)* , vol., no., pp.1-3534, > 14 Dec. 2016, doi: 10.1109/IEEESTD.2016.7786995. > > > > 9) <!-- [rfced] How may we revise the phrase "to increase efficiency, > control and > reduce latency" to clarify how the word "control" should be understood? > > Original: > > The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax > amendment > [IEEE Std 802.11ax], which includes specific capabilities to increase > efficiency, control and reduce latency. > > Perhaps: > > The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax > amendment > [IEEE Std 802.11ax], which includes specific capabilities to increase > efficiency and to control and reduce latency. > > *Dave: This option looks good.* > > > Or: > > The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax > amendment > [IEEE Std 802.11ax], which includes specific capabilities to increase > efficiency and control and to reduce latency. > > --> > > > 10) <!-- [rfced] Would you like to update the following long sentence to > be a > bulleted list? Or do you prefer the original? > > Original: > > Such flexibility can be leveraged to support time-sensitive applications > with bounded latency, especially in a managed network where stations > can be > configured to operate under the control of the AP, in a controlled > environment (which contains only devices operating on the unlicensed > band > installed by the facility owner and where unexpected interference from > other systems and/or radio access technologies only sporadically > happens), > or in a deployment where channel/link redundancy is used to reduce the > impact of unmanaged devices/ interference. > > Perhaps: > > Such flexibility can be leveraged to support time-sensitive applications > with bounded latency, especially: > > * in a managed network where stations can be configured to operate > under the > control of the AP, > > * in a controlled environment (which contains only devices operating on > the > unlicensed band installed by the facility owner and where unexpected > interference from other systems and/or radio access technologies only > sporadically happens), or > > * in a deployment where channel and link redundancy is used to reduce > the > impact of unmanaged devices and interference. > > --> > *Dave: looks good.* > > > > 11) <!-- [rfced] How may we clarify "and potential solution directions"? > > Original: > The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) > provided detailed information on use cases, issues and potential > solution directions to improve support for time-sensitive > applications in 802.11. > > Perhaps: > The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) > provided detailed information on use cases, issues, > *and a potential solutions* to improve support for time-sensitive > applications in 802.11. > --> > > *Dave: suggest to use “and potential solutions”, as there may be more than > one solution proposed.* > > > > > > > > > > *From:* Dr. Corinna Schmitt <[email protected]> > *Sent:* Tuesday, February 10, 2026 7:45 AM > *To:* [email protected] > *Cc:* Pascal Thubert <[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 > > > > Dear RFC Editors, > > many thanks for the comments. Pascal pointed for some items to me. Here > are my answers: > > > > > > > 38) <!-- [rfced] FYI - We moved the first sentence below to appear before > Figures > 11 and 12. Let us know any concerns. > > Original: > This fixed frame structure allows for a reliable and dependable > transmission of data. Next, the LDACS medium access layer is > introduced: > --> > > Answer: Ok with your suggestion. > > > 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 > > > > > > Regards, > Corinna > > > > > > > > Am 10.02.26 um 16:32 schrieb Pascal Thubert: > > 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 > > > > > > 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) > > 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. > > > > > 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. > > > > > > 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. > > > > > > > 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 > > -- > > ****************************************************** > > > > PD Dr. rer. nat. habil. Corinna Schmitt > > Head of 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] <mailto:[email protected]>, contactant amb la persona delegada de protecció de dades a [email protected] <mailto:[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] <mailto:[email protected]>, contactando con la persona delegada de protección de datos en [email protected] <mailto:[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] <mailto:[email protected]>, by contacting the data protection officer at [email protected] <mailto:[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]
