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

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

Alice,
There is one more fix as follows:
-----
- OLD:
when only a few meters off the ground

- NEW:
when only a few hundred meters off the ground
-----

I attach the revised xml file.

Thanks.

Best Regards,
Paul

On Wed, Mar 1, 2023 at 11:35 PM Mr. Jaehoon Paul Jeong <
[e-mail]> wrote:

> 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
>>
>>
>>