Subject: [its] ITS Charter

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 3 Mar 2016 14:50:18 +0000

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.

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

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

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

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

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

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.

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

— Carlos.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 4 Mar 2016 11:11:34 +0100

Hello Carlos, ITSers,

I am travelling right now, sorry.

What do the others think about the comments on the Charter?

Agreeing on a Charter is highly important. Now that the BoF has been
approved (thanks all efforts!) let's continue building our work proposal.

Soon,

Alex

Le 03/03/2016 15:50, Carlos Pignataro (cpignata) a écrit :
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Dapeng Liu <[email-masked]>
Date: Sun, 6 Mar 2016 15:44:45 +0800

Hi Carlos,

Thanks for the comments. Please see my reply inline:

2016-03-03 22:50 GMT+08:00 Carlos Pignataro (cpignata) <[email-masked]>:

> Please find below a couple of additional comments for your consideration,
> prefixed with “CMP” — these also include some nits and questions.
>

[Dapeng] ITS (Intelligent Transportation System) is too broad and we are
thinking whether there is a better name.

> frankly I think short-and-sweet is good.

[Dapeng] We can change the wording to clarify that this group will focus on
1-hop communication between nearby moving networks to narrow down the scope.

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

[Dapeng] Should be ""IP-based".

> (permanently or temporarily)?

[Dapeng] The other one can be fixed network. Will clarify the wording.

> CMP: Again, a small (hopefully non-pedantic) point — that a home net or
> the infrastructure are not moving, likely (reference to the ground :-).
>

[Dapeng] OK. Will add scope&definition of "nearby".

> CMP: I’d add “mandating *secure* communication technology requirements”.

[Dapeng] Agree.

> “naming” are not called out.

[Dapeng]  Yes, discovery should be considered in the solution. Probably we
need to add some text on that.

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

[Dapeng] One draft for all the use-cases and one draft for the problem
statement.

> CMP: What is a path in “1-hop”? Do you mean “connectivity”?

[Dapeng] Yes, maybe “connectivity” is better.

> CMP: MIBs? https://www.ietf.org/iesg/statement/writable-mib-module.html

[Dapeng] OK. Will change "MIBs" to "NETCONF/YANG "...

> Thanks! I hope these are useful

[Dapeng] Thanks, the comments are very helpful.

-Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 7 Mar 2016 03:48:21 +0900

Hi Carlos,

As Dapeng Liu mentioned, we will work on the use cases for V2V and V2I with
one draft and
the problem statements for V2V and V2I with another draft.

Thanks.

Paul
-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 6 Mar 2016 20:07:10 +0100

> https://mailarchive.ietf.org/arch/msg/its/RJIvo8LQEZXSpbaQ5gDq1WqKcBM

Yes.

>
>  Please find below a couple of additional comments for your
> consideration, prefixed with “CMP” — these also include some nits and
> questions.
>
>> ITS (name to change) Charter
>

Right, but we may need a better name.

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

I think IP-based protocols.  For example ICMP is an IP-based protocol, 
whereas WAP (Wireless Application Protocol) is not an IP-based protocol 
because it has no IP headers.

> (permanently or temporarily)?

One can be fixed permanently or temporarily.  An example is a PAN 
entering a homenet, or a spacesuit near a spacecraft (in this context 
it's harder to say what's 'fixed'.)  But one can get the idea.

>> ------------------------------------------------------ The group is
>> concerned with all situations involving moving network to nearby
>> moving network communications.  For example: vehicle-to-vehicle
>> 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
> :-).
>

I agree.  As part of terminology work we will have to define precisely 
what is moving network, and what is a 'nearby moving network'.

>> ------------------------------------------------ Automobiles and
>> vehicles of all types are increasingly connected to the Internet.
>
>> 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.
>

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

Well we can discuss.  It depends what is the "V2I".

An intuitive first thought is that the Internet is all that is fixed.  A 
moving network in an automobile using its GPRS interface is typically 
connecting to the Internet and there is no new work to do, because it's 
already there.

But the Internet could be reached via other vehicles as well, not 
necessarily through its own GPRS link.  The other day driving on the 
highway I followed a disneyland bus; my passenger could connect her 
smartphone to the bus wifi and from there to the Internet.

