Re: [ipwave] Éric Vyncke's No Objection on draft-ietf-ipwave-vehicular-networking-29: (with COMMENT)

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

Hi Erik and Roman,
I am looking forward to seeing the confirmation of Roman that says
that this revision has cleared Roman's DISCUSS:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-29

Thanks.

Best Regards,
Paul


On Mon, Jul 25, 2022 at 12:10 AM Erik Kline <[e-mail]> wrote:

> Re-up'ing this thread.
>
> The datatracker claims "Has enough positions to pass once DISCUSS
> positions are resolved", so if Roman is satisfied, then I think it can be
> forwarded on to the RFC Editor.
>
> On Sat, Jul 16, 2022 at 1:41 AM Mr. Jaehoon Paul Jeong <
> [e-mail]> wrote:
>
>> Hi Roman and Erik,
>> Thanks for your guidance and help on the IPWAVE Problem Statement Draft.
>> https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/
>>
>> Roman,
>> Could you confirm whether my revision satisfies your comments or not even
>> though you are super-busy?
>>
>> Erik,
>> Could you ask another IESG member to ballot on our IPWAVE Problem
>> Statement Draft
>> because this draft needs at least 10 votes with either Yes or No
>> objection?
>>
>> Thanks.
>>
>> Best Regards,
>> Paul
>>
>>
>> On Sun, Jun 26, 2022 at 6:03 AM Erik Kline <[e-mail]> wrote:
>>
>>> Roman,
>>>
>>> I'm not sure if your points are addressed just yet, but figured I would
>>> ask.  =)
>>>
>>> ---------- Forwarded message ---------
>>> From: Erik Kline <[e-mail]>
>>> Date: Sat, Jun 25, 2022 at 2:02 PM
>>> Subject: Re: Éric Vyncke's No Objection on
>>> draft-ietf-ipwave-vehicular-networking-29: (with COMMENT)
>>> To: Éric Vyncke <[e-mail]>
>>> Cc: The IESG <[e-mail]>, <
>>> [e-mail]>, <
>>> [e-mail]>, <[e-mail]>, Carlos Bernardos <
>>> [e-mail]>
>>>
>>>
>>> Thank you Eric, and thank you Paul!
>>>
>>> On Sat, Jun 25, 2022 at 12:25 AM Éric Vyncke via Datatracker <
>>> [e-mail]> wrote:
>>>
>>>> Éric Vyncke has entered the following ballot position for
>>>> draft-ietf-ipwave-vehicular-networking-29: No Objection
>>>>
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>>
>>>>
>>>> Please refer to
>>>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>>> for more information about how to handle DISCUSS and COMMENT positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>> Thank you for the work put into this document. I found the use cases
>>>> part of
>>>> section 3.1 very interesting to read even if some of them seem very far
>>>> fetched
>>>> ;-)
>>>>
>>>> I have now cleared my previous blocking DISCUSS points as you have
>>>> addressed
>>>> them as well as all but one of my previous non-blocking COMMENTs.
>>>> Thanks for
>>>> your reaction.
>>>>
>>>> I have kept below the DISCUSS & COMMENT points just for archiving,
>>>> please
>>>> ignore them.
>>>>
>>>> Special thanks to
>>>>
>>>> - Carlos Bernardos for the shepherd's write-up even if a justification
>>>> for the
>>>> informational status would have been welcome but the WG consensus
>>>> description
>>>> is appreciated.
>>>>
>>>> - Pascal Thubert for his IETF last call INT directorate review at:
>>>>
>>>> https://datatracker.ietf.org/doc/review-ietf-ipwave-vehicular-networking-20-intdir-lc-thubert-2021-06-18/
>>>> and for his IESG telechat INT directorate review
>>>>
>>>> https://datatracker.ietf.org/doc/review-ietf-ipwave-vehicular-networking-27-intdir-telechat-thubert-2022-02-28/
>>>> Pascal's Last Call & telechat reviews were (at least partially) acted
>>>> upon by
>>>> Paul ;-)
>>>>
>>>> I hope that this helps to improve the document,
>>>>
>>>> Regards,
>>>>
>>>> -éric
>>>>
>>>> # DISCUSS (just for archiving)
>>>>
>>>> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/,
>>>> a
>>>> DISCUSS ballot is a request to have a discussion on the following
>>>> topics:
>>>>
>>>> ## Abstract & Section 1
>>>>
>>>> "then enumerates requirements for the extensions of those IPv6
>>>> protocols" does
>>>> not match any IPWAVE WG work item, i.e., it is outside the scope of the
>>>> charter
>>>> of IPWAVE WG. As the document does not explicitly specify requirements,
>>>> I
>>>> strongly suggest to use the word "gaps" rather than "requirements" in
>>>> the
>>>> abstract and section 1.
>>>>
>>>> ## Section 4.1
>>>>
>>>> Using an IPv6 address out of a ULA prefix still requires DAD. So the
>>>> text below
>>>> should be updated to be corrected:
>>>>   "their own IPv6 Unique Local Addresses
>>>>    (ULAs) [RFC4193] over the wireless network, which does not require
>>>>    the messaging (e.g., Duplicate Address Detection (DAD)) of IPv6
>>>>    Stateless Address Autoconfiguration (SLAAC) [RFC4862]."
>>>>
>>>> ## Section 4.2
>>>>
>>>> Very similar comment as above (i.e., DAD & MLD must be done for all IPv6
>>>> addresses of an interface and not only for the global one):
>>>>   "... When global IPv6
>>>>    addresses are used, wireless interface configuration and control
>>>>    overhead for DAD"
>>>>
>>>> ## Section 5.2
>>>>   "... If DHCPv6 is used to assign
>>>>    a unique IPv6 address to each vehicle in this shared link, DAD is not
>>>>    required. "
>>>> This is incorrect and must be changed (see section 18.2.10.1. of RFC
>>>> 8415)
>>>>
>>>> # COMMENTS (just for archiving)
>>>>
>>>> "100km/h as the speed limit in highway" will make many European drivers
>>>> smile
>>>> as it is really slow...
>>>>
>>>> ## Section 1
>>>>
>>>> "Most countries and regions in the world have adopted the same frequency
>>>> allocation for vehicular networks." but there are TWO frequency
>>>> allocations
>>>> described just before, so, which one has been adopted ?
>>>>
>>>> ## Section 2
>>>>
>>>> "GPS" is just the USA commercial example of the more generic "global
>>>> navigation
>>>> satellite system" (GNSS), GNSS should be used in this document.
>>>>
>>>> As IP-RSU have at least 2 interfaces, should "Also, it may have *the*
>>>> third
>>>> IP-enabled wireless interface" be replaced by "Also, it may have *a*
>>>> third
>>>> IP-enabled wireless interface" ?
>>>>
>>>> LiDAR ... "by measuring the reflected pulsed light" but on which kind of
>>>> metrics ?
>>>>
>>>> ## Section 3.1
>>>>
>>>> Should the 1st and 5th bullets be grouped together ?
>>>>
>>>> Please describe "UAM" (e.g., in the terminology section) as it is
>>>> unclear to
>>>> the reader whether it is a crewed / uncrewed aircraft.
>>>>
>>>> If both road and air vehicles are use case, what about river / sea
>>>> ships or
>>>> trains ?
>>>>
>>>> Does the paragraph about "reward system" belong to the use case ? It
>>>> rather
>>>> sounds like a business requirement. Suggest to remove this part.
>>>>
>>>> Like written by Pascal Thubert in his telechat review, the last
>>>> paragraph
>>>> "IPv6-based packet exchange and secure" should be clear that this is
>>>> not only
>>>> about data plane traffic but also control plane L2/L3 ones. Please also
>>>> use the
>>>> Oxford comma, i.e., add a "," after "exchange".
>>>>
>>>> ## Section 3.2
>>>>
>>>> Suggest to also mention "5G" after "IP-RSU or 4G-LTE networks"
>>>>
>>>> How is the UAM use case different from a driverless terrestrial EV ?
>>>> Suggest to
>>>> merge those use cases.
>>>>
>>>> ## Section 4.1
>>>>
>>>> As noted by other ADs, "Existing network architectures," the list
>>>> should not
>>>> include OMNI yet as it is not deployed and would probably not be
>>>> described as
>>>> an architecture.
>>>>
>>>> "the wireless media interfaces are autoconfigured with a global IPv6
>>>> prefix",
>>>> is it the same shared prefix or multiple prefixes ?
>>>>
>>>> Is "RSU" the same concept as "IP-RSU" ?
>>>>
>>>> The last paragraph is about TCP session continuity, but does not
>>>> explain why
>>>> multi-path TCP or QUIC session resumption cannot be used.
>>>>
>>>> ## Section 4.2
>>>>
>>>> The computation about "dwell time" is interesting even if it is
>>>> computed in the
>>>> best case. But, I really wonder whether using IPv6 and routing are
>>>> applicable
>>>> to the use case as opposed to more layer-2 + tunnel solutions (like
>>>> 3GPP) with
>>>> such short time for hand-over. I am a strong supporter of layer-3 (IPv6
>>>> and
>>>> routing), but I cannot refrain from thinking that IPv6 is the wrong
>>>> technical
>>>> solution for those use cases... Was this discussed in the WG ?
>>>>
>>>> ## Section 5.1
>>>>
>>>> What is "legacy DAD" ?
>>>>
>>>>   "...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"
>>>> With the issues linked to multicast over wireless, are the authors and
>>>> the WG
>>>> sure that increasing the amount of multicast will not aggravate the
>>>> problem ?
>>>> See RFC 9119 (cited as a normative down reference)
>>>>
>>>> ## Section 5.1.2
>>>>
>>>> Please add some references to the MADINAS WG current work items. The
>>>> authors
>>>> may also consider adding this use case to the MADINAS use case.
>>>>
>>>> "The pseudonym of a MAC address affects an IPv6 address based on the MAC
>>>> address", nearly no implementations use EUI-64 anymore so this part
>>>> should
>>>> probably be removed from the document. But, the change of MAC address
>>>> probably
>>>> has other impact on the IP stack, e.g., the neighbour cache.
>>>>
>>>> ## Section 5.1.3
>>>>
>>>> AFAIK, RPL relies on messages to discover the topology and I am afraid
>>>> that in
>>>> such a moving / dynamic environment, there will be too many of RPL
>>>> messages.
>>>> Will RPL scale in this ever changing network ? Please note that I am
>>>> not a RPL
>>>> expert.
>>>>
>>>> ## Section 6.1
>>>>
>>>> Some explanations on how SEND protects against DAD flooding would be
>>>> welcome.
>>>>
>>>> Is "classical IPv6 ND" the same as the previously used "legacy ND" ?
>>>>
>>>> Wondering why "Vehicle Identification Number (VIN)" is suggested to be
>>>> used as
>>>> SubjectAltName in a certificate rather than a car manufacturer cert ?
>>>>
>>>> ## Section 6.3
>>>>
>>>> The part about bitcoin and blockchain errs probably too far away from
>>>> the IETF
>>>> remit.
>>>>
>>>> ## Appendix B
>>>>
>>>> I fail to understand how RPL and OMNI can be compared as they are vastly
>>>> different technologies (routing vs. tunneling).
>>>>
>>>> "In OMNI protocol, each wireless media interface is configured with an
>>>> IPv6
>>>> Unique Local Address (ULA)" but from my last read of OMNI drafts (1+
>>>> year ago),
>>>> the OMNI virtual interface can have a ULA indeed but the wireless
>>>> physical ones
>>>> are using any prefix.
>>>>
>>>> ## Appendix D
>>>>
>>>> What will be the impact of high packet loss rate (that I am expecting
>>>> on such
>>>> networks) on IP parcels ?
>>>>
>>>> # NITS
>>>>
>>>> Please check that all IPv6 addresses are in lowercase (e.g., in section
>>>> 4.1).
>>>>
>>>>
>>>>
>>>>