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

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

Alice,
Thanks for your considerations.

I will try to finish the proofreading of this RFC this weekend.

Best Regards,
Paul

2023년 2월 25일 (토) 오전 12:07, Alice Russo <[e-mail]>님이 작성:

> 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
>
>
> --
===========================
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
<http://cpslab.skku.edu/people-jaehoon-jeong.php>