Re: [auth48] AUTH48: RFC-to-be 9365 <draft-ietf-ipwave-vehicular-networking-30> for your review

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Alice,
Here are my updates with my revision letters
so that you can reflect them on the xml file by yourself.

I have used my old xml file to reflect my answers, so
you can refer to the attached xml for only your reference.

If you need my help, please let me know.

Thanks.

Best Regards,
Paul

On Tue, Feb 21, 2023 at 1:57 PM Mr. Jaehoon Paul Jeong <
[e-mail]> wrote:

> Hi Alice,
> I will modify the xml file according to your comments and questions this
> week (by February 24 in KST).
>
> I will also provide you with a revision letter to show how I have updated
> the text.
>
> Thanks.
>
> Best Regards,
> Paul
>
> On Sun, Feb 19, 2023 at 2:43 AM Alice Russo <[e-mail]> wrote:
>
>> Paul,
>> Thank you for your mail. Yes; please know that you have the time needed
>> for the review of the edited document and the questions.  It's your choice
>> whether you update the source file yourself or reply via mail (in which
>> case, we will update the source file).  We will check in with you at the
>> one-week mark if we haven't heard from you. We'll be here for any questions
>> or followups on the updates for the document.
>>
>> Thank you.
>> RFC Editor/ar
>>
>> > On Feb 18, 2023, at 3:34 AM, Mr. Jaehoon Paul Jeong <
>> [e-mail]> wrote:
>> >
>> > Hi RFC Editor,
>> > I will review your comments and answer them.
>> > Today and tomorrow are the weekend, so I am busy with my Christianity
>> worship and fellowship.
>> > Could you allow me to finish them by noon (12pm) next Tuesday (February
>> 21) in Korean time?
>> >
>> > Thanks.
>> >
>> > Best Regards,
>> > Jaehoon (Paul) Jeong
>> >
>> >
>> > On Sat, Feb 18, 2023 at 4:19 PM <[e-mail]> wrote:
>> > Greetings,
>> >
>> > While reviewing this document during AUTH48, please resolve (as
>> necessary) the following questions, which are also in the XML file.
>> >
>> > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in
>> the
>> > title) for use on https://www.rfc-editor.org/search.
>> > -->
>> >
>> >
>> > 2) <!--[rfced] We note that "IPWAVE" has been expanded as "IP"
>> > (rather than "IPv6") in the past - for example, in the name of
>> > the IETF working group. Is it intentional to use "IPv6" in
>> > this document without modifying the acronym?
>> >
>> > Title and Section 1 contain:
>> >   IPv6 Wireless Access in Vehicular Environments (IPWAVE)
>> >
>> > vs. RFC 8691 (and the IPWAVE WG page) contains:
>> >   IP Wireless Access in Vehicular Environments (IPWAVE)
>> > -->
>> >
>> >
>> > 3) <!-- [rfced] Would you like the terms in Section 2 to be
>> alphabetized?
>> > -->
>> >
>> >
>> > 4) <!-- [rfced] We had difficulty parsing this sentence, specifically
>> "at
>> > edge". How should it be updated for clarity? Does "at edge" refer to
>> > "at the edge of the network"?
>> >
>> > Original:
>> >    *  Edge Computing Device (ECD): It is a computing device (or server)
>> >       at edge for vehicles and vulnerable road users.
>> > -->
>> >
>> >
>> > 5) <!-- [rfced] If LiDAR is the method used by a "LiDAR sensor" or
>> > "LiDAR device" (rather than the device itself), may this definition
>> > be updated as follows, or otherwise?
>> >
>> > Original:
>> >    *  LiDAR: "Light Detection and Ranging".  It is a scanning device to
>> >       measure a distance to an object by emitting pulsed laser light and
>> >       measuring the reflected pulsed light.
>> >
>> > Perhaps:
>> >    *  Light Detection and Ranging (LiDAR):  This is a method
>> >       for measuring a distance to an object by emitting pulsed
>> >       laser light and measuring the reflected pulsed light.
>> > -->
>> >
>> >
>> > 6) <!-- [rfced] Should "dot11OCBActivited" be "dot11OCBActivated"
>> > for correct spelling ("i" changed to "a")?
>> > We note that "dot11OCBActivited" is in Section 2 of RFC 8691.
>> >
>> > Original:
>> >    *  802.11-OCB: It refers to the mode specified in IEEE Std
>> >       802.11-2016 [IEEE-802.11-OCB] when the MIB attribute
>> >       dot11OCBActivited is 'true'.
>> >
>> > Suggested:
>> >    *  802.11-OCB: This refers to the mode specified in IEEE Std
>> >       802.11-2016 [IEEE-802.11-OCB] when the MIB attribute
>> >       dot11OCBActivated is 'true'.
>> > -->
>> >
>> >
>> > 7) <!-- [rfced] FYI, so that it wouldn't appear that "safe driving"
>> describes
>> > "avoidance", we updated "safe driving and collision avoidance" to
>> > "driving safely and avoiding collisions". Please let us know if this
>> > isn't agreeable.
>> >
>> > Original:
>> >    *  Context-aware navigation for safe driving and collision avoidance
>> >
>> > Current:
>> >    *  Context-aware navigation for driving safely and avoiding
>> collisions
>> > -->
>> >
>> >
>> > 8) <!-- [rfced] FYI, for clarity concerning "UAM end systems in air", we
>> > rephrased this sentence. Please review.
>> >
>> > Original:
>> >    A collision avoidance service of UAM end systems in air can be
>> >    envisioned as a use case in air vehicular environments
>> >    [I-D.templin-ipwave-uam-its].
>> >
>> > Current:
>> >    A service for collision avoidance of in-air UAM end systems is one
>> >    possible use case in air vehicular environments [UAM-ITS].
>> > -->
>> >
>> >
>> > 9) <!-- [rfced] Can only trucks or any type of vehicle use V2V
>> communication
>> > in this case? If the latter, we suggest replacing "Trucks" with
>> "Vehicles".
>> > (The preceding sentence is included for context.)
>> >
>> > Original:
>> >    Platooning [Truck-Platooning] allows a series (or group) of vehicles
>> >    (e.g., trucks) to follow each other very closely.  Trucks can use V2V
>> >    communication in addition to forward sensors in order to maintain
>> >    constant clearance between two consecutive vehicles at very short
>> >    gaps (from 3 meters to 10 meters).
>> >
>> > Perhaps:
>> >    Platooning [Truck-Platooning] allows a series (or group) of vehicles
>> >    (e.g., trucks) to follow each other very closely.  Vehicles can use
>> V2V
>> >    communication in addition to forward sensors in order to maintain
>> >    constant clearance between two consecutive vehicles at very short
>> >    gaps (from 3 to 10 meters).
>> > -->
>> >
>> >
>> > 10) <!-- [rfced] Please clarify "accident vehicles"; does it refer to
>> > vehicles in a collision, rather than vehicles responding to a collision?
>> >
>> > Also, since "IP-RSU" is not a type of network, we suggest rephrasing
>> > the final list. Should it be via "an IP-RSU" or "IP-RSUs" (plural)?
>> >
>> > How may we update this sentence for clarity?
>> >
>> > Original:
>> >    The emergency communication between accident vehicles (or emergency
>> >    vehicles) and a TCC can be performed via either IP-RSU, 4G-LTE or 5G
>> >    networks.
>> >
>> > Perhaps:
>> >    The emergency communication between vehicles in an accident (or
>> >    emergency-response vehicles) and a TCC can be performed via either
>> >    an IP-RSU or 4G-LTE or 5G networks.
>> > -->
>> >
>> >
>> > 11) <!-- [rfced] How may this sentence be updated to make the list
>> > items parallel? Also, what does "a used approach" refer to?
>> > For the reader, is there some context to provide for citing
>> > HIP certificates [RFC8002]?
>> >
>> > Original:
>> >    These extra means can be certificate-based,
>> >    biometric, credit-based, and one-time passcode (OTP) approaches in
>> >    addition to a used approach [RFC8002].
>> >
>> > Perhaps:
>> >    These extra means could include approaches based on certificates,
>> >    biometrics, credit, or One-Time Passwords (OTPs)
>> >    in addition to Host Identity Protocol certificates [RFC8002].
>> > -->
>> >
>> >
>> > 12) <!--[rfced] Please clarify this sentence, in particular the phrase
>> > "classify to different severity levels for driving safety". Does it
>> > mean the messages are classified into severity levels based
>> > on their potential significance to driving safety, or otherwise?
>> > Also, does "credit for the sender" refer to the "credit of the sender"?
>> >
>> > Original:
>> >    First, a credit-
>> >    based means is to let a vehicle classify the received messages sent
>> >    by another host to different severity levels for driving safety in
>> >    order to calculate the credit for the sender.
>> >
>> > Perhaps:
>> >    First, a credit-
>> >    based method is when a vehicle classifies the messages it received
>> >    from another host into various levels based on their potential
>> >    effects on driving safety in order to calculate the credit of that
>> sender.
>> > -->
>> >
>> >
>> > 13) <!-- [rfced] This sentence is quite complex, making it difficult to
>> parse.
>> > May we replace "which" with "This improvement" to split this into two
>> > sentences?
>> >
>> > Original:
>> >    For the reliability required in V2V networking, the ND optimization
>> >    defined in MANET [RFC6130] [RFC7466] improves the classical IPv6 ND
>> >    in terms of tracking neighbor information with up to two hops and
>> >    introducing several extensible Information Bases, which serves the
>> >    MANET routing protocols such as the different versions of Optimized
>> >    Link State Routing Protocol (OLSR) [RFC3626] [RFC7181], Open Shortest
>> >    Path First (OSPF) derivatives (e.g., [RFC5614]), and Dynamic Link
>> >    Exchange Protocol (DLEP) [RFC8175] with its extensions [RFC8629]
>> >    [RFC8757].
>> >
>> > Perhaps:
>> >    For the reliability required in V2V networking, the ND optimization
>> >    defined in the Mobile Ad Hoc Network (MANET) [RFC6130] [RFC7466]
>> >    improves the classical IPv6 ND in terms of tracking neighbor
>> >    information with up to two hops and introducing several extensible
>> >    Information Bases.  This improvement serves the MANET routing
>> >    protocols, such as the different versions of Optimized Link State
>> >    Routing Protocol (OLSR) [RFC3626] [RFC7181], Open Shortest Path
>> >    First (OSPF) derivatives (e.g., [RFC5614]), and Dynamic Link
>> >    Exchange Protocol (DLEP) [RFC8175] with its extensions [RFC8629]
>> >    [RFC8757].
>> > -->
>> >
>> >
>> > 14) <!--[rfced] Please clarify this sentence, in particular "leads the
>> half
>> > of the link lifetime".
>> >
>> > Original:
>> >    This relative speed leads the half of the link lifetime between the
>> >    vehicle and the IP-RSU.
>> > -->
>> >
>> >
>> > 15) <!--[rfced] Please review how "not-onlink" has been rephrased
>> > and let us know any updates. That term has been avoided because it
>> > has not appeared in other RFCs and is not consistent with the hyphen
>> > in the term "on-link". Please note that RFC 8691 uses the phrase
>> > "advertised as not on-link". For example:
>> >
>> > Original:
>> >    a destination vehicle [..] needs to be distinguished as either
>> >    an on-link host or a not-onlink host
>> >
>> > Current:
>> >    a destination vehicle [..] needs to be distinguished as either
>> >    as a host that is either on-link or not on-link
>> >
>> > In Section 5.1.1, three instances were updated as follows (please
>> > see the diff file for context).
>> >   - a prefix that is not on-link
>> >   - the prefix should be not on-link.
>> >   - prefixes that are not on-link
>> > -->
>> >
>> >
>> > 16) <!--[rfced] Please clarify this sentence, in particular "can
>> maintain its
>> > neighboring vehicles in a stable way".
>> >
>> > Original:
>> >    For example, the NA interval needs to be
>> >    dynamically adjusted according to a vehicle's speed so that the
>> >    vehicle can maintain its neighboring vehicles in a stable way, ...
>> >
>> > Perhaps:
>> >    For example, the NA interval needs to be
>> >    dynamically adjusted according to a vehicle's speed so that the
>> >    vehicle can maintain its position relative to its neighboring
>> >    vehicles in a stable way, ...
>> > -->
>> >
>> >
>> > 17) <!-- [rfced] How may this text be rephrased to clarify it? The
>> > original reads as though the RFC "installs the ND cache entries".
>> >
>> > Original:
>> >    [RFC8505], as
>> >    opposed to [RFC4861], is stateful and proactively installs the ND
>> >    cache entries, which saves broadcasts and provides deterministic
>> >    presence information for IPv6 addresses.  Mainly it updates the
>> >    Address Registration Option (ARO) of ND defined in [RFC6775] to
>> >    include a status field that can indicate the movement of a node and
>> >    optionally a Transaction ID (TID) field, i.e., a sequence number that
>> >    can be used to determine the most recent location of a node.
>> >
>> > Perhaps:
>> > (Option A)
>> >    [RFC8505], as
>> >    opposed to [RFC4861], states how to proactively install the ND
>> >    cache entries.  This saves broadcasts and provides deterministic
>> >    presence information for IPv6 addresses.  The installation then
>> >    updates the Address Registration Option (ARO) of ND defined in
>> >    [RFC6775] to include a status field that can indicate the movement
>> >    of a node and optionally a Transaction ID (TID) field, i.e., a
>> >    sequence number that can be used to determine the most recent
>> >    location of a node.
>> >
>> > (Option B)
>> >    The extension described in [RFC8505] is stateful
>> >    and proactively installs the ND cache entries; this saves broadcasts
>> >    and provides deterministic presence information for IPv6 addresses.
>> >    Mainly, it updates the Address Registration Option (ARO) of ND
>> >    defined in [RFC6775] to include a status field (which can indicate
>> >    the movement of a node) and optionally a Transaction ID (TID) field
>> >    (which is a sequence number that can be used to determine the most
>> >    recent location of a node).
>> > -->
>> >
>> >
>> > 18) <!-- [rfced] Please clarify "the SLAAC with [RFC8505]". Does it
>> > mean "SLAAC with the registration extension specified in
>> > [RFC8505]" or otherwise?
>> >
>> > Also, will the phrase "costs a DAD" be clear to the reader?
>> > Does it mean "costs DAD overhead" or otherwise?
>> >
>> > Original:
>> >    Even though the SLAAC with classic ND costs a DAD during mobility
>> >    management, the SLAAC with [RFC8505] and/or AERO/OMNI do not cost a
>> >    DAD.
>> >
>> > Perhaps:
>> >    Even though SLAAC with classic ND costs DAD overhead during
>> >    mobility management, SLAAC with the registration extension
>> >    specified in [RFC8505] and/or with AERO/OMNI does not cost DAD
>> overhead.
>> > -->
>> >
>> >
>> > 19) <!--[rfced] Please clarify "among them"; does it mean mutual
>> > authentication of the vehicles?
>> >
>> > Original:
>> >    In addition,
>> >    to prevent bogus IP-RSUs and MA from interfering with the IPv6
>> >    mobility of vehicles, mutual authentication among them needs to be
>> >    performed by certificates (e.g., TLS certificate).
>> >
>> > Perhaps:
>> >    In addition,
>> >    to prevent bogus IP-RSUs and MA from interfering with the IPv6
>> >    mobility of vehicles, mutual authentication of the vehicles needs
>> >    to be performed by certificates (e.g., TLS certificate).
>> >
>> > Or simply cut "among them":
>> >    In addition,
>> >    to prevent bogus IP-RSUs and MA from interfering with the IPv6
>> >    mobility of vehicles, mutual authentication needs to be
>> >    performed by certificates (e.g., TLS certificate).
>> > -->
>> >
>> >
>> > 20) <!-- [rfced] Would you like the references to be alphabetized
>> > or left in their current order?  (This would be done by setting
>> > the rfc element's sortRefs attribute to true.)
>> > -->
>> >
>> >
>> > 21) <!-- [rfced] The title in this reference does not match the title
>> of the
>> > document available from the provided URL. So would you like to keep
>> > the URL and update the title? Or, perhaps a different URL was intended?
>> >
>> > Original:
>> >    [FCC-ITS-Modification]
>> >               Federal Communications Commission, "Use of the 5.850-5.925
>> >               GHz Band, First Report and Order, Further Notice of
>> >               Proposed Rulemaking, and Order of Proposed Modification,
>> >               FCC 19-138", Available: https://www.fcc.gov/document/fcc-
>> >               modernizes-59-ghz-band-improve-wi-fi-and-automotive-
>> >               safety-0, November 2020.
>> >
>> > Perhaps:
>> >    [FCC-ITS-Modification]
>> >               Federal Communications Commission, "FCC Modernizes 5.9
>> GHz
>> >               Band to Improve Wi-Fi and Automotive Safety", November
>> 2020,
>> >               <https://www.fcc.gov/document/fcc-modernizes-59-
>> >               ghz-band-improve-wi-fi-and-automotive-safety-0>.
>> > -->
>> >
>> >
>> > 22) <!-- [rfced] Are there exactly two modes for routing in RPL?
>> > If so, may we update the sentence as follows?
>> >
>> > Original:
>> >    There are two modes for routing in RPL
>> >    such as non-storing mode and storing mode.
>> >
>> > Perhaps (remove "such as"):
>> >    There are two modes for routing in RPL:
>> >    non-storing mode and storing mode.
>> > -->
>> >
>> >
>> > 23) <!-- [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.
>> > -->
>> >
>> >
>> > 24) <!-- [rfced] Terminology and Capitalization
>> >
>> > a) Will it be clear to readers what the following terms are? If not,
>> > please let us know if definitions should be added to Section 2.
>> >
>> >   gNodeB
>> >   eNodeB
>> >
>> > We note that RFC 9269 contains:
>> >    eNodeB:  The eNodeB is a base station entity that supports the Long
>> >       Term Evolution (LTE) air interface.
>> >
>> >
>> > b) In this definition, "Vehicle" is capitalized but throughout the
>> > document it isn't. Would you like to make this instance lowercase or,
>> > would you like any other instances of "vehicle" to be capitalized?
>> >
>> > Original:
>> >    *  Vehicle: A Vehicle in this document is a node that has an IP-OBU
>> >       for wireless communication with other vehicles and IP-RSUs.
>> >
>> >
>> > c) In this definition, "Vehicular Cloud” is capitalized but throughout
>> the
>> > document it is sometimes capitalized and sometimes not. How may we
>> update
>> > for consistency?
>> >
>> > Original:
>> >    *  Vehicular Cloud: A cloud infrastructure for vehicular networks,
>> >       having compute nodes, storage nodes, and network forwarding
>> >       elements (e.g., switch and router).
>> > -->
>> >
>> >
>> > 25) <!-- [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.
>> >
>> > Note that our script did not flag any words in particular, but this
>> should
>> > still be reviewed as a best practice.
>> >
>> > In addition, please consider whether "traditional helicopter" should be
>> > updated for clarity.  While the NIST website
>> > <
>> https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1
>> >
>> > indicates that this term is potentially biased, it is also ambiguous.
>> > "Tradition" is a subjective term, as it is not the same for everyone.
>> > -->
>> >
>> >
>> > Thank you.
>> >
>> > RFC Editor/st/ar
>> >
>> >
>> > On Feb 17, 2023, [e-mail] wrote:
>> >
>> > *****IMPORTANT*****
>> >
>> > Updated 2023/02/17
>> >
>> > 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/rfc9365.xml
>> >   https://www.rfc-editor.org/authors/rfc9365.html
>> >   https://www.rfc-editor.org/authors/rfc9365.pdf
>> >   https://www.rfc-editor.org/authors/rfc9365.txt
>> >
>> > Diff file of the text:
>> >   https://www.rfc-editor.org/authors/rfc9365-diff.html
>> >   https://www.rfc-editor.org/authors/rfc9365-rfcdiff.html (side by
>> side)
>> >
>> > Diff of the XML:
>> >   https://www.rfc-editor.org/authors/rfc9365-xmldiff1.html
>> >
>> > The following files are provided to facilitate creation of your own
>> > diff files of the XML.
>> >
>> > Initial XMLv3 created using XMLv2 as input:
>> >   https://www.rfc-editor.org/authors/rfc9365.original.v2v3.xml
>> >
>> > XMLv3 file that is a best effort to capture v3-related format updates
>> > only:
>> >   https://www.rfc-editor.org/authors/rfc9365.form.xml
>> >
>> >
>> > Tracking progress
>> > -----------------
>> >
>> > The details of the AUTH48 status of your document are here:
>> >   https://www.rfc-editor.org/auth48/rfc9365
>> >
>> > Please let us know if you have any questions.
>> >
>> > Thank you for your cooperation,
>> >
>> > RFC Editor
>> >
>> > --------------------------------------
>> > RFC9365 (draft-ietf-ipwave-vehicular-networking-30)
>> >
>> > Title            : IPv6 Wireless Access in Vehicular Environments
>> (IPWAVE): Problem Statement and Use Cases
>> > Author(s)        : J. Jeong, Ed.
>> > WG Chair(s)      : Carlos J. Bernardos, Russ Housley
>> > Area Director(s) : Erik Kline, Éric Vyncke
>> >
>> >
>>
>>