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

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

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