Subject: Re: [its] latest charter text

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 2 May 2016 15:40:49 +0200

Le 29/04/2016 20:21, Templin, Fred L a écrit :
> Hi, I have one other charter text suggestion:
>
>> Co-existence with techniques of infrastructure mobility management will
>> be coordinated with the DMM Working Group and with LISP Working Group.
>
> Add to this:
>
>    Other infrastructure mobility management solutions such as AERO will
>    also be considered.

Fred,

Let's bring that later.

Alex

> Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 2 May 2016 15:48:33 +0200

Hi ITSers,

The latest charter text is now at http://tools.ietf.org/wg/its/trac

Alex

Pasted here for convenience:
'''Intelligent Transportation Systems (its), Charter'''

'''Chairs'''
    Russ Housley, Carlos Pignataro

'''Assigned Area Director'''
    Suresh Krishnan

'''Mailing list'''
    Address: [email-masked]
    To Subscribe: https://www.ietf.org/mailman/listinfo/its
    Archive:
    http://www.ietf.org/mail-archive/web/its/current/maillist.html

'''Additional web page'''
    TBD

'''Charter'''
{{{
Automobiles and vehicles of all types are increasingly connected to
the Internet.  Comfort-enhancing entertainment applications, road
safety applications using bidirectional data flows, and connected
automated driving are but a few new features expected in automobiles
to hit the roads from now to year 2020.

Today, there are several deployed Vehicle-to-Internet technologies
(V2Internet) that make use of embedded Internet modules, or through
driver's cellular smartphone: mirrorlink, carplay, android auto.
However, Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I,
not to be mistaken with V2Internet) communications are still being
developed.

In the future, some vehicle communications may not use IP for
exchanging safety messages with other vehicles and infrastructure.
Other vehicle communications may involve IP-based protocols,
especially when multiple applications need to share one data link.

This group will work on V2V and V2I use-cases where IP is well-suited
as a networking technology, supporting also applications that involve
exchanges of safety-related messages between vehicles and
infrastructure if necessary.

This group will develop IP-based protocols to establish direct and
secure connectivity between a vehicle, which is often comprised of
moving networks, and other vehicles and stationary systems.  Some
communications will be extremely short lived, but others will last for
many hours or days.

Moving network to nearby moving or fixed network communications may
involve various kinds of link layers: 802.11-OCB (Outside the Context
of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ad, VLC (Visible
Light Communications), IrDA, LTE-D, LP-WAN.  One of the most used link
layers for vehicular networks is IEEE 802.11-OCB, as a basis for DSRC.
However, IPv6 on 802.11-OCB is not yet defined.

The group will only work on IPv6 solutions.

The group will leverage on technologies for Internet of Things (IoT)
which are developed in other IETF efforts: 6lo, LP-WAN, T2T.
Co-existence with techniques of infrastructure mobility management
will be coordinated with the DMM Working Group and with LISP Working
Group.

The SDOs interested in this work are: ISO/TC204, ETSI TC ITS, 3GPP,
NHTSA and more.

This group will not work on V2V or V2I use-cases where IP is not
well-suited.  It will not work on Delay-Tolerant Networking nor on
Information-Centric Networking.

If the group is successful in accomplishing its first goals, then it
can be rechartered to work on other things (examples include but are
not limited to: a 1-hop mechanism of IP prefix exchange between moving
networks, an n-hop extension, naming for moving networks;
generalization for trains, air, unmanned and space use-cases).
}}}
'''Work items'''
{{{
1. Informational RFC "ITS General Problem Area" covering:
   - What is ITS?
      - Explain V2V, V2I, and related terms
   - Why is IPv6 needed?
      - Explain why some traffic will not use IPv6
      - Explain why other traffic will use IPv6
   - Use-cases, illustrating the expected areas for initial focus
   - Informative references, relationship with other SDOs

2. Standards Track RFC "IPv6 over DSRC"

3. Informational RFC "Problem Statement" covering:
    - Problem statement
    - Security considerations
    - Privacy considerations
}}}
'''Goals and milestones'''
{{{
Oct 2016 - submit "ITS General Problem Area" to WG

Dec 2016 - submit "IPv6 over DSRC" to WG

Jun 2017 - submit "ITS General Problem Area" to IESG

Jun 2017 - submit "IPv6 over DSRC" to IESG

Sep 2017 - submit "Problem Statement" to WG

May 2018 - submit "Problem Statement" to IESG
}}}

---

From: Michelle Wetterwald <[email-masked]>
Date: Fri, 6 May 2016 16:38:04 +0200

