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

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