Re: [auth48] [EXT] RE: AUTH48: RFC-to-be 9450 <draft-ietf-raw-use-cases-11> for your review

["Dr. Corinna Schmitt" <[e-mail]>]

Good improvement!



Am 16.08.23 um 16:37 schrieb Pascal Thubert (pthubert):
>
> Hello Alice and all
>
> I reviewed and approve this RFC for publication.
>
> regards,
>
> Pascal
>
> *From:* Alice Russo <[e-mail]>
> *Sent:* Tuesday, August 15, 2023 6:00 PM
> *To:* CARLOS JESUS BERNARDOS CANO <[e-mail]>
> *Cc:* [e-mail]; Pascal Thubert 
> (pthubert) <[e-mail]>; [e-mail]; 
> [e-mail]; [e-mail]; Schmitt, Corinna 
> <[e-mail]>; John Scudder <[e-mail]>; 
> [e-mail]; [e-mail]
> *Subject:* Re: AUTH48: RFC-to-be 9450 <draft-ietf-raw-use-cases-11> 
> for your review
>
> Carlos,
>
> Thank you for your reply. We have updated the document accordingly; 
> please see the follow-ups below. The revised files are here (please 
> refresh):
>
> https://www.rfc-editor.org/authors/rfc9450.html
> https://www.rfc-editor.org/authors/rfc9450.txt
> https://www.rfc-editor.org/authors/rfc9450.pdf
> https://www.rfc-editor.org/authors/rfc9450.xml
>
> This diff file shows all changes from the approved I-D:
> https://www.rfc-editor.org/authors/rfc9450-diff.html
>
> https://www.rfc-editor.org/authors/rfc9450-rfcdiff.html (side by side)
>
> This diff file shows only the changes made during AUTH48 thus far:
> https://www.rfc-editor.org/authors/rfc9450-auth48diff.html
>
> Re: #17, should "be" be "have"? (In other words, an ambulance would 
> have network segments?)
>
>         Current:
>            An instrumented ambulance would be one or multiple network
>         segments
>            that are connected to end systems such as:
>
> Perhaps:
>
>    An instrumented ambulance would have one or multiple network segments
>    that are connected to end systems such as:
>
> Re: #18c on [ODVA], you wrote:
>
>     [Carlos] We want to reference the home page, but we also wanted to
>     provide some additional context and explain that OSVA is the
>     organization that supports CIP. If it is fine, I'd prefer to keep
>     the "Original" text.
>
> We have moved the context into the body of the document (Section 4.4), 
> as it is not part of the reference itself. Please review.
>
> Original:
>
>  Over the course of the recent years, major Industrial Protocols
>
> (e.g., [ODVA] with EtherNet/IP [EIP] and [PROFINET]) have been
>
> migrating towards Ethernet and IP.
>
> [...]
>
> [ODVA] http://www.odva.org/, "The organization that supports
>
>             network technologies built on the Common Industrial
>
>             Protocol (CIP) including EtherNet/IP.".
>
> Current:
>
>  Over recent years, major industrial protocols have been migrating
>
>  towards Ethernet and IP.  (For example, [ODVA] with EtherNet/IP [EIP]
>
>  and [PROFINET], where ODVA is the organization that supports network
>
>  technologies built on the Common Industrial Protocol (CIP) including
>
>  EtherNet/IP.)
>
>
>
> [...]
>
>
>
>  [ODVA]     ODVA, "ODVA | Industrial Automation | Technologies and
>
>             Standards", <https://www.odva.org/>.
>
> We will wait to hear from you again and from your coauthors
> before continuing the publication process. This page shows
> the AUTH48 status of your document:
> https://www.rfc-editor.org/auth48/rfc9450
>
> Thank you.
> RFC Editor/ar
>
>
>
>     On Aug 10, 2023, at 3:53 AM, CARLOS JESUS BERNARDOS CANO
>     <[e-mail]> wrote:
>
>     Dear RFC Editor,
>
>     Thanks for the work on this and the suggested changes. Please
>     check below my responses to your editorial comments.
>
>     On Tue, Aug 8, 2023 at 8:17 AM <[e-mail]> wrote:
>
>         Authors,
>
>         While reviewing this document during AUTH48, please resolve
>         (as necessary) the following questions, which are also in the
>         XML file.
>
>         1) <!-- [rfced] Please note that the title of the document has
>         been updated as
>         follows. Please review.
>
>         Original:
>         RAW Use-Cases
>
>         Current:
>         Reliable and Available Wireless (RAW) Use Cases
>         -->
>
>     [Carlos] This is fine, thanks.
>
>
>
>         2) <!-- [rfced] Please insert any keywords (beyond those that
>         appear in the
>         title) for use on https://www.rfc-editor.org/search.
>         -->
>
>     [Carlos] determinism, availability, routing, path.
>
>
>         3) <!-- [rfced] For "shaper", would adding a description or
>         adding a citation
>         make this term more clear to the reader? If so, please provide
>         text.
>
>         Original:
>            Based on time, resource reservation, and policy enforcement by
>            distributed shapers, deterministic networking (DetNet)
>         provides the
>            capability to carry specified unicast or multicast data
>         streams for
>            real-time applications with extremely low data loss rates
>         and bounded
>            latency, so as to support time-sensitive and mission-critical
>            applications on a converged enterprise infrastructure.
>
>         For example, from RFC 9320:
>                A regulator, also known as shaper in [RFC2475], delays
>         some or
>                all of the packets in a traffic stream in order to
>         bring the
>                stream into compliance with an arrival curve ...
>         -->
>
>     [Carlos] I think adding a reference to [RFC2475] is fine after
>     "distributed shapers".
>
>
>         4) <!--[rfced] Are the two instances of "and/or" necessary in
>         the final phrase, or is it possible for the sentence to be
>         more precise?
>
>         Original:
>            This requires a
>            tight control of the physical resources to maintain the
>         amount of
>            traffic within the physical capabilities of the underlying
>            technology, e.g., using time-shared resources (bandwidth
>         and buffers)
>            per circuit, and/or by shaping and/or scheduling the
>         packets at every
>            hop.
>
>         Perhaps:
>            This requires a tight control of the physical resources
>            to maintain the amount of traffic within the physical
>         capabilities of
>            the underlying technology, e.g., by using time-shared resources
>            (bandwidth and buffers) per circuit, by shaping or scheduling
>            the packets at every hop, or by using a combination of these
>            techniques.
>         -->
>
>     [Carlos] The proposed text after "Perhaps" is fine, thanks.
>
>
>         5) <!--[rfced] Please clarify how this citation connects to
>         the phrase
>         "This is now changing"? Should it be as follows or otherwise?
>
>         Current:
>            This is now changing [RAW-TECHNOS]:
>
>         Perhaps:
>            This is now changing (as detailed in [RAW-TECHNOS]):
>         -->
>
>     [Carlos] The proposed text after "Perhaps" is fine, thanks.
>
>
>         6) <!--[rfced] Upon first mention of "constellations" (2nd
>         paragraph
>         of Section 2.1), will it be clear to the reader that this refers
>         to "constellations of satellites", or should it be written out?
>
>         Original:
>            Note that the large scale of the planned low Earth orbit (LEO)
>            constellations can provide fast end-to-end latency rates
>         and ...
>
>         Perhaps:
>            Note that the large scale of the planned Low Earth Orbit (LEO)
>            constellations of satellites can provide fast end-to-end
>         latency
>            rates and ...
>         -->
>
>     [Carlos] The proposed text after "Perhaps" is fine, thanks.
>
>
>         7) <!-- [rfced] Regarding the title of Figure 1:
>
>         a) "A/G" has been expanded as "Air/Ground" in keeping with RFC
>         9372;
>         please let us know if you prefer otherwise.
>
>         b) For readability, may we move the text from the title to a
>         list that follows the figure?  Also, we updated the text,
>         as RFC 9372 uses 'oceanic region' instead of 'oceanic domain'.
>
>         Original:
>           Figure 1: The Future Communication Infrastructure (FCI):
>         AeroMACS
>           for Airport/ Termina Maneuvering Area domain, LDACS A/G for
>           Terminal Maneuvering/ En-Route domain, LDACS A/G for En-Route/
>           Oceanic, Remote, Polar domain, SatCOM for Oceanic, Remote, Polar
>           domain domain communications
>
>         Perhaps:
>              Figure 1: The Future Communication Infrastructure (FCI)
>
>           FCI includes:
>             * AeroMACS for airport and terminal maneuvering area domains,
>             * LDACS Air/Ground for terminal maneuvering area and en route
>               domains,
>             * LDACS Air/Ground for en route or oceanic, remote, and polar
>               regions, and
>             * SatCOM for oceanic, remote, and polar regions.
>         -->
>
>     [Carlos] a) fine, thanks. b) the proposed text after "Perhaps" is
>     fine, thanks.
>
>
>         8) <!-- [rfced] To make the list items more parallel and to
>         make the list
>         similar to preceding lists, may we update it as follows?
>
>         Original:
>            *  Local area: the sensors and actuators controlling the
>         attractions
>               are co-located.  Control loops trigger only local
>         traffic, with a
>               small end-to-end delay, typically less than 10 ms, like
>         classical
>               industrial systems [IEEE80211-RT-TIG].
>
>            *  Wearable mobile devices are free to move in the park.  They
>               exchange traffic locally (identification, personalization,
>               multimedia) or globally (billing, child tracking).
>
>            *  Computationally intensive applications offload some
>         tasks.  Edge
>               computing seems an efficient way to implement real-time
>               applications with offloading.  Some non-time-critical
>         tasks may
>               rather use the cloud (predictive maintenance, marketing).
>
>         Perhaps:
>            *  Local area: the sensors and actuators controlling the
>         attractions
>               are co-located.  Control loops trigger only local
>         traffic, with a
>               small end-to-end delay, typically less than 10 ms, like
>         classical
>               industrial systems [IEEE80211-RT-TIG].
>
>            *  Wearable devices: wearable mobile devices are free to
>         move in the
>               park.  They exchange traffic locally (identification,
>               personalization, multimedia) or globally (billing,
>         child-tracking).
>
>            *  Offloading: computationally intensive applications
>         offload some
>               tasks.  Edge computing seems to be an efficient way to
>         implement
>               real-time applications with offloading.  Some
>         non-time-critical
>               tasks may rather use the cloud (predictive maintenance,
>               marketing).
>         -->
>
>     NEW:
>
>        *  Local area: the sensors and actuators controlling the
>     attractions
>           are co-located.  Control loops trigger only local traffic,
>     with a
>           small end-to-end delay, typically less than 10 ms, like
>     classical
>           industrial systems [IEEE80211-RT-TIG].
>
>        *  Wearable devices: wearable mobile devices are free to move
>     in the
>           park.  They exchange traffic locally (identification,
>           personalization, multimedia) or globally (billing,
>     child-tracking).
>
>        *  Edge computing: computationally intensive applications
>     offload some
>           tasks.  Edge computing seems to be an efficient way to implement
>           real-time applications with offloading.  Some non-time-critical
>           tasks may rather use the cloud (predictive maintenance,
>           marketing).
>
>
>         9) <!-- [rfced] FYI, for clarity, we added quotation marks
>         around "warm up
>         the mix" to make it easier to read as a unit. Please let us know
>         if you prefer otherwise.
>
>         Original:
>            A major use-case for networking in Industrial environments
>         is the
>            control networks where periodic control loops operate between a
>            collection of sensors that measure a physical property such
>         as the
>            temperature of a fluid, a Programmable Logic Controller
>         (PLC) that
>            decides an action such as warm up the mix, and actuators
>         that perform
>            the required action, such as the injection of power in a
>         resistor.
>
>         Current:
>            A major use case for networking in industrial environments
>         is the
>            control networks where periodic control loops operate between a
>            collection of sensors that measure a physical property
>         (such as the
>            temperature of a fluid), a Programmable Logic Controller
>         (PLC) that
>            decides on an action (such as "warm up the mix"), and
>         actuators that
>            perform the required action (such as the injection of power
>         in a
>            resistor).
>         -->
>
>     [Carlos] The proposed text after "Perhaps" is fine, thanks.
>
>
>         10) <!-- [rfced] In the first sentence of Section 5.3, to make
>         "The devices" more specific, may it be "Audio and video
>         devices" or
>         something else?
>
>         Original:
>            The devices need the wireless communication to support video
>            streaming via IEEE 802.11 wireless LAN for instance.
>
>         Perhaps:
>            Audio and video devices need wireless communication to
>            support video streaming via IEEE 802.11 wireless LAN, for
>            instance.
>         -->
>
>     [Carlos] The proposed text after "Perhaps" is fine, thanks.
>
>
>         11) <!-- [rfced] To avoid a sentence fragment, how may we
>         update the following?
>
>         Original:
>            Content delivery with bounded (lowest possible) latency.
>
>         Perhaps:
>            Content delivery must have bounded latency (to the lowest
>         possible latency).
>         -->
>
>     [Carlos] The proposed text after "Perhaps" is fine, thanks.
>
>
>         12) <!-- [rfced] To make "by the network providing redundancy"
>         more related
>         to rest of the sentence, may we update it as follows? If not,
>         please
>         provide another rephrase.
>
>         Original:
>            However, the most critical requirement of this
>            use-case is reliability, by the network providing redundancy.
>
>         Perhaps:
>            However, the most critical requirement of this
>            use case is reliability, which can be achieved by the network
>            providing redundancy.
>         -->
>
>     [Carlos] The proposed text after "Perhaps" is fine, thanks.
>
>
>         13) <!-- [rfced] May we update this sentence by breaking the
>         sentence into
>         two and rephrasing as follows for conciseness?
>
>         Original:
>               The cloud gaming requires low latency capability as
>               the user commands in a game session need to be sent back
>         to the
>               cloud server, the cloud server would update game context
>         depending
>               on the received commands, and the cloud server would
>         render the
>               picture/video to be displayed at user devices and stream the
>               picture/video content to the user devices.
>
>         Perhaps:
>               Cloud gaming requires low-latency capability as
>               the user commands in a game session are sent back to the
>               cloud server. Then, the cloud server updates the game
>         context
>               depending on the received commands, renders the
>               picture/video to be displayed on the user devices, and
>         streams the
>               picture/video content to the user devices.
>         -->
>
>     [Carlos] The proposed text after "Perhaps" is fine, thanks.
>
>
>         14) <!-- [rfced] FYI, we updated "UAVs/vehicles" to "UAVs and
>         other
>         vehicles". Please let us know if the intended meaning is
>         otherwise.
>
>         Original:
>            UAVs/vehicles typically have various forms of wireless
>            connectivity:
>
>         Current:
>            UAVs and other vehicles typically have various forms of
>            wireless connectivity:
>         -->
>
>     [Carlos] The proposed text after "Perhaps" is fine, thanks.
>
>
>         15) <!-- [rfced] For these two lists, would you like to match
>         the order of
>         "Cellular" and "IEEE 802.11"? Please let us know how/if we may
>         update.
>
>         Original:
>
>         (first list)
>            UAVs/vehicles typically have various forms of wireless
>         connectivity:
>
>            *  Cellular: for communication with the control center, for
>         remote
>               maneuvering as well as monitoring of the drone;
>
>            *  IEEE 802.11: for inter-drone communications (i.e.,
>         platooning) and
>               providing connectivity to other devices (i.e., acting as
>         Access
>               Point).
>
>         (second list)
>            Robots would have various forms of wireless connectivity:
>
>            *  IEEE 802.11: for connection to the edge and also inter-robot
>               communications (i.e., for coordinated actions).
>
>            *  Cellular: as an additional communication link to the
>         edge, though
>               primarily as backup, since ultra-low latency is needed.
>         -->
>
>      [Carlos] Please match the order as suggested.
>
>
>         16) <!-- [rfced] FYI, we have updated this sentence as
>         follows; please
>         review whether other updates are needed. (This sentence
>         appears twice
>         in this document, so any updates to one will be applied to both
>         instances.)
>
>         Additionally, will "chained" be clear to readers? The other use
>         within this document is "small functions that are distributed and
>         chained among robots and the edge".
>
>         Original:
>            When a given service is decomposed into functions - hosted at
>            different UAVs - chained, each link connecting two given
>         functions
>            would have a well-defined set of requirements (e.g., latency,
>            bandwidth and jitter) that must be met.
>
>         Current:
>            When a given service is decomposed into functions (which
>         are hosted at
>            different UAVs and chained), each link connecting two given
>         functions
>            would have a well-defined set of requirements (e.g., latency,
>            bandwidth, and jitter) that must be met.
>         -->
>
>     [Carlos] The proposed text after "Current" is fine, thanks.
>
>
>         17) <!-- [rfced] FYI, we updated this sentence as follows;
>         please review.
>
>         Original:
>            An instrumented ambulance would be one that one or multiple
>         network
>            segments to which are connected these end systems such as:
>
>         Current:
>            An instrumented ambulance would be one or multiple network
>         segments
>            that are connected to end systems such as:
>         -->
>
>     [Carlos] The proposed text after "Current" is fine, thanks.
>
>
>         18) <!-- [rfced] References
>
>         a) Please review [KEAV20], as the provided URL goes to the
>         Sesar home page. Is it your intention to reference the home
>         page or
>         something else?
>
>         Original:
>            [KEAV20]   T. Keaveney and C. Stewart, "Single European Sky ATM
>                       Research Joint Undertaking", 2019,
>                       <https://www.sesarju.eu/>.
>
>         Perhaps:
>            [SESAR]   SESAR, "SESAR Joint Undertaking",
>         <https://www.sesarju.eu/>.
>
>      [Carlos] The proposed text after "Perhaps" is fine, thanks.
>
>
>         b) Is the year for [ICAO18] accurate? On icao.int
>         <http://icao.int/>, we were unable to find
>         Annex 10, Vol. III, from 2018. We only see 2007 (2nd edition).
>
>         Original:
>            [ICAO18]   International Civil Aviation Organization
>         (ICAO), "L-Band
>                       Digital Aeronautical Communication System (LDACS)",
>                       International Standards and Recommended
>         Practices Annex 10
>                       - Aeronautical Telecommunications, Vol. III -
>                       Communication Systems , 2018.
>
>     [Carlos] I think it's better to replace this reference with the
>     following (from RFC 9372):
>
>     [ICAO2022] International Civil Aviation Organization (ICAO), "CHAPTER
>
>                   13 L-Band Digital Aeronautical Communications System
>
>                   (LDACS)", International Standards and Recommended
>
>                   Practices, Annex 10 - Aeronautical Telecommunications,
>
>                   Volume III, Communication Systems, 2022,
>
>                   <https://www.ldacs.com/wp-content/uploads/2023/03/
>
>                   WP06.AppA-DCIWG-6-LDACS_SARPs.pdf>.
>
>
>         c) For [ODVA], the provided URL goes to the ODVA home page.
>         Would you like to reference the home page or something else?
>
>         Original:
>            [ODVA] http://www.odva.org/, "The organization that supports
>                       network technologies built on the Common Industrial
>                       Protocol (CIP) including EtherNet/IP.".
>
>         Perhaps:
>            [ODVA]     ODVA, "ODVA | Industrial Automation |
>         Technologies and
>                       Standards", <http://www.odva.org/>.
>
>      [Carlos] We want to reference the home page, but we also wanted
>     to provide some additional context and explain that OSVA is the
>     organization that supports CIP. If it is fine, I'd prefer to keep
>     the "Original" text.
>
>         d) For [EIP], please provide new information, as the provided URL
>         yields 404 Not Found. Should it be updated to
>         1)
>         https://www.odva.org/technology-standards/key-technologies/ethernet-ip/
>         2)
>         https://www.odva.org/wp-content/uploads/2021/05/PUB00138R7_Tech-Series-EtherNetIP.pdf
>         or something else?
>
>         Current:
>            [EIP]      ODVA, "EtherNet/IP provides users with the
>         network tools
>                       to deploy standard Ethernet technology (IEEE 802.3
>                       combined with the TCP/IP Suite) for industrial
>         automation
>                       applications while enabling Internet and enterprise
>                       connectivity data anytime, anywhere.",
>                       <http://www.odva.org/Portals/0/Library/
>                       Publications_Numbered/
>         PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf>.
>
>     [Carlos] Please use 1)
>
>
>         e) Please review [IEEE802.1TSN] as it appears to be superseded
>         by IEEE Std
>         802.1AS-2020 and a revision of IEEE Std 802.1AS-2011.
>
>         Current:
>            [IEEE802.1TSN]
>                       IEEE, "IEEE Standard for Local and Metropolitan Area
>                       Networks - Timing and Synchronization for
>         Time-Sensitive
>                       Applications in Bridged Local Area Networks",
>                       DOI 10.1109/IEEESTD.2011.5741898, IEEE
>         802.1AS-2011, March
>                       2011,
>         <https://doi.org/10.1109/IEEESTD.2011.5741898>.
>
>     [Carlos] Please use the revision instead.
>
>
>         f) Please review [IEEE80211RTA] as it appears to be a
>         duplicate of reference
>         [IEEE80211-RT-TIG]. Let us know how/if we may update.
>
>            [IEEE80211RTA]
>                       IEEE standard for Information Technology, "IEEE
>         802.11
>                       Real Time Applications TIG Report", November 2018.
>
>            [IEEE80211-RT-TIG]
>                       Jones, A. and K. Meng, "Status of IEEE 802.11
>         Real Time
>                       Application Topic Interest Group", July 2018,
>                      
>         <http://www.ieee802.org/11/Reports/rtatig_update.htm>.
>         -->
>
>     [Carlos] Please use the first one only (replaced the duplicated
>     one with this one).
>
>
>         19) <!-- [rfced] Terminology
>
>         a) The acronym "IT" seems to be used with two different meanings -
>         presumably "Information Technology', then 'Internet technology'.
>         May '(IT)' be removed fron the second usage?
>
>         Original:
>         (first instance; Section 3)
>            Amusement parks comprise a variable number of attractions,
>         mostly
>            outdoor, over a large geographical area.  The IT
>         infrastructure is
>            typically multi-scale:
>
>         (second instance; Section 4.2.2)
>            On the other
>            hand, this information must be reported to the operators
>         over IP,
>            which means the potential for a security breach via the
>            interconnection of the Operational Technology (OT) network
>         with the
>            Internet technology (IT) network and possibly enable a
>         rogue access.
>
>         Perhaps (remove acronyms in Section 4.2.2):
>            ...via the
>            interconnection of the Operational Technology network with the
>            Internet Technology network and possibly enable a rogue access.
>         -->
>
>      [Carlos] The proposed text after "Perhaps" is fine, thanks.
>
>
>         20) <!-- [rfced] Please review whether the following in-text
>         citations
>         are the correct documents, as we were unable to find the topic
>         (shown on right) we expected to find and let us know if/how we
>         may update.
>
>         a) [ARINC858P1] - "Diffserv"
>
>         Current:
>            These flows are grouped into classes that
>            have similar requirements, following the Diffserv approach
>            [ARINC858P1].
>
>
>         b) [IEEE802.1TSN] - "critical", "flow", or "Ethernet"
>
>         Current:
>            On the contrary, [IEEE802.1TSN] is used for critical
>            flows using Ethernet devices.
>         -->
>
>     [Carlos] Both are fine.
>
>
>         21) <!-- [rfced] Some author comments are present in the XML.
>         Please confirm that
>         no updates related to these comments are outstanding. Note
>         that the
>         comments will be deleted prior to publication.
>         -->
>
>     [Carlos] Yes, it is fine to delete those comments.
>
>
>         22) <!-- [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.
>
>         For example, please consider whether the following should be
>         updated:
>         "disk mastering"
>
>         In addition, please consider whether "traditional games"
>         should be updated
>         for clarity. The NIST website
>         <https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
>         indicates that "traditional" can "create an inequitable
>         relationship
>         and introduce ambiguity".
>         -->
>
>     [Carlos] I think the easiest way to fix the comment regarding the
>     use of "traditional" is just by remove "Different from traditional
>     games,"
>
>     [Carlos] Regarding the term "disk mastering", I think this has a
>     very specific meaning and there is no good alternative, so I
>     prefer to keep it.
>
>     Thanks a lot!
>
>     Carlos
>
>
>         Thank you.
>
>         RFC Editor/st/ar
>
>
>         On Aug 7, 2023, [e-mail] wrote:
>
>         *****IMPORTANT*****
>
>         Updated 2023/08/07
>
>         RFC Author(s):
>         --------------
>
>         Instructions for Completing AUTH48
>
>         Your document has now entered AUTH48. Once it has been
>         reviewed and
>         approved by you and all coauthors, it will be published as an
>         RFC.
>         If an author is no longer available, there are several remedies
>         available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>
>         You and you coauthors are responsible for engaging other parties
>         (e.g., Contributors or Working Group) as necessary before
>         providing
>         your approval.
>
>         Planning your review
>         ---------------------
>
>         Please review the following aspects of your document:
>
>         *  RFC Editor questions
>
>           Please review and resolve any questions raised by the RFC
>         Editor
>           that have been included in the XML file as comments marked as
>           follows:
>
>           <!-- [rfced] ... -->
>
>           These questions will also be sent in a subsequent email.
>
>         *  Changes submitted by coauthors
>
>           Please ensure that you review any changes submitted by your
>           coauthors.  We assume that if you do not speak up that you
>           agree to changes submitted by your coauthors.
>
>         *  Content
>
>           Please review the full content of the document, as this cannot
>           change once the RFC is published. Please pay particular
>         attention to:
>           - IANA considerations updates (if applicable)
>           - contact information
>           - references
>
>         *  Copyright notices and legends
>
>           Please review the copyright notice and legends as defined in
>           RFC 5378 and the Trust Legal Provisions
>           (TLP – https://trustee.ietf.org/license-info/).
>
>         *  Semantic markup
>
>           Please review the markup in the XML file to ensure that
>         elements of
>           content are correctly tagged.  For example, ensure that
>         <sourcecode>
>           and <artwork> are set correctly. See details at
>           <https://authors.ietf.org/rfcxml-vocabulary>.
>
>         *  Formatted output
>
>           Please review the PDF, HTML, and TXT files to ensure that the
>           formatted output, as generated from the markup in the XML
>         file, is
>           reasonable.  Please note that the TXT will have formatting
>           limitations compared to the PDF and HTML.
>
>
>         Submitting changes
>         ------------------
>
>         To submit changes, please reply to this email using ‘REPLY
>         ALL’ as all
>         the parties CCed on this message need to see your changes. The
>         parties
>         include:
>
>           *  your coauthors
>
>           * [e-mail] (the RPC team)
>
>           *  other document participants, depending on the stream (e.g.,
>              IETF Stream participants are your working group chairs, the
>              responsible ADs, and the document shepherd).
>
>           * [e-mail], which is a new archival
>         mailing list
>              to preserve AUTH48 conversations; it is not an active
>         discussion
>              list:
>
>             *  More info:
>         https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>
>             *  The archive itself:
>         https://mailarchive.ietf.org/arch/browse/auth48archive/
>
>             *  Note: If only absolutely necessary, you may temporarily
>         opt out
>                of the archiving of messages (e.g., to discuss a
>         sensitive matter).
>                If needed, please add a note at the top of the message
>         that you
>                have dropped the address. When the discussion is
>         concluded,
>         [e-mail] will be re-added to the CC list and
>                its addition will be noted at the top of the message.
>
>         You may submit your changes in one of two ways:
>
>         An update to the provided XML file
>         — OR —
>         An explicit list of changes in this format
>
>         Section # (or indicate Global)
>
>         OLD:
>         old text
>
>         NEW:
>         new text
>
>         You do not need to reply with both an updated XML file and an
>         explicit
>         list of changes, as either form is sufficient.
>
>         We will ask a stream manager to review and approve any changes
>         that seem
>         beyond editorial in nature, e.g., addition of new text,
>         deletion of text,
>         and technical changes.  Information about stream managers can
>         be found in
>         the FAQ.  Editorial changes do not require approval from a
>         stream manager.
>
>
>         Approving for publication
>         --------------------------
>
>         To approve your RFC for publication, please reply to this
>         email stating
>         that you approve this RFC for publication.  Please use ‘REPLY
>         ALL’,
>         as all the parties CCed on this message need to see your approval.
>
>
>         Files
>         -----
>
>         The files are available here:
>         https://www.rfc-editor.org/authors/rfc9450.xml
>         https://www.rfc-editor.org/authors/rfc9450.html
>         https://www.rfc-editor.org/authors/rfc9450.pdf
>         https://www.rfc-editor.org/authors/rfc9450.txt
>
>         Diff file of the text:
>         https://www.rfc-editor.org/authors/rfc9450-diff.html
>         https://www.rfc-editor.org/authors/rfc9450-rfcdiff.html (side
>         by side)
>
>         Diff of the XML:
>         https://www.rfc-editor.org/authors/rfc9450-xmldiff1.html
>
>
>         Tracking progress
>         -----------------
>
>         The details of the AUTH48 status of your document are here:
>         https://www.rfc-editor.org/auth48/rfc9450
>
>         Please let us know if you have any questions.
>
>         Thank you for your cooperation,
>
>         RFC Editor
>
>         --------------------------------------
>         RFC9450 (draft-ietf-raw-use-cases-11)
>
>         Title            : RAW Use-Cases
>         Author(s)        : C. Bernardos, Ed., G. Papadopoulos, P.
>         Thubert, F. Theoleyre
>         WG Chair(s)      : Rick Taylor, Eve Schooler
>
>         Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
>
-- 
******************************************************

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:[e-mail]
Mobil: [phone]
https://www.unibw.de/code
https://www.corinna-schmitt.de