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<http://www.hartcomm.org>
There is a specific page for WirelessHART here:
https://www.fieldcommgroup.org/technologies/wirelesshart.
However, this does not match the original title of this reference. The
original title of this reference seems to be pointing to IEC 62951, which can
be found at this URL: https://webstore.iec.ch/en/publication/24433
We have updated this reference based of the information available at
the redirected URL to point to FieldComm Group's page for
WirelessHART. Please let us know if you would prefer to point to the
IEC page.
Original:
[WirelessHART]
www.hartcomm.org<http://www.hartcomm.org>, "Industrial
Communication Networks -
Wireless Communication Network and Communication Profiles
- WirelessHART - IEC 62591", 2010.
Updated:
[WirelessHART]
FieldComm Group, "WirelessHART",
<https://www.fieldcommgroup.org/technologies/
wirelesshart>.
Pascal> many thanks, sorry the pages change.
e) The original title for this reference doesn't match the title at the
URL. We have updated this reference to match the URL.
Original:
[IMT2020] "ITU towards IMT for 2020 and beyond",
<https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-2020/Pages/default.aspx>.
Updated:
[IMT2020] ITU, "IMT-2020 (a.k.a. "5G")",
<https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-2020/Pages/default.aspx>.
Pascal> OK
f) The original URL for this reference results in a 404 error. We found the
following URL, which matches the information for this reference, but
M. Schnell is not the author of this article. We have updated the reference
accordingly.
Original:
[SCH19] Schnell, M., "DLR tests digital communications
technologies combined with additional navigation functions
for the first time", 3 March 2019,
<https://www.dlr.de/dlr/en/desktopdefault.aspx/tabid-
10081/151_read-32951/#/gallery/33877>.
Current:
[SCH19] German Aerospace Center (DLR), "DLR tests digital
communications technologies combined with additional
navigation functions for the first time", 27 March 2019,
<https://www.dlr.de/en/latest/
news/2019/01/20190327_modern-technology-for-the-flight-
deck>.
-->
Pascal> OK
45) <!-- [rfced] In the Contributors section, would you like to point to
specific
section numbers? This would create links in the HTML and PDF
outputs. Also, is Section 4 the "Wi-Fi section"? Will this be clear to
readers?
Current:
* Georgios Z. Papadopoulos: Contributed to the TSCH section
* Nils Maeurer: Contributed to the LDACS section
* Thomas Graeupl: Contributed to the LDACS section
* Torsten Dudda, Alexey Shapin, and Sara Sandberg: Contributed to
the 5G section
* Rocco Di Taranto: Contributed to the Wi-Fi section
* Rute Sofia: Contributed to the Introduction and Terminology
sections
Perhaps:
* Georgios Z. Papadopoulos contributed to Section 5 ("IEEE 802.15.4
Time-Slotted Channel Hopping (TSCH)").
* Nils Maeurer and Thomas Graeupl contributed to Section 7 ("L-Band
Digital Aeronautical Communications System (LDACS)").
* Torsten Dudda, Alexey Shapin, and Sara Sandberg contributed to Section 6
("5G").
* Rocco Di Taranto contributed to Section 4 ("IEEE 802.11").
* Rute Sofia contributed to Section 1 ("Introduction") and Section 2
("Terminology").
-->
Pascal> yes, please use 'Perhaps'
46) <!-- [rfced] Some author comments are present in the XML. Please confirm
that
no updates related to these comments are needed. Note that these comments
will be deleted prior to publication. -->
Pascal> I'll do that offline
47) <!-- [rfced] Would you like to make use of <sup> for superscript for the two
instances of "10^-5" in this document? We updated the first instance so
you can see what this looks like; please review in the HTML. Note that in the
HTML
and PDF, it appears as superscript; in the text output, <sup> generates a^b,
which is
used in the original document.
-->
Pascal> yes, please use <sup>. Looks good
48) <!-- [rfced] Please review "It results that" in these sentences. Would
either
removing this phrase or updating to "As a result", "Thus," (or something
else) improve these sentences? Note that how to update may depend on
context, so please review each instance in context.
Original:
It results that a frame that is received in a RX-cell of a Track with a
destination MAC address set to this node as opposed to broadcast must
be extracted from the Track and delivered to the upper layer (a frame
with an unrecognized MAC address is dropped at the lower MAC layer
and thus is not received at the 6top sublayer).
...
It results that a frame
that is received over a layer-3 bundle may be in fact associated with
a Track.
...
It results that the tagging that is used for a DetNet flow outside
the 6TiSCH Low Power Lossy Network (LLN) must be swapped into 6TiSCH
formats and back as the packet enters and then leaves the 6TiSCH
network.
...
It results that a node
will maintain only a small number of peering information, and will
not be able to store many packets waiting to be forwarded.
-->
Pascal> I'll trust you on this. "As a result" seems good to me.
49) <!-- [rfced] Would you like to update "wide-area" and "local-area" in these
sentences to "WAN" and "LAN", respectively? Or do you prefer the current?
Current:
With these three cornerstones, NR is a
complete solution supporting the connectivity needs of consumers,
enterprises, and the public sector for both wide-area and local-area
(e.g., indoor) deployments.
...
The 5G system allows deployment in a vast spectrum range, addressing
use cases in both wide-area and local-area networks.
Perhaps:
With these three cornerstones, NR is a
complete solution supporting the connectivity needs of consumers,
enterprises, and the public sector for both WAN and LAN
(e.g., indoor) deployments.
...
The 5G system allows deployment in a vast spectrum range, addressing
use cases in both WANs and LANs.
-->
Pascal> Please keep the original text. The meaning is different.
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]<mailto:[email protected]>
Mobil: +49 (0)1514 4821490
https://www.unibw.de/code
https://www.corinna-schmitt.de
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
