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

[[e-mail]]

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