As such I think moving network reaching the Internet (V2I) is more than 
just using its own cellular link.

The other issue with the "V2I" term is that it means 
"Vehicle-to-Infrastructure" sometimes.  And that V2I does not mean 
Internet.  For example a car at toll situation, or a car on an 
electrical charging station.  One IP computer in the car needs to talk 
to one IP computer among the numerous IP computers in the toll station, 
or in the CS.  And this is a very close server, not on the 
Internet-at-large.

For these reasons in some earlier focused discussion we said it may be 
simpler to just say "reach the rest of the world on the Internet", and 
not assume that just "V2I" covers it all.

> and “naming” are not called out.

I agree they should be.

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

We need to clarify this.

It is 1-hop between the moving networks, but each moving network may 
have several IP hops inside.  That 1-IP-hop between moving networks is 
the only variable characteristic (it's often a WiFi, 11p or other radio 
link) whereas the IP hops inside the moving networks are very stable.

We do not look at more than 1 hop between moving networks - that's MANET.

We can not put any Server on that variable 1-hop.  There's no DHCP 
Server on that 1-hop that could do address allocation, nor DNS server 
that could be discovered with existing link-scoped DNS discovery 
techniques, and no designated Router that could advertise a prefix of 
that link - because the link is very short-lived (it's hard to determine 
quickly prefix ownership on variable links).  If there is any such 
server it must be either in the fixed infrastructure, or in the fixed 
part inside a moving network.

> CMP: Also, the Goal above is about “connectivity”.

Yes, connectivity at IP layer, in the sense that an IP device must 
become able to talk to any other IP device in a nearby (1-hop) moving 
network.

>> In this proposed Working Group the focus is on 1-hop protocols,
>> and leverage from other Working Groups for the n-hop situations.
>
>> 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?

Currently we think 1 PS draft and 1 use-case draft (including V2V and 
V2I sections).  But we need to agree.

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

I agree.

> CMP: What is a path in “1-hop”? Do you mean “connectivity”?

I think we should say a path is between IP devices and that there may be 
n hops between them.  But there is only one variable part which is the 
crux of the problem - the 1-hop between moving networks which is 
typically a radio link (or visible light comms, or 
IP-over-charge-while-driving rails).

The paths are like this:

     IP1-----Router----Router .... Router---Router----IP2

The dashed lines are fixed links inside the moving networks and the dots 
are the 1-hop which makes the problem.

> CMP: MIBs?
> https://www.ietf.org/iesg/statement/writable-mib-module.html

I agree we should.

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

Yes, the charter should be modified accordingly.

Alex

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

---

From: Rex Buddenberg <[email-masked]>
Date: Sun, 06 Mar 2016 14:42:44 -0800

> connecting to the Internet and there is no new work to do, because

Alex, you are sniffing at what I think are the right things here.  Let
me sort a bit; I think there are three topics that must be handled,
although a good share of such handling is a layer 2 issue (meaning out
of scope for IETF):

What does 'radio' mean?

1.  Topology -- shared medium.  The wired internet is almost all
point-to-point connectivity so the stitching together of >2 parties is a
layer 3 routing problem.  But in a radio-WAN, several parties (routers)
may be attached to a single segment.  (The problem is masked with
wireless LANs, or wired LANs for that matter).  Rather fundamental
topology issue.

2.  Economy -- Bandwidth constraint.  In the wired internet, we're
routinely provisioning at 10s of G.  ... and can always add a second
fiber pair.  In radio, we're spectrum limited and the limits are about 4
orders of magnitude less.  

3.  with a shared media you need a means to share it -- a MAC.
Terrestrial internet technologies (ADSL, DWDM, ...) lack MACs because
they don't need them.  But we sure need one with radio.  (There are only
two kinds of MACs out there -- contention and contention-free).

4.  multicast.  With point-to-point connectivity, which can be
overprovisioned, the payoffs to multicast are not obvious.  But with a
capacity-constrained media, and a shared media at that, the payoffs to
multicast are compelling.

A thoughtful analysis of the differences between wired and radio media
in the internet ought to yield some fruitful charter thinking.  Above
help?

b