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 is my proofread and corrected xml file along with files of other types.
I have corrected the contents of RFC9365 with this xml file.
Please go ahead for the publication of RFC9365 with this file.

Thanks for your sincere help and support.

Best Regards,
Paul


On Sat, Feb 25, 2023 at 12:07 AM Alice Russo <[e-mail]> wrote:

> Paul,
>
> Thank you for your mail. Please know that you have as much time as you
> need to complete the review of the document.
>
> Thank you.
> RFC Editor/ar
>
> > On Feb 24, 2023, at 7:55 AM, Mr. Jaehoon Paul Jeong <
> [e-mail]> wrote:
> >
> > Hi Alice,
> > I need more time to proofread the revision.
> > Could you allow me more time to let me proofread it
> > by the midnight on February 25 in KST?
> >
> > I was busy with university work and event today.
> >
> > Thanks.
> >
> > Best Regards,
> > Paul
> >
> > 2023년 2월 24일 (금) 오전 1:39, Mr. Jaehoon Paul Jeong <[e-mail]>님이
> 작성:
> > 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>
> >
> > --
> > ===========================
> > Mr. Jaehoon (Paul) Jeong, Ph.D.
> > Associate Professor
> > Department of Computer Science and Engineering
> > Sungkyunkwan University
> > Office: [phone]
> > Email: [e-mail], [e-mail]
> > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
>
>
>