Subject: Re: [its] ITS Charter

From: Nabil Benamar <[email-masked]>
Date: Fri, 4 Mar 2016 16:52:36 +0000

Hi Carlos,

answers in the text.

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

http://nabilbenamar.ipv6-lab.net/

On Thu, Mar 3, 2016 at 2:50 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Hi, ITS,
>
> It seems this is the most recent message regarding the draft charter:
>
> https://mailarchive.ietf.org/arch/msg/its/RJIvo8LQEZXSpbaQ5gDq1WqKcBM
>
> Please find below a couple of additional comments for your consideration,
> prefixed with “CMP” — these also include some nits and questions.
>
> I would encourage thorough review and list discussion of this charter text.
>
> >               ITS (name to change)
> >                     Charter
>
> CMP: ITS does not seem to expand to “name to change” :-)
>
> > Goal
> > ----
> > The goal of this group is to standardize IP protocols for establishing
> > direct and secure connectivity between moving networks.
>
> CMP: My initial reaction was that perhaps this was a bit too broad — but
> frankly I think short-and-sweet is good.
> ​
>

​What do you mean by short-and-sweet ?​

​what kind of sweetness in this context ?​

> ​
>
>
> CMP: Are these “IP protocols” or “IP-based protocols”?
>

​These are IP protocols and IPv6 more precisely ! ​

>
> CMP: Is this between moving networks only, or can one be fixed
> (permanently or temporarily)?
>

​I think that the draft covers all aspects of networks but we are more
focusing on V2V, moving networks to moving networks.​

>
> > Moving Network to Nearby Moving Network Communications
> > ------------------------------------------------------
> > The group is concerned with all situations involving moving network to
> > nearby moving network communications.  For example: vehicle-to-vehicle
> > communications, nomadic user wearing a PAN and communicating to a
> > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a
> > train, or train-to-intersection signalling.
>
> CMP: Again, a small (hopefully non-pedantic) point — that a home net or
> the infrastructure are not moving, likely (reference to the ground :-).
>
> CMP: What is “nearby" moving? Might not hurt do scope/define it.
>

​I think that Link layer media can differ based on the scope of the signal
!​

>
> > Example from the automobile communications space
> > ------------------------------------------------
> > Automobiles and vehicles of all types are increasingly connected to
> > the Internet.
>
> CMP: Same distinction — vehicle-to-vehicle, or vehicle-to-Internet, or
> vehicle-to-infra?
>
> > in automobiles to hit the roads from now to year 2020. Highlighting
> > increased safety as an immediate result of hyper-connectivity applied
> > to vehicles, public authorities worldwide are increasingly mandating
> > communication technology requirements in vehicles.
>
> CMP: I’d add “mandating *secure* communication technology requirements”.
>

​Agree​

>
>
> > IP communication between vehicles (V2V), and between vehicles and the
> > immediate infrastructure (V2I), will provide (0) ability to reach the
> > rest of the world on the Inerenet (1) short and deterministic delays,
> > (2) fast forwarding through scalable paths of routers, (3) ease of
> > reuse of existing Internet applications in a vehicular environment.
>
> CMP: Typo, s/Inerenet/Internet/.
>

​Agree​

>
> CMP: Now, Isn’t (0) already provided (a few paragraphs above) with
> vehicle-to-Internet?
>
​

>
> CMP: A meta-comment, I am surprised that requirements of “discovery” and
> “naming” are not called out.
>

​Agree, since we are mentioning ​

​IPv6 so NDP by default​

>
> > What kind of solutions?
> > -----------------------
> > The current technical solutions considered to achieve moving network
> > to nearby moving network communications are of two kinds: IP routing
> > protocols for n-hop path management and 1-hop link-scoped IP protocol
> > enhancements.
>
> CMP: It would be useful to also here specify scope of solutions in terms
> of number of hops — I thought this was 1-hop.
>
> CMP: Also, the Goal above is about “connectivity”.
>
> > In this proposed Working Group the focus is on 1-hop protocols, and
> > leverage from other Working Groups for the n-hop situations.
>
> CMP: Sorry, what follows is this paragraph, forget my previous comment :-)
>
> > Work Items
> > ----------
> > - use-cases for moving network to nearby moving network communications
> > - Problem Statement for moving network to nearby moving network
> > communications
>
> CMP: Are you thinking of use-cases and problem statements as individual
> work items (drafts)? Are these one? And in fact one for V2V and V2I?
>