Hi Alex, all,

It is a good idea to restrict to those use cases where IPv6 can be helpful.
There are a lot of potential use cases for that and it will avoid creating
fragmentation of solutions, as can be seen in other domains. Waiting now
for preliminary versions of the informational rfc. We are doing some work
at ETSI STF 505 on smart mobility standardization landscape and gap
analysis which may be used as a reference.

Best regards,
Michelle

2016-05-02 15:48 GMT+02:00 Alexandre Petrescu <[email-masked]>
:

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

-- 
Michelle Wetterwald
[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 9 May 2016 13:15:18 +0200

Hi Michelle,

Le 06/05/2016 à 16:38, Michelle Wetterwald a écrit :
> Hi Alex, all,
>
> It is a good idea to restrict to those use cases where IPv6 can be
> helpful. There are a lot of potential use cases for that and it will
> avoid creating fragmentation of solutions, as can be seen in other
> domains. Waiting now for preliminary versions of the informational
> rfc.

Do you mean for item 1 "ITS General Problem Area"?

Some drafts have been submitted along these lines, and some others are
prepared.

> We are doing some work at ETSI STF 505 on smart mobility
> standardization landscape and gap analysis which may be used as a
> reference.

Is ETSI STF 505 dealing also with the vehicular communications part of
IoT LSPs, like Pilot5? or just smartcities/smartliving?

If the former, then we may need to cite ETSI STF 505 documents.
Otherwise no.

I am asking because the ETSI STF 505 homepage does not seem to mention
vehicles such as automobiles, but more smartcities/smartliving.

Alex

>
> Best regards, Michelle
>
>
> 2016-05-02 15:48 GMT+02:00 Alexandre Petrescu
> <[email-masked]
> <mailto:[email-masked]>>:
>
> Hi ITSers,
>
> Pasted here for convenience: '''Intelligent Transportation Systems
> (its), Charter'''
>
> '''Chairs''' Russ Housley, Carlos Pignataro
>
>
> '''Assigned Area Director''' Suresh Krishnan
>
> '''Mailing list''' Address: [email-masked] <mailto:[email-masked]> To
> Subscribe: https://www.ietf.org/mailman/listinfo/its Archive:
> '''Additional web page''' TBD
>
> '''Charter''' {{{ Automobiles and vehicles of all types are
> increasingly connected to the Internet.  Comfort-enhancing
> entertainment applications, road safety applications using
> bidirectional data flows, and connected automated driving are but a
> few new features expected in automobiles to hit the roads from now to
> year 2020.
>
> However, Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure
> (V2I, not to be mistaken with V2Internet) communications are still
> being developed.
>
> This group will work on V2V and V2I use-cases where IP is
> well-suited as a networking technology, supporting also applications
> that involve exchanges of safety-related messages between vehicles
> and infrastructure if necessary.
>
> communications will be extremely short lived, but others will last
> for many hours or days.
>
> involve various kinds of link layers: 802.11-OCB (Outside the
> Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ad, VLC
> (Visible Light Communications), IrDA, LTE-D, LP-WAN.  One of the most
> used link layers for vehicular networks is IEEE 802.11-OCB, as a
> basis for DSRC. However, IPv6 on 802.11-OCB is not yet defined.
>
> not limited to: a 1-hop mechanism of IP prefix exchange between
> moving networks, an n-hop extension, naming for moving networks;
> generalization for trains, air, unmanned and space use-cases). }}}
> '''Work items''' {{{ 1. Informational RFC "ITS General Problem Area"
> covering: - What is ITS? - Explain V2V, V2I, and related terms - Why
> is IPv6 needed? - Explain why some traffic will not use IPv6 -
> Explain why other traffic will use IPv6 - Use-cases, illustrating the
> expected areas for initial focus - Informative references,
> relationship with other SDOs
>
> 3. Informational RFC "Problem Statement" covering: - Problem
> statement - Security considerations - Privacy considerations }}}
> '''Goals and milestones''' {{{ Oct 2016 - submit "ITS General Problem
> Area" to WG
>
> _______________________________________________ its mailing list
> [email-masked] <mailto:[email-masked]>
> -- Michelle Wetterwald [email-masked]
> <mailto:[email-masked]>

---

From: Michelle Wetterwald <[email-masked]>
Date: Tue, 10 May 2016 12:57:15 +0200

Hi Alex,

STF 505 is looking at seven verticals domains, five of them are those
addressed by the LSPs.
In particular, we are covering Smart Cities and Smart Mobility, which
include ITS and may be relevant here.
The result of the technical study will be published as TR 103 375
(standards landscape) and TR 103 376 (gap analysis).
You can cite these reports, as they also mention IPv6 for these domains,
together with other V2X standards.

Best, Michelle

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 17 May 2016 16:31:41 +0200

Hello,

Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit :
[...]
> 2. Standards Track RFC "IPv6 over DSRC"

This particular mentioning of "IPv6 over DSRC" has raised a number of 
questions.

Do you think it is the appropriate title?

Alex

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 17 May 2016 19:28:37 -0700

shared medium

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 May 2016 09:23:54 +0200

Well yes, it's a shared medium.

But "IPv6-over-foo" documents are titled something like:
"Transmission of IPv6 Packets over Ethernet Networks"      RFC 2464
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks" RFC 4944
"Transmission of IPv6 Packets over ITU-T G.9959 Networks"  RFC 7428

What could DSRC in "IPv6 over DSRC" mean?  The 802.11 OCB link? 
802.11p?  The set of WAVE WSMP messages?

I am tempted to believe that in this context "DSRC" means "802.11 OCB".

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 24 May 2016 14:41:29 +0200

Hello ITSers,

I discussed with people involved in GCDC, yogoko, and open source of 
ETSI ITS CAM (github.com/alexvoronov/geonetworking), IEEE 802.11p 
(github.com/CTU-IIG/802.11p-linux) and SAE BSM at itsforge.net.

At this time I believe the title of the work item number 2 should be:

        "IPv6 over 802.11p" and not "IPv6 over DSRC".

In this title the "DSRC" term was a source of confusion:
- it means link-layer in some context but app-layer in other,
- the  authoritative source of definition of 'DSRC' seems to be SAE,
   but not sure whether it's rather IEEE, or other - not sure where to
   look for it.

On the contrary, '802.11p' is clearly defined as 'Outside the Context of 
a BSSID of 802.11' by IEEE.  It always means link-layer (there are no 
802.11p applications - an application runs equally well on 802.11b as on 
802.11p).

I will modify the title in the work item charter proposal accordingly.

This does not preclude that later we can work on "Transmission of DSRC 
messages like BSM over IPv6 over 802.11p".

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 25 May 2016 09:47:45 +0200

Le 25/05/2016 à 00:46, Dick Roy a écrit :
> There are two problems with using the term "802.11p".
>
> 1) Technically, it no longer exists within IEEE 802.  If you go to try to
> find documentation on it, it will be difficult at best.

I can agree.

Instead of saying 802.11p, how about:

"IPv6 over 802.11-OCB, with optional Timestamp Advertise Message, and 
with half-rate OFDM at 5.9GHz"

The unique IEEE document is called "802.11" and has a "OCB" flag. (there 
are no longer 802.11b, or 802.11g documents, nor 802.11p for that matter.)

> 2) Being outside the context of a BSS has NOTHING to do with any mods or
> additions to IPv6 functions that might be required.

In a sense yes, but indirectly there may be some needs.

Indeed being OCB does not change the fact that the ethertype must be 
0x86DD (and not 0x8947 geonet, nor 0x88DC WAVE)- this maybe the single 
most important point of such a spec.

But there could be some other needs.

What do you think could be other needs?

The ones I think of are the following:

Being OCB means there is no link-layer security, which means that 
IPv6-over-OCB MUST use some IP security mechanism - there is no 
optionality.  It is a fundamental requirement.

Being OCB has some other impacts in IP handovers between OCB links.

Being OCB and with TSA may mean that rather than TSA one should use an 
IPv6 Router Advertisement containing a timestamp.

> You would do well to simply drop any mention of ANY particular MAC&PHY and
> do not use the word "over" in the title (or your thoughts, for that matter).

In a sense yes, but the use of "over" is not my particular thought.  I 
learned this at IETF.  There is an established practice of writing "IPv6 
over foo documents":

RFC 2464 "IPv6 over Ethernet"
RFC 2470 "IPv6 over Token Ring"
...
RFC 4944 "IPv6 over 802.15.4"
etc.

Currently there are numerous ongoing "IPv6 over foo" efforts at IETF, 
e.g. "IPv6 over NFC":
https://tools.ietf.org/html/draft-ietf-6lo-nfc-03

> Simply think of "networks with rapidly changing topology and unreliable
> links" ... GOOD ENOUGH.

Good enough, but there is other ongoing work of that kind:
"Multi-hop Ad Hoc Wireless Communication"
draft-ietf-intarea-adhoc-wireless-com-01 abstract:
>    This document describes characteristics of communication between
>    interfaces in a multi-hop ad hoc wireless network, that protocol
>    engineers and system analysts should be aware of when designing
>    solutions for ad hoc networks at the IP layer.
https://tools.ietf.org/html/draft-ietf-intarea-adhoc-wireless-com-01

(that document is not particular to vehicular communications, doesnt use 
OCB).

Alex

>
> Cheers,
>
> RR
>
> -----Original Message-----
> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Tuesday, May 24, 2016 5:41 AM
> To: [email-masked]
> Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p"
>
> Hello ITSers,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 25 May 2016 10:50:33 +0200

Le 25/05/2016 à 00:49, Dick Roy a écrit :
> Any mention of messages and/or message types that could or should or
> might or can't or whatever be sent using this "new IP functionality"
> is out of scope.  IPv6 connectivity in highly transient environments
> is the goal. Just keep it simple!

I fully agree.  That's why "DSRC" in the title is not simple at all.

> Saying you are going to send BSMs using IPv6 is going to needlessly
> ruffle some big feathers!

I agree.  Sending BSM over IPv6 over 802.11p may be an activity for 
later, if proven necessary.

(BSM stands for "Basic Safety Message" and is defined by the Society of
Automotive Engineers in the standard J2735_201603 "DSRC Message Set
Dictionary", paying access; a BSM is however dissected by the freely
available open source wireshark tool, and some packet captures are
freely available open source at
http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files#82)

Alex

>
> RR
>
> -----Original Message----- From: Alexandre Petrescu
> [mailto:[email-masked]] Sent: Tuesday, May 24, 2016
> 5:41 AM To: [email-masked] Subject: Re: [its] latest charter text -
> title of items "IPv6 over 802.11p"
>
> Hello ITSers,
>
> In this title the "DSRC" term was a source of confusion: - it means
> link-layer in some context but app-layer in other, - the
> authoritative source of definition of 'DSRC' seems to be SAE, but not
> sure whether it's rather IEEE, or other - not sure where to look for
> it.
>
> On the contrary, '802.11p' is clearly defined as 'Outside the Context
> of a BSSID of 802.11' by IEEE.  It always means link-layer (there are
> no 802.11p applications - an application runs equally well on 802.11b
> as on 802.11p).
>
> This does not preclude that later we can work on "Transmission of
> DSRC messages like BSM over IPv6 over 802.11p".
>
> Alex
>
>> "Transmission of IPv6 Packets over Ethernet Networks"      RFC
>> 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" RFC
>> 4944 "Transmission of IPv6 Packets over ITU-T G.9959 Networks"  RFC
>> 7428
>>
>>>> Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit : [...]
>>>>>
>>>>> 1. Informational RFC "ITS General Problem Area" covering: -
>>>>> What is ITS? - Explain V2V, V2I, and related terms - Why is
>>>>> IPv6 needed? - Explain why some traffic will not use IPv6 -
>>>>> Explain why other traffic will use IPv6 - Use-cases,
>>>>> illustrating the expected areas for initial focus -
>>>>> Informative references, relationship with other SDOs
>>>>>
>>>> This particular mentioning of "IPv6 over DSRC" has raised a
>>>> number of questions.
>>>>
>>>>> statement - Security considerations - Privacy considerations
>>>> _______________________________________________ its mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>
>>
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 26 May 2016 08:56:06 +0200

Dick, thanks for the reply.

Le 26/05/2016 à 08:44, Dick Roy a écrit :
> [mailto:[email-masked]] Sent: Wednesday, May 25, 2016
> 1:51 AM To: [email-masked]; [email-masked] Subject: Re: [its]
> latest charter text - title of items "IPv6 over 802.11p"
>
>> Any mention of messages and/or message types that could or should
>> or might or can't or whatever be sent using this "new IP
>> functionality" is out of scope.  IPv6 connectivity in highly
>> transient environments is the goal. Just keep it simple!
>
>> Saying you are going to send BSMs using IPv6 is going to
>> needlessly ruffle some big feathers!
>
> later, if proven necessary. [RR>] Whether or not it happens has NO
> bearing on the work this group should be considering.  It's a local
> broadcast, and does not need IPv6 at all.

Well, let us save this discussion for later.  There are many aspects
that need to be mentioned about advantages and inconvenients of a
network layer-less local broadcast.

> (BSM stands for "Basic Safety Message" and is defined by the Society
> of Automotive Engineers in the standard J2735_201603 "DSRC Message
> Set Dictionary", paying access; a BSM is however dissected by the
> freely available open source wireshark tool, and some packet captures
> are freely available open source at
> http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files
>
>
>
> [RR>] NB: The BSM is an ASN.1 data object. It's ABSTRACT.

Ok.

> It can be and is encoded in a variety of ways.  When encoded
> according to what a few people believe to be the correct encoding for
> US V2V deployments,

I hope there is BSM interoperability at least within US V2V deployments. 
  That should me more than just what a few people believe.

  then yes, a wireshark tool programmed to decode
> that particular encoding can dissect the contents.  So when the rules
> are finally set, if the encoding changes, so muist the wireshark
> tools if they want to be able to "dissect the BSM".

You mean the rules are undergoing change?

Alex

>> I discussed with people involved in GCDC, yogoko, and open source
>> of ETSI ITS CAM (github.com/alexvoronov/geonetworking), IEEE
>> 802.11p (github.com/CTU-IIG/802.11p-linux) and SAE BSM at
>> itsforge.net.
>>
>> In this title the "DSRC" term was a source of confusion: - it
>> means link-layer in some context but app-layer in other, - the
>> authoritative source of definition of 'DSRC' seems to be SAE, but
>> not sure whether it's rather IEEE, or other - not sure where to
>> look for it.
>>
>> On the contrary, '802.11p' is clearly defined as 'Outside the
>> Context of a BSSID of 802.11' by IEEE.  It always means link-layer
>> (there are no 802.11p applications - an application runs equally
>> well on 802.11b as on 802.11p).
>>
>>> 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks"
>>> RFC 4944 "Transmission of IPv6 Packets over ITU-T G.9959
>>> Networks"  RFC 7428
>>>
>>>>>> - What is ITS? - Explain V2V, V2I, and related terms - Why
>>>>>> is IPv6 needed? - Explain why some traffic will not use
>>>>>> IPv6 - Explain why other traffic will use IPv6 -
>>>>>> Use-cases, illustrating the expected areas for initial
>>>>>> focus - Informative references, relationship with other
>>>>>> SDOs
>>>>>>
>>>>>> 3. Informational RFC "Problem Statement" covering: -
>>>>>> Problem statement - Security considerations - Privacy
>>>>>> considerations

---

From: "Dick Roy" <[email-masked]>
Date: Thu, 26 May 2016 10:13:35 -0700

At present, in the U.S., there are NO rules.  NHTSA has yet to “make the
rules”.  If all goes according to the current plan in the minds of a few
individuals, then the relevant SAE and IEEE standards that have been
produced over the last 15 years will form the basis of that ruling.  Things
could change, including the frequency allocations, between now and then.
Stay tuned …

As for the BSM, it has little to no value outside a VERY LIMITED geographic
and temporal region.  No one more than a few hundred meters from a given
vehicle cares where it is, and even if it knew, within a few tenths of a
second, it would be yesterday’s news!  There is NO thought that broadcasting
BSMs through networks makes any sense at all.  That DOES NOT mean that
logging a few for transmission to a TMC to be used for traffic management
and efficiency applications won’t happen.  But that is NOT an IP broadcast.
There is simply NO WAY all (or even a miniscule fraction thereof) BSMs
transmitted are going to end up traversing IP networks.  The network(s)
can’t handle all the USELESS information!

RR

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2016 11:56 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p"

Le 26/05/2016 à 08:44, Dick Roy a écrit :

Ok.

Alex

>> At this time I believe the title of the work item number 2 should

>> be:

>> I will modify the title in the work item charter proposal

>> accordingly.

>>> I am tempted to believe that in this context "DSRC" means

>>> "802.11 OCB".

---

From: John Kenney <[email-masked]>
Date: Thu, 26 May 2016 11:39:57 -0700

I don't disagree with Dick's second paragraph, but I wouldn't want there to
be confusion about the existence of "rules." The auto industry has worked
hard to develop and publish key standards related to the BSM (SAE J2735,
SAE J2945/1), so there will be interoperability.  Deployments are moving
ahead in the US based on those standards.

Best Regards,
John

On Thu, May 26, 2016 at 10:13 AM, Dick Roy <[email-masked]> wrote:

> As for the BSM, it has little to no value outside a VERY LIMITED
> geographic and temporal region.  No one more than a few hundred meters from
> a given vehicle cares where it is, and even if it knew, within a few tenths
> of a second, it would be yesterday’s news!  There is NO thought that
> broadcasting BSMs through networks makes any sense at all.  That DOES NOT
> mean that logging a few for transmission to a TMC to be used for traffic
> management and efficiency applications won’t happen.  But that is NOT an IP
> broadcast.  There is simply NO WAY all (or even a miniscule fraction
> thereof) BSMs transmitted are going to end up traversing IP networks.  The
> network(s) can’t handle all the USELESS information!
>
>
>
> RR
>
>
>

-- 
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 26 May 2016 22:46:50 +0200

Dick,

Once again - the relevance of putting a BSM directly on the link-layer, 
or on a network layer first, is debatable.  There are many pro and con 
arguments for each; you list only the cons for putting BSM on network 
layer.  Let's have that discussion later.

For now, I guess you will agree we pursue with putting _something_ on 
top of IPv6 on top of 802.11p, right?

Alex

Le 26/05/2016 à 19:13, Dick Roy a écrit :
> produced over the last 15 years will form the basis of that ruling.
> Things could change, including the frequency allocations, between now
> and then.  Stay tuned …
>
>
>
> geographic and temporal region.  No one more than a few hundred meters
> from a given vehicle cares where it is, and even if it knew, within a
> few tenths of a second, it would be yesterday’s news!  There is NO
> thought that broadcasting BSMs through networks makes any sense at all.
> That DOES NOT mean that logging a few for transmission to a TMC to be
> used for traffic management and efficiency applications won’t happen.
> But that is NOT an IP broadcast.  There is simply NO WAY all (or even a
> miniscule fraction thereof) BSMs transmitted are going to end up
> traversing IP networks.  The network(s) can’t handle all the USELESS
> information!
>
>
>
> RR
>
>
>
> */ /*

---

From: "Dick Roy" <[email-masked]>
Date: Thu, 26 May 2016 17:45:51 -0700

While we could debate the word “deployments”, nothing John points out is
essentially incorrect (double negatives are beautiful in such
circumstances:^))). The problem is there is a very strong lobby that may
result in rules being put in place that were not what is currently
“anticipated”.  None of this is particularly relevant to the issue at hand,
however.  

The real point is that basing a use case on a particular technology (5.9GHz
802.11p) when it is not necessary to do so is just not a good idea.  To
describe and justify the IETF’s effort to “upgrade IP” to handle rapidly
varying network topologies and unreliable links does NOT require mention of
any particular MAC&PHY.  There are more than enough to go around, and the
resulting IPv6 functionality will not depend on what frequency band is being
used at the PHY!  Add to this the fact that the 5.9GHz band is the most
tenuous at present of all the other possible choices, focusing on it is
probably the worst choice you could make.  The characteristics of the lower
layers (1 and 2) can be described sufficiently well without naming names, so
don’t name names.

RR    

  _____  

From: John Kenney [mailto:[email-masked]] 
Sent: Thursday, May 26, 2016 11:40 AM
To: Dick Roy
Cc: Alexandre Petrescu; Richard Roy; [email-masked]
Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p"

I don't disagree with Dick's second paragraph, but I wouldn't want there to
be confusion about the existence of "rules." The auto industry has worked
hard to develop and publish key standards related to the BSM (SAE J2735, SAE
J2945/1), so there will be interoperability.  Deployments are moving ahead
in the US based on those standards.

Best Regards,

John

RR

-----Original Message-----

Le 26/05/2016 à 08:44, Dick Roy a écrit :

Ok.

Alex

 

-- 

John Kenney

465 Bernardo Avenue

Mountain View, CA 94043

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Fri, 27 May 2016 06:10:47 +0200

Dick is right. Mentioning a specific access technology would be a "one 
way street with dead end".

Presenting now new "rules" and new "appraoches" competing with what SAE 
/ IEEE has developed can only aim on stopping the NHTSA project - I 
wonder whether IETF is interested in this?

Hans-Joachim

Am 27.05.2016 um 02:45 schrieb Dick Roy:
>
> While we could debate the word “deployments”, nothing John points out 
> is essentially incorrect (double negatives are beautiful in such 
> circumstances:^))). The problem is there is a very strong lobby that 
> may result in rules being put in place that were not what is currently 
> “anticipated”.  None of this is particularly relevant to the issue at 
> hand, however.
>
> The real point is that basing a use case on a particular technology 
> (5.9GHz 802.11p) when it is not necessary to do so is just not a good 
> idea.  To describe and justify the IETF’s effort to “upgrade IP” to 
> handle rapidly varying network topologies and unreliable links does 
> NOT require mention of any particular MAC&PHY.  There are more than 
> enough to go around, and the resulting IPv6 functionality will not 
> depend on what frequency band is being used at the PHY! Add to this 
> the fact that the 5.9GHz band is the most tenuous at present of all 
> the other possible choices, focusing on it is probably the worst 
> choice you could make.  The characteristics of the lower layers (1 and 
> 2) can be described sufficiently well without naming names, so don’t 
> name names.
>
> RR
>
> ------------------------------------------------------------------------
>
> *From:*John Kenney [mailto:[email-masked]]
> *Sent:* Thursday, May 26, 2016 11:40 AM
> *To:* Dick Roy
> *Cc:* Alexandre Petrescu; Richard Roy; [email-masked]
> *Subject:* Re: [its] latest charter text - title of items "IPv6 over 
> 802.11p"
>
> I don't disagree with Dick's second paragraph, but I wouldn't want 
> there to be confusion about the existence of "rules." The auto 
> industry has worked hard to develop and publish key standards related 
> to the BSM (SAE J2735, SAE J2945/1), so there will be 
> interoperability. Deployments are moving ahead in the US based on 
> those standards.
>
> Best Regards,
>
> John
>
> On Thu, May 26, 2016 at 10:13 AM, Dick Roy <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> At present, in the U.S., there are NO rules. NHTSA has yet to “make 
> the rules”. If all goes according to the current plan in the minds of 
> a few individuals, then the relevant SAE and IEEE standards that have 
> been produced over the last 15 years will form the basis of that 
> ruling.  Things could change, including the frequency allocations, 
> between now and then.  Stay tuned …
>
> thought that broadcasting BSMs through networks makes any sense at 
> all. That DOES NOT mean that logging a few for transmission to a TMC 
> to be used for traffic management and efficiency applications won’t 
> happen.  But that is NOT an IP broadcast.  There is simply NO WAY all 
> (or even a miniscule fraction thereof) BSMs transmitted are going to 
> end up traversing IP networks. The network(s) can’t handle all the 
> USELESS information!
>
> RR
>
> From: Alexandre Petrescu [mailto:[email-masked] 
> <mailto:[email-masked]>]
>
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> > [mailto:[email-masked] 
> <mailto:[email-masked]>] Sent: Wednesday, May 25, 2016
>
> > 1:51 AM To: [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]> Subject: Re: [its]
>
> *//*
> >> [mailto:[email-masked] 
> <mailto:[email-masked]>] Sent: Tuesday, May 24, 2016
>
> >> 5:41 AM To: [email-masked] <mailto:[email-masked]> Subject: Re: [its] 
> latest charter text -
>
> >> of ETSI ITS CAM (github.com/alexvoronov/geonetworking 
> <http://github.com/alexvoronov/geonetworking>), IEEE
>
> >> 802.11p (github.com/CTU-IIG/802.11p-linux 
> <http://github.com/CTU-IIG/802.11p-linux>) and SAE BSM at
>
> >> itsforge.net <http://itsforge.net>.
>
> >>
>
> >>>>> list [email-masked] <mailto:[email-masked]> 

-- 
Dr. Hans-Joachim Fischer
Managing Director

-------------------------------------------------------------------------------

                               ESF News edition 2016/1
              http://fischer-tech.eu/Feeds/News/ESF-News-2016-01.pdf

-------------------------------------------------------------------------------
+ + + Instaurare omnia in Christo + + +
-------------------------------------------------------------------------------
The information contained in this message is confidential and may be legally
privileged. This email is intended for the addressee(s). Addressees may be
individual persons or members of mailing list.
If you are not an addressee, you are hereby notified that any use,
dissemination, or reproduction of this email and its optional attachements is
strictly prohibited and may be unlawful. If you are not an addressee, please
contact the sender by return e-mail and destroy all copies of the original
message.
-------------------------------------------------------------------------------
ESF GmbH
Fichtenweg 9
89143 Blaubeuren
+49 (7344) 175340 (Direct line)
+49 (7344) 919188 (Central office)
+49 (7344) 919123 (Fax)
http://fischer-tech.eu : Main web of ESF GmbH
http://its-standards.eu : News on cooperative ITS standardization
http://its-testing.org : International consultancy for cooperative ITS
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
ESF online-news:    http://fischer-tech.eu/Feeds/esf.rss
C-ITS online news:  http://its-standards.info/Feeds/cits.rss
ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss
-------------------------------------------------------------------------------

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 27 May 2016 09:43:23 +0200

Hans-Joachim,

Thanks for the message.

Generally speaking, the politics I see at IETF is at Layer8, well beyond 
"rough consensus and running code".

NHTSA: I still have to see somebody from NHTSA here or meet at IETF, or 
in the virtual meeting...

For the mentioning of access technology: there are clearly two 
directions of thought:
1. the IPv6-over-foo documents help in keeping the IP layer dire
    (unmodified, see the well-known IETF/Steve Deering hourglass model);
    in that sense yes, IPv6-over-80211p will help keep IPv6 unmodified,
    and thus not lead to that dead end you mention.
2. an "upgraded" IPv6 layer dedicated to highly dynamic link layers;
    this is something that an IPv6-over-dynamiclinklayer document could
    do.  One could free one's imagination in so "upgrading" the IPv6
    layer (add header compression, new identifiers, congestion control,
    etc.) IMHO this leads to a dead end in that there can not be enough
    people agreeing to "upgrade IP", nor about the features to include.
    It is also a domain typically of MANET WG, not here.

In the charter text I propose an aggressive schedule for this "IPv6 over 
foo" WG item: delivery to the WG by December 2016.  This assumes until 
then there should be multiple personal I-Ds published...

If we follow that timeline, there is obviously no time to propose 
anything along the lines of 'upgrading' an IP layer.

I can not not add, again for information, that a typical "IPv6-over-foo" 
document at IETF is like RFC 2464 "IPv6 over Ethernet".  There are many 
such IPv6-over-foo RFCs; these RFCs are very much mirroring each other.

We can discuss separately about what is an "IPv6 over foo" document.

Alex

Le 27/05/2016 à 06:10, Dr. Hans-Joachim Fischer a écrit :
>> On Thu, May 26, 2016 at 10:13 AM, Dick Roy
>> <<mailto:[email-masked]>[email-masked]> wrote:
>>
>> From: Alexandre Petrescu
>> [mailto:<mailto:[email-masked]>[email-masked]]
>>
>>
>> > [mailto:<mailto:[email-masked]>[email-masked]] Sent: Wednesday, May 25, 2016
>>
>> > 1:51 AM To: <mailto:[email-masked]>[email-masked];
>> > <http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files>http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files
>>
>> >
>>
>> >
>>
>> >
>>
>> >> [mailto:<mailto:[email-masked]>[email-masked]] Sent: Tuesday, May 24, 2016
>>
>> >> 5:41 AM To: <mailto:[email-masked]>[email-masked] Subject: Re: [its]
>> latest charter text -
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 27 May 2016 13:28:58 +0200

Le 27/05/2016 à 02:45, Dick Roy a écrit :
[...]

> To describe and justify the IETF’s effort to “upgrade IP” to handle
> rapidly varying network topologies and unreliable links does NOT
> require mention of any particular MAC&PHY.

To clarify - I wonder where this perspective about upgrading IP can come 
from?

I never said and I never heard such discussion here.

Alex

> There are more than enough to go around, and the resulting IPv6
> functionality will not depend on what frequency band is being used at
> the PHY!  Add to this the fact that the 5.9GHz band is the most
> tenuous at present of all the other possible choices, focusing on it
> is probably the worst choice you could make. The characteristics of
> the lower layers (1 and 2) can be described sufficiently well without
> naming names, so don’t name names.
>
>
>
> RR
>
>
>
>  *From:*John Kenney [mailto:[email-masked]] *Sent:*
> Thursday, May 26, 2016 11:40 AM *To:* Dick Roy *Cc:* Alexandre
> Petrescu; Richard Roy; [email-masked] *Subject:* Re: [its] latest
> charter text - title of items "IPv6 over 802.11p"
>
>
>
> the rules”.  If all goes according to the current plan in the minds
> of a few individuals, then the relevant SAE and IEEE standards that
> have been produced over the last 15 years will form the basis of that
> geographic and temporal region.  No one more than a few hundred
> meters from a given vehicle cares where it is, and even if it knew,
> within a few tenths of a second, it would be yesterday’s news!  There
> is NO thought that broadcasting BSMs through networks makes any sense
> at all. That DOES NOT mean that logging a few for transmission to a
> TMC to be used for traffic management and efficiency applications
> won’t happen. But that is NOT an IP broadcast.  There is simply NO
> WAY all (or even a miniscule fraction thereof) BSMs transmitted are
> going to end up traversing IP networks.  The network(s) can’t handle
> all the USELESS information!
>
>
>
> RR
>
>
>
> Sent: Wednesday, May 25, 2016 11:56 PM To: [email-masked]
> <mailto:[email-masked]> Cc: [email-masked] <mailto:[email-masked]>
> Sent: Wednesday, May 25, 2016
>
> <mailto:[email-masked]> Subject: Re: [its]
>
> Sent: Tuesday, May 24, 2016
>
>>>> list