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

[Alice Russo <[e-mail]>]

Paul,

Thank you for your reply. We have updated the one sentence and the references accordingly. Please see two notes below. The revised files are here (please refresh):
  https://www.rfc-editor.org/authors/rfc9365.html
  https://www.rfc-editor.org/authors/rfc9365.txt
  https://www.rfc-editor.org/authors/rfc9365.pdf
  https://www.rfc-editor.org/authors/rfc9365.xml

This diff file shows only the most recent changes:
   https://www.rfc-editor.org/authors/rfc9365-lastdiff.html
   https://www.rfc-editor.org/authors/rfc9365-lastrfcdiff.html (side by side)

This diff file shows the changes made during AUTH48 thus far:
  https://www.rfc-editor.org/authors/rfc9365-auth48diff.html
  https://www.rfc-editor.org/authors/rfc9365-auth48rfcdiff.html (side by side)

This diff file shows all changes from the approved I-D:
  https://www.rfc-editor.org/authors/rfc9365-diff.html
  https://www.rfc-editor.org/authors/rfc9365-rfcdiff.html (side by side)

FYI:
- Regarding [FirstNet], we updated the title of the reference to the title of the webpage, rather than the text on the page.
- In general, we check the references to Internet-Drafts again directly before publication because they are subject to change.

Please review if any further changes are needed. We will wait to hear from you again before continuing the publication process. This page shows the AUTH48 status of your document:
  https://www.rfc-editor.org/auth48/rfc9365

Thank you.
RFC Editor/ar