​This one is a charter, and drafts are the outcomes of the work of wg
members​. However, the current charter is still a draft that could be
improved base on the comments in the list!

> > - Security and Privacy Requirements for moving network to
> >    nearby moving network communications
> > - Problem Statement for moving network to infrastructure network
> >    communications, including DNS
> > - Potentially new protocol, or protocol extensions for establishing IP
> >    paths for 1-hop moving network to nearby moving network
> communications.
> >    With MIB and security.
>
> CMP: I’d say ‘Solutions, which might include new protocols or extensions
> to existing protocols”
>
> CMP: What is a path in “1-hop”? Do you mean “connectivity”?
>
> CMP: MIBs? https://www.ietf.org/iesg/statement/writable-mib-module.html
> > - IPv6-over foo, where foo is pertinent for moving network to nearby
> >    moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)
>
> Thanks! I hope these are useful
>

​Very useful !​

>
> — Carlos.
>
>
>
>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>
>

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 04 Mar 2016 11:41:07 -0800

Nabil, Carlos,

There's a sensitivity in here that, from a purely IETF experience, you
might not be aware of.

In US, National Highway Traffic Safety Agency (part of Dept of
Transportation) is mandating a set of standards for vehicle-vehicle
communications.  The IEEE 1609 committee is trying to respond to this
mandate by writing a set of standards.  The vehicle-to-vehicle protocol
stack voids the network and transport layers and, IMHO, cops out with a
single-hop protocol stack (including a catalog of content messages).  
     The single-hop solution has, again IMHO, several shortcomings with
reach and discrimination.  
     1609 has a dual-stack cartoon with IPv6 stack as the second stack
(and not much attention to it).  Other than that, there's very little
internetworking in the discussion or draft standard.  
     My litmus test use case is an instrumented ambulance.  You want
things like 'virtual siren' to alert other vehicles on the road.  But
you also want to telemeter casualty data to the ER -- clearly an
extend-the-internet case.  Putting these in separate standards
stovepipes is, again IMHO, a bad idea.  

Alex is trying to head off some of this in the language he chose.  I
might not have written it the same way, but this is at least part of the
reasoning.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 7 Mar 2016 10:42:53 +0100

Le 04/03/2016 20:41, Rex Buddenberg a écrit :
> Nabil, Carlos,
>
>
> There's a sensitivity in here that, from a purely IETF experience,
> you might not be aware of.
>

Thanks for this.  I will add it to draft-petrescu-its-cacc-sdo.

> The IEEE 1609 committee is trying to respond to this mandate by
> writing a set of standards.  The vehicle-to-vehicle protocol stack
> voids the network and transport layers and,

Right.

> IMHO, cops out with a single-hop protocol stack (including a catalog
> of content messages). The single-hop solution has, again IMHO,
> several shortcomings with reach and discrimination. 1609 has a
> dual-stack cartoon with IPv6 stack as the second stack (and not much
> attention to it).  Other than that, there's very little

I agree.

One would be careful qualifying the 1609 work as 1-hop.  The
1609 perspective may not consider - currently - that 1-hop to be 
(exclusively) an IP 1-hop.

Prototypes have however exposed a need for the 1-hop to be IP.  As the
number of in-vehicle specific applications grows relentlessly it becomes
harder to add dedicated communication boxes for each.  For this reason,
some prototypes use 1609 messaging _over_ IP along 1 or 2 IP hops, along
with other more classical TCP/IP messages such as web browsing.

Additionally, security work in 1609 and elsewhere (ITU) consider the use 
of certificates.  These 'vehicular' certificates are very friendly with 
being carried over IP.

> stovepipes is, again IMHO, a bad idea.

I agree.  The instrumented ambulance is an important user of these 
vehicular networks.  Their requirements are very strong and with 
heterogeneous applications.

If somebody from the public safety space is attending Buenos Aires, we 
have a slot for the public safety in the agenda.

Alex

> might not have written it the same way, but this is at least part of
> the reasoning.
>
>
>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>