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

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

Hi Roman,
How are you nowadays?

It seems like you are very busy with other tasks in the IESG as an AD.
However, IPWAVE WG needs to finish this IPWAVE Problem Statement Draft as
an RFC and it will be closed
after the publication of this IPWAVE Problem Statement Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-29

Could you proofread my revision for your comments as soon as possible?

Thanks.

Best Regards,
Paul


On Wed, Aug 17, 2022 at 12:01 AM Mr. Jaehoon Paul Jeong <
[e-mail]> wrote:

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