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