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
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
