Subject: Last Call: <draft-ietf-ipwave-vehicular-networking-20.txt> (IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases) to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 14 Jun 2021 07:02:40 -0700

The IESG has received a request from the IP Wireless Access in Vehicular
Environments WG (ipwave) to consider the following document: - 'IPv6 Wireless
Access in Vehicular Environments (IPWAVE): Problem
   Statement and Use Cases'
  <draft-ietf-ipwave-vehicular-networking-20.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2021-06-28. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This document discusses the problem statement and use cases of
   IPv6-based vehicular networking for Intelligent Transportation
   Systems (ITS).  The main scenarios of vehicular communications are
   vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and
   vehicle-to-everything (V2X) communications.  First, this document
   explains use cases using V2V, V2I, and V2X networking.  Next, for
   IPv6-based vehicular networks, it makes a gap analysis of current
   IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management,
   and Security & Privacy), and then enumerates requirements for the
   extensions of those IPv6 protocols for IPv6-based vehicular
   networking.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/

No IPR declarations have been submitted directly on this I-D.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 15 Jun 2021 12:12:39 -0700

+1

I was going to write something similar to what Brian wrote.   This document says it is a problem statement, but then becomes a solution document.   Might be better to cut it down to only the problem statement part.

I also noted as Brian points out that the solution part appears to be dependent on OMNI given the “must” language, but OMNI is an informational reference.   This seems like a disconnect.

Bob

> On Jun 14, 2021, at 8:25 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Thanks for the heads-up, Erik.
> 
> This text at https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-20#page-9
> 
>>   Therefore, the existing IPv6 protocol can be
>>   augmented through the addition of an Overlay Multilink Network (OMNI)
>>   Interface [OMNI] and/or protocol changes in order to support both
>>   wireless single-hop/multihop V2V communications and multiple radio
>>   technologies in vehicular networks.
> 
> is of concern regardless of the mention of OMNI. Does it mean "can be" or "needs to be"? This paragraph seems like a very short summary of a big problem area. At the end of page 13 there is some related discussion, which mentions RPL as part of the solution (good choice, IMHO) but again seems to depend on OMNI. I don't think the fix of simply removing references to OMNI works, because it would leave a gap. In an informational document, that is not a formal problem but as far as this draft describes architecture, I don't think that big a gap is reasonable. "OMNI" is mentioned more than 20 times in the document. There are also several references to AERO, which is strongly associated with OMNI.
> 
> At this point I became confused about the purpose of the document. The Abstract says
> 
>>   IPv6-based vehicular networking
> 
> In fact, most of section 4 seems to be a draft architecture of a solution.
> 
>> 5.  Problem Statement
>> 
>>   In order to specify protocols using the architecture mentioned in
>>   Section 4.1, IPv6 core protocols have to be adapted to overcome
>>   certain challenging aspects of vehicular networking.
> 
> That's a big leap. But the rest of section 5 seems to get back to solution design.
> 
> So I am left puzzled about what would happen next if this draft becomes an RFC. Do the authors expect 6man to work on the issues they've raised? I'm not sure they match 6man's limited charter ("not chartered to develop major changes or additions
> to the IPv6 specifications").
> 
> Regards
>   Brian Carpenter
> 
> On 15-Jun-21 13:07, Erik Kline wrote:
>> +6man, since there are many statements about IPv6 work in this document.
>> 
>> One thing of note: in the time after this document was WGLC'd, 6man
>> held an adoption call on OMNI that did not result in adoption [OMNI].
>> There are at two places where this text appears:
>> 
>>   "The existing IPv6 protocol must be augmented through the addition of
>>   an OMNI interface..."
>> 
>> These statements should probably be revised (or removed).
>> 
>> -Erik
>> 
>> [OMNI] https://mailarchive.ietf.org/arch/msg/ipv6/s1S49EYPThX34Gowu4ExPgFb32k/
>> 
>> On Mon, Jun 14, 2021 at 7:02 AM The IESG <[email-masked]> wrote:
>>> 
>>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------