> On Feb 23, 2023, at 10:39 AM, Mr. Jaehoon Paul Jeong <[e-mail]> wrote:
> 
> Hi Alice,
> Thanks for your quick update.
> I answer your comments inline below with the prefix "=> [PAUL]".
> 
> On Thu, Feb 23, 2023 at 1:49 PM Alice Russo <[e-mail]> wrote:
> Paul,
> 
> Thank you for your reply. We have updated the document accordingly; please see the follow-up question below. The revised files are here (please refresh):
>   https://www.rfc-editor.org/authors/rfc9365.html
>   https://www.rfc-editor.org/authors/rfc9365.txt
>   https://www.rfc-editor.org/authors/rfc9365.pdf
>   https://www.rfc-editor.org/authors/rfc9365.xml
> 
> This diff file shows all changes from the approved I-D:
>   https://www.rfc-editor.org/authors/rfc9365-diff.html
>   https://www.rfc-editor.org/authors/rfc9365-rfcdiff.html (side by side)
> 
> This diff file shows the changes made during AUTH48 thus far:
>   https://www.rfc-editor.org/authors/rfc9365-auth48diff.html
>   https://www.rfc-editor.org/authors/rfc9365-auth48rfcdiff.html (side by side)
> 
> 
> For #14, regarding this sentence in Section 5, may it be updated as below for readability?
> 
> > Original:
> >    This relative speed leads the half of the link lifetime between the
> >    vehicle and the IP-RSU.
> 
> 
> Your reply:
>    This relative speed leads to the half of the lifetime of the wireless link
>    between the vehicle and the IP-RSU.  
> 
> Perhaps:
>    This relative speed causes the lifetime of the wireless link
>    between the vehicle and the IP-RSU to be halved.  
> 
>  => [PAUL] The above Perhaps looks good to me. 
> 
> FYI, regarding the requested updates for the references:
> - Using the organization element is the preferred syntax when an organization authored a document, so those changes have not been made.
> - Several updates to add volume and issue numbers were already made in the edited document.
> - A "web access date" is not included in references within RFCs.
> 
>  => [PAUL] The above policy looks good to me, but there are many places to fix in References:
>       Could you update the references with the following ones?
> 
> - OLD:
> [DFC]
> Jeong, J., Shen, Y., Kim, S., Choe, D., Lee, K., and Y. Kim, "DFC: Device-free human counting through WiFi fine-grained subcarrier information", IET Communications, Volume 15, Issue 3, pp. 337-350, DOI 10.1049/cmu2.12043, January 2021, <https://doi.org/10.1049/cmu2.12043>.
> 
> - NEW:
> [DFC]
> Jeong, J., Shen, Y., Kim, S., Choe, D., Lee, K., and Y. Kim, "DFC: Device-free human counting through WiFi fine-grained subcarrier information", IET Communications, Volume 15, Issue 3, pp. 337-350, DOI 10.1049/cmu2.12043, February 2021, <https://doi.org/10.1049/cmu2.12043>.
> ---
> 
> - OLD:
> [FirstNet]
> "FirstNet Authority: The future of public safety communications", <https://www.firstnet.gov/>.
> 
> - NEW:
> [FirstNet]
> FirstNet Authority, "The future of public safety communications", <https://www.firstnet.gov/>.
> ---
> 
> - OLD:
> [OMNI]
> Templin, F. L., Ed., "Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces", Work in Progress, Internet-Draft, draft-templin-intarea-omni-11, 10 January 2023, <https://datatracker.ietf.org/doc/html/draft-templin-intarea-omni-11>.
> 
> - NEW:
> [OMNI]
> Templin, F. L., Ed., "Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces", Work in Progress, Internet-Draft, draft-templin-intarea-omni-25, 15 February 2023, <https://datatracker.ietf.org/doc/html/draft-templin-intarea-omni-25>.
> ---
> - OLD:
> [PARCELS]
> Templin, F. L., Ed., "IP Parcels", Work in Progress, Internet-Draft, draft-templin-intarea-parcels-19, 10 January 2023, <https://datatracker.ietf.org/doc/html/draft-templin-intarea-parcels-19>.
> 
> - NEW:
> [PARCELS]
> Templin, F. L., Ed., "IP Parcels and Advanced Jumbos", Work in Progress, Internet-Draft, draft-templin-intarea-parcels-51, 15 February 2023, <https://datatracker.ietf.org/doc/html/draft-templin-intarea-parcels-51>.
> ---
> 
> - OLD:
> [PSCE]
> European Comission, "PSCEurope Public Safety Communications Europe", <https://www.psc-europe.eu/>.
> 
> - NEW:
> [PSCE]
> European Commission, "PSCEurope: Public Safety Communications Europe", <https://www.psc-europe.eu/>.
> ---
> 
> - OLD:
> [SAINT]
> Jeong, J., Jeong, H., Lee, E., Oh, T., and D. H. C. Du, "SAINT: Self-Adaptive Interactive Navigation Tool for Cloud-Based Vehicular Traffic Optimization", IEEE Transactions on Vehicular Technology, Volume 65, Issue 6, DOI 10.1109/TVT.2015.2476958, June 2016, <https://doi.org/10.1109/TVT.2015.2476958>.
> 
> - NEW:
> [SAINT]
> Jeong, J., Jeong, H., Lee, E., Oh, T., and D. H. C. Du, "SAINT: Self-Adaptive Interactive Navigation Tool for Cloud-Based Vehicular Traffic Optimization", IEEE Transactions on Vehicular Technology, Volume 65, Issue 6, pp. 4053-4067, DOI 10.1109/TVT.2015.2476958, June 2016, <https://doi.org/10.1109/TVT.2015.2476958>.
> ---
> 
> - OLD:
> [SAINTplus]
> Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D. H. C. Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+ for Emergency Service Delivery Optimization", IEEE Transactions on Intelligent Transportation Systems, Volume 19, Issue 4, DOI 10.1109/TITS.2017.2710881, June 2017, <https://doi.org/10.1109/TITS.2017.2710881>. 
> 
> - NEW:
> [SAINTplus]
> Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D. H. C. Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+ for Emergency Service Delivery Optimization", IEEE Transactions on Intelligent Transportation Systems, Volume 19, Issue 4, pp. 1038-1053, DOI 10.1109/TITS.2017.2710881, April 2018, <https://doi.org/10.1109/TITS.2017.2710881>.
> ---
> 
> - OLD:
> [Truck-Platooning]
> California Partners for Advanced Transportation Technology (PATH), "Automated Truck Platooning", <https://path.berkeley.edu/research/connected-and-automated-vehicles/truck-platooning>.
> 
> - NEW:
> [Truck-Platooning]
> California Partners for Advanced Transportation Technology (PATH), "Truck Platooning", <https://path.berkeley.edu/research/connected-and-automated-vehicles/truck-platooning>.
> ---
> 
> - OLD:
> [VEHICULAR-MM]
> Jeong, J., Ed., Mugabarigira, B., Shen, Y., and H. Jung, "Vehicular Mobility Management for IP-Based Vehicular Networks", Work in Progress, Internet-Draft, draft-jeong-ipwave-vehicular-mobility-management-08, 25 July 2022, <https://datatracker.ietf.org/doc/html/draft-jeong-ipwave-vehicular-mobility-management-08>.
> 
> - NEW:
> [VEHICULAR-MM]
> Jeong, J., Ed., Mugabarigira, B., Shen, Y., and H. Jung, "Vehicular Mobility Management for IP-Based Vehicular Networks", Work in Progress, Internet-Draft, draft-jeong-ipwave-vehicular-mobility-management-09, 4 February 2023, <https://datatracker.ietf.org/doc/html/draft-jeong-ipwave-vehicular-mobility-management-09>.
> ---
> 
> - OLD:
> [VEHICULAR-ND]
> Jeong, J., Ed., Shen, Y., Kwon, J., and S. Cespedes, "Vehicular Neighbor Discovery for IP-Based Vehicular Networks", Work in Progress, Internet-Draft, draft-jeong-ipwave-vehicular-neighbor-discovery-14, 25 July 2022, <https://datatracker.ietf.org/doc/html/draft-jeong-ipwave-vehicular-neighbor-discovery-14>.
> 
> - NEW:
> [VEHICULAR-ND]
> Jeong, J., Ed., Shen, Y., Kwon, J., and S. Cespedes, "Vehicular Neighbor Discovery for IP-Based Vehicular Networks", Work in Progress, Internet-Draft, draft-jeong-ipwave-vehicular-neighbor-discovery-15, 4 February 2023, <https://datatracker.ietf.org/doc/html/draft-jeong-ipwave-vehicular-neighbor-discovery-15>.
> ---
> 
> - OLD:
> [VIP-WAVE]
> Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the Feasibility of IP Communications in 802.11p Vehicular Networks", IEEE Transactions on Intelligent Transportation Systems, Volume 14, Issue 1, DOI 10.1109/TITS.2012.2206387, March 2013, <https://doi.org/10.1109/TITS.2012.2206387>.
> 
> - NEW:
> [VIP-WAVE]
> Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the Feasibility of IP Communications in 802.11p Vehicular Networks", IEEE Transactions on Intelligent Transportation Systems, Volume 14, Issue 1, pp. 82-97, DOI 10.1109/TITS.2012.2206387, March 2013, <https://doi.org/10.1109/TITS.2012.2206387>.
> ---
>     
> 
> Please review if any further changes are needed. We will wait to hear from you again before continuing the publication process. This page shows the AUTH48 status of your document:
>   https://www.rfc-editor.org/auth48/rfc9365
> 
>  => [PAUL] I will proofread the current version tomorrow.
>       When I am done, I will let you know with possible corrections
>       by midnight on February 24 (Friday) in Korean Standard Time (UTC +9).
> 
>       Thanks.
> 
>       Best Regards,
>       Paul
>  
> Thank you.
> RFC Editor/ar
> 
> > On Feb 22, 2023, at 10:51 AM, Mr. Jaehoon Paul Jeong <[e-mail]> wrote:
> > 
> > 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
> > > 
> > > 
> > 
> > <Revision-Letter-for-AUTH48-for-IPWAVE-PS-Draft-2023-02-18.docx><Revision-Letter-for-AUTH48-for-IPWAVE-PS-Draft-2023-02-18.pdf><draft-ietf-ipwave-vehicular-networking-30-rfc9365.xml>
> 
> <Reference-Updates-for-IPWAVE-PS-Document-By-Jaehoon-Paul-Jeong-20230224.txt>