Subject: Re: [its] WG Review: IP Wireless Access in Vehicular Environments (ipwave)

From: ernstty <[email-masked]>
Date: Sat, 1 Oct 2016 18:43:14 +0800

Dear all,

I’m going to give you my personal feeling on this charter, and report with my ISO - IETF liaison hat about the ISO TC204 view by October 7th as ISO TC204 plenary is held this week (I’m appointed as liaison officer by ISO, while Alexandru Petrescu is appointed by IETF).

Here are my comments:

1 — I don’t very much like the name as it is too much implicating that the work done at the IETF is related to IEEE P1609 (WAVE architecture). As you might certainly now, there are other ITS-related communication stacks the compete / complement / interoperate with WAVE, and particularly the ITS station reference architecture work being developed by ISO TC204 (ISO 21217 and ISO 21210 when it comes to IPv6). 

2 — the charter explicit mentions that there are not formal liaison established with other SDOs, this is wrong, because there is one established with ISO TC204 just for this matters (IETF work related to ITS). This wording in the charter MUST be change and liaison with ISO TC204 should be explicitly mentioned.

3 — while I appreciate that the charter is narrowed, I don’t think it should be narrowed exclusively to 802.11p

4 — if this choice is maintained, it cannot be done without formal liaison with the SDOs established in this topic. 

5 — When it comes to IPv6 for ITS, over 802.11p or other access technologies, the work being done by ISO TC204 should be acknowledged, and IETF & ISO should discuss together. Please recall that this was the reason behind establishing the liaison. 

Again, as far as today these comments are only mine as I didn’t consult with other ISO TC204 delegates yet, but ISO TC204 will discuss this topic in the following days. 

Regards,
Thierry Ernst
ISO TC204 - IETF liaison, representing ISO

> Le 1 oct. 2016 à 10:27, Suresh Krishnan <[email-masked]> a écrit :
> 
> Hi all,
>    If you have any questions or comments about this charter that was 
> approved after IESG internal review, please feel free to send a note to the 
> IESG list before October 10. We will be discussing any comments that are 
> received on the October 13th telechat and try to get the WG formed right after.
> 
> Thanks
> Suresh
> 
> On 09/30/2016 02:07 PM, The IESG wrote:
>> A new IETF WG has been proposed in the Internet Area. The IESG has not
>> made any determination yet. The following draft charter was submitted,
>> and is provided for informational purposes only. Please send your
>> comments to the IESG mailing list ([email-masked]) by 2016-10-10.
>> 
>> IP Wireless Access in Vehicular Environments (ipwave)
>> -----------------------------------------------------------------------
>> Current status: Proposed WG
>> 
>> Chairs:
>>  TBD
>> 
>> Assigned Area Director:
>>  Suresh Krishnan <[email-masked]>
>> 
>> Internet Area Directors:
>>  Terry Manderson <[email-masked]>
>>  Suresh Krishnan <[email-masked]>
>> 
>> Mailing list:
>>  Address: [email-masked]
>>  To subscribe: https://www.ietf.org/mailman/listinfo/its
>>  Archive:
>> https://www.ietf.org/mail-archive/web/its/current/maillist.html
>> 
>> Charter: https://datatracker.ietf.org/doc/charter-ietf-ipwave/
>> 
>> 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 an
>> occupant's cellular smartphone: mirrorlink, carplay, android
>> auto. Vehicle-to-Infrastructure (V2I, not to be mistaken with
>> V2Internet) Communications are used for wireless exchange of critical
>> safety and operational data between vehicles and roadway
>> infrastructure, intended primarily to avoid motor vehicle
>> crashes. Similarly, Vehicle-to-Vehicle Communications (V2V) are used
>> for short-range communications between vehicles to exchange vehicle
>> information such as vehicle speed, headng and braking status. However,
>> V2V and V2I communications are still in the process of being
>> developed.
>> 
>> Some forms of vehicle and infrastructure communications will use IP
>> and others will not.  Thus, multiple applications need to share one
>> data link, including non-IP-based protocols sharing the data link with
>> IP-based protocols. This group will work on V2V and V2I use-cases
>> where IP is well-suited as a networking technology and will develop an
>> IPv6 based solution to establish direct and secure connectivity
>> between a vehicle and other vehicles or stationary systems.
>> 
>> V2V and V2I communications may involve various kinds of link layers:
>> 802.11-OCB (Outside the Context of a Basic Service Set, also called
>> 802.11p), 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
>> Dedicated short-range communications (DSRC). Several of these
>> link-layers already provide support for IPv6. However, IPv6 on
>> 802.11-OCB is yet to be defined.
>> 
>> This group's primary deliverable (and the only Standards track item)
>> will be a document that will specify the mechanisms for transmission
>> of IPv6 datagrams over IEEE 802.11p OCB mode. The group will work on
>> an informational document that will explain the state of the art in
>> the field and describe the use cases that will use IPv6 in order to
>> focus the work of the group. The group will also work on informational
>> document that describes the problem statement and the associated
>> security and privacy considerations. The working group will decide at
>> a future point whether these informational documents need to be
>> published separately as RFCs or if they maybe combined.
>> 
>> The group will try to reuse relevant technologies for Internet of
>> Things (IoT) and infrastructure mobility that have been developed in
>> other IETF and IRTF groups. The WG will pay particular attention to
>> the privacy characteristics of solution it develops in order to
>> minimize unwanted tracking opportunities. The group will closely
>> coordinate with IEEE 802.11. The work produced by this group may be of
>> interest to other SDOs such as ISO/TC204, ETSI TC ITS, 3GPP, and
>> NHTSA. No formal co-ordination is anticipated with these groups at
>> this point but work done in these SDOs may end up becoming relevant to
>> the WG deliverables in the future.
>> 
>> Milestones:
>>  Oct 2016 - Draft for "IPv6 over 802.11-OCB" adopted by WG
>>  Dec 2016 - Draft for "ITS General Problem Area" adopted by WG
>>  Mar 2017 - Draft for "Problem Statement" adopted by WG
>>  May 2017 - Submit "IPv6 over 802.11-OCB" to IESG
>>  Oct 2017 - Submit "ITS General Problem Area" to IESG
>>  May 2018 - Submit "Problem Statement" to IESG
>> 
>> 
>> 
> 
> 
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 1 Oct 2016 18:56:21 +0000

Hi AB,

On 10/01/2016 02:18 AM, Abdussalam Baryun wrote:
> Hi Suresh,
>
> is there possibility that the wg can meet in ietf97?

That is certainly the goal.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 1 Oct 2016 19:12:53 +0000

Hi AB,

On 10/01/2016 02:22 AM, Abdussalam Baryun wrote:
> Even if iesg and ietf calls the ITS as ipwave, still others around the world
> may still name it ITS. Therefore, we need to make the definition clear that
> they are the same so others know what we are talking about otherwise we may
> not be able to communicate with others,

There was a lot of discussion about the its name being too broad and that is 
why the proposed name was changed.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 2 Oct 2016 02:51:59 +0000

(Adding IESG to the recipient list as they need to be in the loop)

Hi Thierry,
   Good to hear from you. Thanks for your comments. Please find my responses 
inline.

> 1 — I don’t very much like the name as it is too much implicating that the work done at the IETF is related to IEEE P1609 (WAVE architecture). As you might certainly now, there are other ITS-relate…

Please see my response to Question 3.

> 2 — the charter explicit mentions that there are not formal liaison established with other SDOs, this is wrong, because there is one established with ISO TC204 just for this matters (IETF work rela…

Actually, it does not state that there is no formal liaison established. It 
says that no formal co-ordination is expected at this point. If you can write 
down a sentence or two about what co-ordination is needed for the 
deliverables in the current charter, I can add it into the charter before it 
gets in front of the IESG again. That should not be an issue.

> 3 — while I appreciate that the charter is narrowed, I don’t think it should be narrowed exclusively to 802.11p

What else do you think should be added? Are you talking about other link-layers?

> 4 — if this choice is maintained, it cannot be done without formal liaison with the SDOs established in this topic.

This is an IETF activity. Everyone is free to provide comments on the charter 
during the external review period with or without a formal liaison. Do you 
see an issue in this regard?

> 5 — When it comes to IPv6 for ITS, over 802.11p or other access technologies, the work being done by ISO TC204 should be acknowledged, and IETF & ISO should discuss together. Please recall that thi…

 From what I understand about the liaison, it was purely informational 
exchange between the bodies. The LS pointed to your slides from the first its 
BoF which mentioned the following

* From ISO to IETF:

- inform about ongoing work developed within ISO TC204

* From IETF to ISO

- Get feedback and advices on the use of IETF protocols in ISO standards 
(particularly IPv6, Security)

I don't see the charter precluding either of these exchanges. If you want 
something explicit to be added to the charter, can you please provide that in 
the text I requested for item 2 above.

Thanks
Suresh

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 2 Oct 2016 13:59:00 +0200

Hi Russ,

The charter was narrowed down to focus on IPv6-over-80211-OCB.  In the 
process the 1-hop moving network to moving network communication parts 
seem to have been delayed.

The current Problem Statement work (draft-petrescu-its-problem-03.txt, 
draft-jeong-its-v2i-problem-statement-00) is a little bit geared to that 
mnet-to-mnet direction, rather than focus specifically on 
IPv6-over-80211-OCB.

The recent DSRC capacity analysis is more focused on an 
IPv6-over-80211-OCB work.
https://mailarchive.ietf.org/arch/msg/its/GTDvTFTpCS-zAqVonDXkQND5w-8

As such I propose to join these three texts into one PS draft, with 
necessary reorderind and adaptation.

Do you disagree?

Alex

Le 30/09/2016 à 21:21, Russ Housley a écrit :
> The IESG is proposing to move forward with a scope of work that this
> narrower than the draft charter proposed by this group.  If this is a
> concern to you, please send comments to the IESG mailing list
> ([email-masked]) by 2016-10-10.  Similarly, if you support this more
> narrow charter, please send comments to the IESG mailing list
> ([email-masked]) by 2016-10-10.
>
> Russ
>
>
> On Sep 30, 2016, at 2:07 PM, The IESG <[email-masked]>
> wrote:
>
>> A new IETF WG has been proposed in the Internet Area. The IESG has
>> not made any determination yet. The following draft charter was
>> submitted, and is provided for informational purposes only. Please
>> send your comments to the IESG mailing list ([email-masked]) by
>> 2016-10-10.
>>
>>
>> Chairs: TBD
>>
>> Assigned Area Director: Suresh Krishnan
>> <[email-masked]>
>>
>> Internet Area Directors: Terry Manderson
>> <[email-masked]> Suresh Krishnan
>> <[email-masked]>
>>
>> Mailing list: Address: [email-masked] To subscribe:
>> https://www.ietf.org/mailman/listinfo/its Archive:
>> 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.
>>
>> occupant's cellular smartphone: mirrorlink, carplay, android auto.
>> Vehicle-to-Infrastructure (V2I, not to be mistaken with V2Internet)
>> Communications are used for wireless exchange of critical safety
>> and operational data between vehicles and roadway infrastructure,
>> intended primarily to avoid motor vehicle crashes. Similarly,
>> Vehicle-to-Vehicle Communications (V2V) are used for short-range
>> communications between vehicles to exchange vehicle information
>> such as vehicle speed, headng and braking status. However, V2V and
>> V2I communications are still in the process of being developed.
>>
>> Some forms of vehicle and infrastructure communications will use
>> IP and others will not.  Thus, multiple applications need to share
>> one data link, including non-IP-based protocols sharing the data
>> link with IP-based protocols. This group will work on V2V and V2I
>> use-cases where IP is well-suited as a networking technology and
>> will develop an IPv6 based solution to establish direct and secure
>> connectivity between a vehicle and other vehicles or stationary
>> systems.
>>
>> V2V and V2I communications may involve various kinds of link
>> layers: 802.11-OCB (Outside the Context of a Basic Service Set,
>> also called 802.11p), 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 Dedicated short-range communications (DSRC). Several of these
>> This group's primary deliverable (and the only Standards track
>> item) will be a document that will specify the mechanisms for
>> transmission of IPv6 datagrams over IEEE 802.11p OCB mode. The
>> group will work on an informational document that will explain the
>> state of the art in the field and describe the use cases that will
>> use IPv6 in order to focus the work of the group. The group will
>> also work on informational document that describes the problem
>> statement and the associated security and privacy considerations.
>> The working group will decide at a future point whether these
>> informational documents need to be published separately as RFCs or
>> if they maybe combined.
>>
>> Things (IoT) and infrastructure mobility that have been developed
>> in other IETF and IRTF groups. The WG will pay particular attention
>> to the privacy characteristics of solution it develops in order to
>> coordinate with IEEE 802.11. The work produced by this group may be
>> of interest to other SDOs such as ISO/TC204, ETSI TC ITS, 3GPP,
>> and NHTSA. No formal co-ordination is anticipated with these groups
>> at this point but work done in these SDOs may end up becoming
>> relevant to the WG deliverables in the future.
>>
>> Milestones: Oct 2016 - Draft for "IPv6 over 802.11-OCB" adopted by
>> WG Dec 2016 - Draft for "ITS General Problem Area" adopted by WG
>> Mar 2017 - Draft for "Problem Statement" adopted by WG May 2017 -
>> Submit "IPv6 over 802.11-OCB" to IESG Oct 2017 - Submit "ITS
>> General Problem Area" to IESG May 2018 - Submit "Problem Statement"
>> to IESG
>>
>>
>> _______________________________________________ its mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 2 Oct 2016 23:05:12 +0200

Hi Suresh,

As I mentioned before some can call ITS and we may call it IPWAVE, usually
I preferred ITS, we should not get into specific names but better general,
however, we need to define it in an RFC so other SDOs know what we mean
while coordination. There is no doubt that this WG needs coordination with
many SDOs. Furthermore, I think we need to mention in our charter the
liaison with ISO, or we may mention our appointed manager (Mr. Alexandre
Petrescu) for the liaison and coordination. I thank Joel Jaeggli that
refered me to RFC4052 in IETF list while discussing liaison process. That
process is important that we use while our WG discussions/works.

We need to consider all SDOs because we may have participants from
different ones all into IETF. IMHO, for my easy follow up for this WG I
need to know my WG chair and AD, but Also I need to know if there are any
liaison used by the WG, also we need to know the related appointed
IETF liaison managers mentioned in the chartered. IMHO, the key managers
mentioned in chartered for any WG will need to include the liaison managers
with the AD and Chairs. Yes there is a list of IETF liaison managers at
https://www.ietf.org/liaison/managers.html , but a WG may not use only one
or two which they may to need to know which ones are current coordinating
such work. My reply comments below,

Best Regards
AB

On Sun, Oct 2, 2016 at 4:51 AM, Suresh Krishnan <
[email-masked]> wrote:

> > I’m going to give you my personal feeling on this charter, and report
> with my ISO - IETF liaison hat about the ISO TC204 view by October 7th as
> ISO TC204 plenary is held this week (I’m appointed as liaison officer by
> ISO, while Alexandru Petrescu is appointed by IETF).
> >
> > Here are my comments:
> >
> > 1 — I don’t very much like the name as it is too much implicating that
> the work done at the IETF is related to IEEE P1609 (WAVE architecture). As
> you might certainly now, there are other ITS-related communication stacks
> the compete / complement / interoperate with WAVE, and particularly the ITS
> station reference architecture work being developed by ISO TC204 (ISO 21217
> and ISO 21210 when it comes to IPv6).
>

I agree with Thierry,

>
> >
> > 2 — the charter explicit mentions that there are not formal liaison
> established with other SDOs, this is wrong, because there is one
> established with ISO TC204 just for this matters (IETF work related to
> ITS). This wording in the charter MUST be change and liaison with ISO TC204
> should be explicitly mentioned.
>
> > 3 — while I appreciate that the charter is narrowed, I don’t think it
> should be narrowed exclusively to 802.11p
>

Yes iso technologies under IPv6, we may look also if there are other
request from other SDOs,

>
> >
> > 4 — if this choice is maintained, it cannot be done without formal
> liaison with the SDOs established in this topic.
>
> > 5 — When it comes to IPv6 for ITS, over 802.11p or other access
> technologies, the work being done by ISO TC204 should be acknowledged, and
> IETF & ISO should discuss together. Please recall that this was the reason
> behind establishing the liaison.
>

yes we should not stick to  our IPWAVE or our ITS to one or only two
technologies that is poor work, we need adaptability to many technologies
or whom interested to participate with us to work productively and with
diversity. We should not only follow one country/company technology even if
our majority participants are from one country/company.

> (particularly IPv6, Security)

so information is power, all our RFC are based on information, IMHO there
is a liaison with ISO. However, the ISO webpage does not mention that there
is a liaison with IETF related to ITS, so they mention many other SDOs but
not IETF,

> the text I requested for item 2 above.

we need the liaison managers mentioned which we will use in our work, we
can do per work/draft.

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 2 Oct 2016 23:34:41 +0200

> gets in front of the IESG again. That should not be an issue.

I suggest to delete from chartered:

 No formal co-ordination is anticipated with these groups
at this point but work done in these SDOs may end up becoming
relevant to the WG deliverables in the future.

I suggest to replace with below to give opportunity to RFC4052:

 Formal co-ordination can be established by IETF participants through IETF
liaison manager with these groups as mentioned in RFC4052, also work done
in these SDOs may end up becoming relevant to the WG deliverables in the
future.

Regards

AB

---

From: Russ Housley <[email-masked]>
Date: Mon, 3 Oct 2016 12:48:48 -0400

I think the IESG is telling us to do the IPv6-over-80211-OCB work as our primary task.

We should understand (from those drafts) what is special about this link layer, and summarize those unique requirements at the from of the IPv6-over-80211-OCB document, but I do not think that the use cases should be folded in.

Russ

On Oct 2, 2016, at 7:59 AM, Alexandre Petrescu <[email-masked]> wrote:

> Hi Russ,
> 
> The charter was narrowed down to focus on IPv6-over-80211-OCB.  In the process the 1-hop moving network to moving network communication parts seem to have been delayed.
> 
> The current Problem Statement work (draft-petrescu-its-problem-03.txt, draft-jeong-its-v2i-problem-statement-00) is a little bit geared to that mnet-to-mnet direction, rather than focus specifically on IPv6-over-80211-OCB.
> 
> The recent DSRC capacity analysis is more focused on an IPv6-over-80211-OCB work.
> As such I propose to join these three texts into one PS draft, with necessary reorderind and adaptation.
> 
> Do you disagree?
> 
> Alex
> 
>

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 3 Oct 2016 17:10:13 +0000

Hi Dick, (CCed: IESG)
   Thanks a lot for your extensive comments. Please find responses inline.

On 10/02/2016 12:58 AM, Dick Roy wrote:
>> automated driving are */[RR] /*only a few */[RR] /*of the new features expected in automobiles
>
>> to hit the roads in the near future.

OK.

>> V2Internet) communications are used for wireless exchange of critical
>
>> crashes.
> */[RR] This is actually not quite true. V2V is primarily to avoid crashes;
> V2I is used for many other services/applications.  Secondly, I can assure you
> that what you refer to as V2I communications will in most instances “use the
> internet”, and there really is no difference between V2I and V2Internet. /*
>
> */ /*

This text is from the charter discussed at the BoF in Berlin. Please suggest 
alternate text if you think this is not accurate.

>
>> Similarly, Vehicle-to-Vehicle Communications (V2V) are used
>
>> information such as vehicle speed, heading and braking status. However,
>
> */[RR] This really depends on what you mean by “being developed”.  There are
> companies building and selling products in this space today.  These products
> are being deployed in several large programs currently underway (CV Pilot,
> Smart Cities, Corridor Project, etc.).  /*

Makes sense. Will take out the final sentence.

>> IP-based protocols.
> */[RR] The work of this group is in no way impacted by the fact that there
> may be applications that share a common PHY layer and use different network
> layer protocols.  The sentences above can be removed for clarity and
> conciseness./*

OK.

>
>> This group will work on V2V and V2I use-cases
>
>> where IP is well-suited as a networking technology, and will develop an
>
>> IPv6-based solution to establish direct and secure connectivity
>
> */[RR] /*between hosts (nodes) in networks characterized by dynamically
> changing network topologies(connectivity) such as those in vehicular
> environments.

OK.

> */[RR] The (data) link layer is composed of a logical link control sublayer
> ABOVE a MAC sublayer where 802.11 stops. That is, the SAP at the top of the
> 802.11 stack is a MAC-SAP!/*
>
>> 802.11p), 802.15.4 with 6lowpan, 802.11ad,
>
> */[RR] The references to 802 technologies are all MAC/PHY references, not
> link layer references./*

The link-layer is term is used in the Internet protocols to mean the layer 
below the IP layer and it has been used at least since RFC1122 (1989). Not 
sure what you want to change here. But please provide alternate text to discuss.

>
>> VLC (Visible Light Communications), IrDA, LTE-D, LP-WAN.
>
>> One of the most used link
>
> */[RR] The highlighted text above is misleading and wrong on several counts.
> First and foremost, the statement that IPv6 on 802.11-OCB is yet to be
> defined has no useful meaning. This text should be replaced with:/*

Please see my response below. There was active discussion about various 
alternatives for running IPv6 on 802.11 OCB including from some IEEE 
participants involved in this work.

>
> Current regulations and system specifications in the US and Europe mandate
> the use of the IEEE 802.11 MAC and PHY in the 5.9GHz bands set aside for ITS.
> The current IEEE 802.11 standard mandates that operations in those bands be
> performed outside the context of a BSS (OCB) which eliminates the normal
> 802.11 functions of authentication, association, and synchronization. Note
> that ALL 802.11 operational modes, including OCB operation, support a logical
> link control sublayer that in turn supports all IPv6 networking services.
>
>>
>
>> of IPv6 datagrams over IEEE 802.11p OCB mode.
>
> */[RR] The problem with this statement is that those mechanisms are already
> in place. The IEEE 1609 and 802.11 standards already state how to do this,
> and these mechanisms are already in products on the market and in the field.
> This should not and can not be the primary deliverable. The primary
> deliverable should be a document that specifies how IPv6 can be used in
> networks with rapidly varying topologies, and describes any new functionality
> required at the IP layer [that may result from constraints imposed by
> different classes of access technologies (such as frame size limits)]
> independent of any particular access technology (MAC and PHY) employed. /*

You might have a better understanding of what has been done to run IPv6 on 
802.11 OCB in IEEE or elsewhere but your statement that the mechanisms are 
already in place *does not correspond at all* to the drafts that were 
presented at the its BoF meeting in Berlin. The slides are here

https://www.ietf.org/proceedings/96/slides/slides-96-its-4.pdf

The open issues that were discussed include basic things like

* What is the size of the MTU on 802.11-OCB
* How to communicate the MTU between 802.11-OCB nodes?
* What layer does the fragmentation - IP and/or MAC
* Frame format: Use 802.11 Data or 802.11 QoS Data
* Address mappings (unicast and multicast)
...

In short an IPv6 over foo specification. If you think all this work has been 
done, please post a comment on the list with pointers. I am sure the draft 
authors will greatly appreciate it.

>> The group will work on
>> focus the work of the group. The group will also work on*//*an informational
>
>> coordinate with IEEE 802.11.
>
> */[RR] Why do you think this is necessary? While there is nothing wrong with
> keeping abreast of 802.11 developments (such as TGai), it’s not clear at all
> that it is necessary to accomplish the task at hand. Perhaps you meant
> “closely follow recent developments within the 802.11 WG”?/*
>
>> The work produced by this group is of
>
>> interest to other SDOs such as ISO/TC204, ETSI TC ITS, 3GPP, andITS-related government organizations such as
>
>> NHTSA.
>
> */[RR] NHTSA is not an SDO.  It’s a government administration/*

And the text does not state that it is an SDO. Not sure what you want to change.

>
>> No formal co-ordination is anticipated with these groups at
>
> */[RR] The IETF has established a formal liaison with TC204 and the TC204
> liaison is Thierry Ernst./*

I have asked Thierry to come up with the text for the scope of the liaison 
work. Once I get it, I will add it in.

>
>>
>
>> Milestones:
>
>>   Oct 2016 - Draft for "IPv6*//*in rapidly changing networks" adopted by WG
>
>>   May 2017 - Submit "IPv6 in rapidly changing networks " to IESG
>
> */[RR] Removal of OCB from the title of the effort is very important.  The
> work to be done applies to ANY and ALL MACs and PHYs that are used in rapidly
> varying environments including standard Wi-Fi in all of its modes (11a, 11n,
> 11ac, 11g, 11b, …), LTE-D2D when it arrives, IR (21214) mm-wave (21216), and
> any other access technology that can be integrated into an ITS station!
> That’s the WHOLE POINT of the ITS station concept in the first place!/*

This was not what was discussed at the second its BoF which led to this 
charter and is pretty widely scoped. That really sounds to me more like a 
manet problem statement. If the other WG participants feel the same way as 
you, we can go back to the drawing board to figure it out.

Thanks
Suresh

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Oct 2016 14:23:39 +0200

Hi Russ,

> I think the IESG is telling us to do the IPv6-over-80211-OCB work as

Yes, I agree.

> We should understand (from those drafts) what is special about this
> link layer, and summarize those unique requirements at the from of
> the IPv6-over-80211-OCB document, but I do not think that the use
> cases should be folded in.

I agree.

The use-cases would not be folded in.

So an 80211-OCB Problem Statement draft will describe what is special
about this link layer.

The issue I have is that, prior to charter narrowing, we called "Problem
Statement" two drafts which were not describing much about the link
layer, but were describing a connectivity problem between vehicles, and
between vehicle and infra:
draft-petrescu-its-problem-03.txt
draft-jeong-its-v2i-problem-statement-00

Maybe we can keep these two drafts for a later "Problem Statement", and
write a new "Problem Statement" according to the narrowed charter for
IPv6-over-80211-OCB?

Alex

>> The charter was narrowed down to focus on IPv6-over-80211-OCB.  In
>> the process the 1-hop moving network to moving network
>> communication parts seem to have been delayed.
>>
>> draft-jeong-its-v2i-problem-statement-00) is a little bit geared
>> to that mnet-to-mnet direction, rather than focus specifically on
>> IPv6-over-80211-OCB.
>>
>>> The IESG is proposing to move forward with a scope of work that
>>> this narrower than the draft charter proposed by this group.  If
>>> this is a concern to you, please send comments to the IESG
>>> mailing list ([email-masked]) by 2016-10-10.  Similarly, if you
>>> support this more narrow charter, please send comments to the
>>> IESG mailing list ([email-masked]) by 2016-10-10.
>>>
>>> Russ
>>>
>>>
>>>> A new IETF WG has been proposed in the Internet Area. The IESG
>>>> has not made any determination yet. The following draft
>>>> charter was submitted, and is provided for informational
>>>> purposes only. Please send your comments to the IESG mailing
>>>> list ([email-masked]) by 2016-10-10.
>>>>
>>>>
>>>> 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 an occupant's cellular smartphone: mirrorlink,
>>>> carplay, android auto. Vehicle-to-Infrastructure (V2I, not to
>>>> be mistaken with V2Internet) Communications are used for
>>>> wireless exchange of critical safety and operational data
>>>> between vehicles and roadway infrastructure, intended
>>>> primarily to avoid motor vehicle crashes. Similarly,
>>>> Vehicle-to-Vehicle Communications (V2V) are used for
>>>> short-range communications between vehicles to exchange vehicle
>>>> information such as vehicle speed, headng and braking status.
>>>> However, V2V and V2I communications are still in the process of
>>>> being developed.
>>>>
>>>> Some forms of vehicle and infrastructure communications will
>>>> use IP and others will not.  Thus, multiple applications need
>>>> to share one data link, including non-IP-based protocols
>>>> sharing the data link with IP-based protocols. This group will
>>>> work on V2V and V2I use-cases where IP is well-suited as a
>>>> networking technology and will develop an IPv6 based solution
>>>> to establish direct and secure connectivity between a vehicle
>>>> and other vehicles or stationary systems.
>>>>
>>>> also called 802.11p), 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 Dedicated short-range
>>>> communications (DSRC). Several of these link-layers already
>>>> provide support for IPv6. However, IPv6 on 802.11-OCB is yet to
>>>> be defined.
>>>>
>>>>  group will work on an informational document that will
>>>> explain the state of the art in the field and describe the use
>>>> cases that will use IPv6 in order to focus the work of the
>>>> group. The group will also work on informational document that
>>>> describes the problem statement and the associated security and
>>>> privacy considerations. The working group will decide at a
>>>> future point whether these informational documents need to be
>>>> The group will try to reuse relevant technologies for Internet
>>>> of Things (IoT) and infrastructure mobility that have been
>>>> developed in other IETF and IRTF groups. The WG will pay
>>>> particular attention to the privacy characteristics of
>>>> solution it develops in order to minimize unwanted tracking
>>>> opportunities. The group will closely coordinate with IEEE
>>>> 802.11. The work produced by this group may be of interest to
>>>> other SDOs such as ISO/TC204, ETSI TC ITS, 3GPP, and NHTSA. No
>>>> formal co-ordination is anticipated with these groups at this
>>>> point but work done in these SDOs may end up becoming relevant
>>>> to the WG deliverables in the future.
>>>>
>>>> Milestones: Oct 2016 - Draft for "IPv6 over 802.11-OCB"
>>>> adopted by WG Dec 2016 - Draft for "ITS General Problem Area"
>>>> adopted by WG Mar 2017 - Draft for "Problem Statement" adopted
>>>> by WG May 2017 - Submit "IPv6 over 802.11-OCB" to IESG Oct 2017
>>>> - Submit "ITS General Problem Area" to IESG May 2018 - Submit
>>>> "Problem Statement" to IESG
>>>>
>>>>
>>>> _______________________________________________ its mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Oct 2016 14:45:15 +0200

For what is worth...

Le 03/10/2016 à 19:10, Suresh Krishnan a écrit :
[...]
>> */[RR] The problem with this statement is that those mechanisms
>> are already in place. The IEEE 1609 and 802.11 standards already
>> state how to do this, and these mechanisms are already in products
>> on the market and in the field. This should not and can not be the
>> primary deliverable. The primary deliverable should be a document
>> that specifies how IPv6 can be used in networks with rapidly
>> varying topologies, and describes any new functionality required at
>> the IP layer [that may result from constraints imposed by
>> different classes of access technologies (such as frame size
>> limits)] independent of any particular access technology (MAC and
>> PHY) employed. /*
>
> You might have a better understanding of what has been done to run
> IPv6 on 802.11 OCB in IEEE or elsewhere but your statement that the
> mechanisms are already in place *does not correspond at all* to the
> drafts that were presented at the its BoF meeting in Berlin. The
> slides are here
>
> * What is the size of the MTU on 802.11-OCB * How to communicate the
> MTU between 802.11-OCB nodes? * What layer does the fragmentation -
> IP and/or MAC * Frame format: Use 802.11 Data or 802.11 QoS Data *
> Address mappings (unicast and multicast) ...
>
> In short an IPv6 over foo specification. If you think all this work
> has been done, please post a comment on the list with pointers. I am
> sure the draft authors will greatly appreciate it.

YEs, certainly.

Any answers to that issues will be greatly improving the
IPv6-over-80211OCB work.

[...]

>> */[RR] Removal of OCB from the title of the effort is very
>> important.  The work to be done applies to ANY and ALL MACs and
>> PHYs that are used in rapidly varying environments including
>> standard Wi-Fi in all of its modes (11a, 11n, 11ac, 11g, 11b, …),
>> LTE-D2D when it arrives, IR (21214) mm-wave (21216), and any other
>> access technology that can be integrated into an ITS station!
> This was not what was discussed at the second its BoF which led to
> this charter and is pretty widely scoped. That really sounds to me
> more like a manet problem statement. If the other WG participants
> feel the same way as you, we can go back to the drawing board to
> figure it out.

I agree with the current charter.

Yes, IP runs over everything - from 11a to mm-wave.  But IP runs over
everything precisely because there is one individual
IPv6-over-foo document for each of these things (list of IPv6-over-foo 
RFCs inserted here).

For 11a, 11n, 11c, 11b - there is indeed a need to have an
IPv6-over-wifi Internet Draft; because today only an IPv6-over-Ethernet
exists.  Compared to Ethernet, WiFi involves a supplementary adaptation
layer.  If such IPv6-over-WiFi I-D existed we'd gladly refer to it in
the IPv6-over-80211-OCB I-D.

But I dont think there is place in this ipwave group to discuss an
additional IPv6-over-WiFi document.  The specialists of WiFi are in
other groups at IETF.

11ad-OCB (3.5Gbps beyond 11p's 27Mbps) - if such a thing ever comes
about, we will be able to improve - if need be - the IPv6-over-80211-OCB
  document.

Alex

> Thanks Suresh

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 7 Oct 2016 01:35:39 +0200

I don't mind that we do this IP over 80211-OCB as a start but why making it
the primary access for IPWAVE?

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 7 Oct 2016 02:22:02 +0200

> I agree with the current charter.
It is ok to use the current charter to do the job for the WG as a good
start, but we need to consider importance of the integration for IPv6 over
many Vehicular Technologies for ITS stations. We need to select best
technologies suitable for WAVE, because many countries/companies may use
different technology.

We should not work in narrow direction just because a sound of old WGs.
WGs follow their charters and we need to know others charters and I hope
IESG does too. I don't think it is manet problem statement, you need
to compare the charters not general-sounds or general-statements. MANET WG
does not talk about IPv6 over technologies, I really tried that years ago,
however, manet focuses on infrastructureless. IMHO the manet WG should
change its name because it was an old name, and it is making confusing to
many.

AB

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 8 Oct 2016 20:09:10 +0200

I dont understand what you mean by primary access for IPWAVE?

IPv6-over-80211-OCB can be used (1) as a subnet on an access - connect a 
vehicle to a Road-Side Unit which is connected to the Internet, (2) as a 
range extension - connect a vehicle to a RSU and further to another 
vehicle and (3) as a pure vehicle-to-vehicle subnet.

'A' in 'wave' is indeed 'access', but I read it more than just access 
like an e.g. LTE access to Internet.

IPv6-over-80211-OCB is a primary deliverable for ipwave at this time, in 
the sense of a first work item; maybe in the future we would work on a 
second(ary) IPv6-over-LiFi within the ipwave WG, then on a third 
(tertiary), and so on.  I think it could make sense.

Alex

Le 07/10/2016 à 01:35, Abdussalam Baryun a écrit :
> I don't mind that we do this IP over 80211-OCB as a start but why making
> it the primary access for IPWAVE?
>
> AB
>
> On Thu, Oct 6, 2016 at 2:23 PM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Russ,
>
>         On Oct 2, 2016, at 7:59 AM, Alexandre Petrescu
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Hi Russ,
>
>             <https://mailarchive.ietf.org/arch/msg/its/GTDvTFTpCS-zAqVonDXkQND5w-8>
>
>
>
>
>                 mailing list ([email-masked] <mailto:[email-masked]>) by
>                 2016-10-10.  Similarly, if you
>                 IESG mailing list ([email-masked] <mailto:[email-masked]>)
>                 by 2016-10-10.
>
>                 Russ
>
>
>                 On Sep 30, 2016, at 2:07 PM, The IESG
>                 <[email-masked] <mailto:[email-masked]>>
>                 wrote:
>
>                     list ([email-masked] <mailto:[email-masked]>) by
>                     2016-10-10.
>
>                     <[email-masked]
>                     <mailto:[email-masked]>>
>
>                     <[email-masked]
>                     <mailto:[email-masked]>> Suresh Krishnan
>                     <[email-masked]
>                     <mailto:[email-masked]>>
>
>                     Mailing list: Address: [email-masked]
>                     <mailto:[email-masked]> To subscribe:
>                     <https://www.ietf.org/mailman/listinfo/its> Archive:
>                     <https://www.ietf.org/mail-archive/web/its/current/maillist.html>
>
>
>
>
>     <https://datatracker.ietf.org/doc/charter-ietf-ipwave/>
>
>
>                     list [email-masked] <mailto:[email-masked]>
>                     <https://www.ietf.org/mailman/listinfo/its>
>
>
>                  [email-masked] <mailto:[email-masked]>
>                 <https://www.ietf.org/mailman/listinfo/its>
>
>
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/its>
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/its>
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 9 Oct 2016 00:10:56 +0200

yes I agree with you, it is not primary access just wg task,  it was my
confusion sorry,

AB

On Sat, Oct 8, 2016 at 8:09 PM, Alexandre Petrescu <
[email-masked]> wrote:

> range extension - connect a vehicle to a RSU and further to another vehicle
> and (3) as a pure vehicle-to-vehicle subnet.
>
> 'A' in 'wave' is indeed 'access', but I read it more than just access like
> an e.g. LTE access to Internet.
>

---

From: "Francois Simon" <[email-masked]>
Date: Sun, 9 Oct 2016 06:30:08 -0400

Ladies and Gentlemen;

PLEASE, STOP  including the word “WAVE” in the charter.  I have already commented on this.  “WAVE” is precisely the name ADOPTED BY IEEE FOR DSRC.  What did concerned me, is happening!

It started with “IPWAVE”, now, I see “short-cut” with just “WAVE”.  I suggest to you take a look at the attached. doc. which is the architecture of “WAVE” from IEEE view point.  You will see in this document that IPv6 is already addressed in the WAVE/DSRC Architecture.

Francois Simon

From: its [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: Saturday, October 08, 2016 6:11 PM
To: Alexandre Petrescu <[email-masked]>
Cc: Russ Housley <[email-masked]>; its <[email-masked]>
Subject: Re: [its] WG Review: IP Wireless Access in Vehicular Environments (ipwave) - Problem Statement work

yes I agree with you, it is not primary access just wg task,  it was my confusion sorry,

AB

On Sat, Oct 8, 2016 at 8:09 PM, Alexandre Petrescu <[email-masked] <mailto:[email-masked]> > wrote:

IPv6-over-80211-OCB can be used (1) as a subnet on an access - connect a vehicle to a Road-Side Unit which is connected to the Internet, (2) as a range extension - connect a vehicle to a RSU and further to another vehicle and (3) as a pure vehicle-to-vehicle subnet.

'A' in 'wave' is indeed 'access', but I read it more than just access like an e.g. LTE access to Internet.

IPv6-over-80211-OCB is a primary deliverable for ipwave at this time, in the sense of a first work item; maybe in the future we would work on a second(ary) IPv6-over-LiFi within the ipwave WG, then on a third (tertiary), and so on.  I think it could make sense.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 9 Oct 2016 16:57:21 +0200

Hi Francis,

Thank you for the email and for the pdf.

I think ipwave is appropriate here.  I think the charter does not say 
wave, but ipwave.  I other discussions also people talk about IP-V2V to 
distinguish from V2V.

Aspects of IPv6 may already be addressed in that pdf, and there could be 
some aspects which would be written here in _ip_wave.  E.g. the MTU 
size, the use of RA (Router Advertisement) instead of WSA (WAVE Service 
Advertisement), and more.

Where the charter says "IPv6 on 802.11-OCB is yet to be defined" it 
meansmthat there is no definition of IPv6 on 802.11-OCB.  The pdf 
referred to above does not offer such a definition either.

(a definition of IPv6-over-foo is, for example, RFC2464 for 
IPv6-over-Ethernet; that specifies a number of parameters like MTU size, 
IID formation and more).

Where the pdf says "Use of multicast MAC 11 addressing is permitted" and 
"IPv6 also supports special multicast addresses." a programmer needs to 
know how to map a multicast MAC into a multicast IP address.  The pdf 
does not say how, yet an IPv6-over-80211-OCB document would tell so.

and more.

Alex

Le 09/10/2016 à 12:30, Francois Simon a écrit :
> Ladies and Gentlemen;
>
>
>
> PLEASE, STOP  including the word “WAVE” in the charter.  I have
> already commented on this.  “WAVE” is precisely the name ADOPTED BY
> IEEE FOR DSRC.  What did concerned me, is happening!
>
>
>
> It started with “IPWAVE”, now, I see “short-cut” with just “WAVE”.
> I suggest to you take a look at the attached. doc. which is the
> architecture of “WAVE” from IEEE view point.  You will see in this
> document that IPv6 is already addressed in the WAVE/DSRC
> Architecture.
>
>
>
> Francois Simon
>
>
>
>
>
> *From:*its [mailto:[email-masked]] *On Behalf Of *Abdussalam
> Baryun *Sent:* Saturday, October 08, 2016 6:11 PM *To:* Alexandre
> Petrescu <[email-masked]> *Cc:* Russ Housley
> <[email-masked]>; its <[email-masked]> *Subject:* Re: [its] WG
> Review: IP Wireless Access in Vehicular Environments (ipwave) -
> Problem Statement work
>
>
>
> On Sat, Oct 8, 2016 at 8:09 PM, Alexandre Petrescu
> IPv6-over-80211-OCB can be used (1) as a subnet on an access -
> connect a vehicle to a Road-Side Unit which is connected to the
> Internet, (2) as a range extension - connect a vehicle to a RSU and
> further to another vehicle and (3) as a pure vehicle-to-vehicle
> subnet.
>
> IPv6-over-80211-OCB is a primary deliverable for ipwave at this time,
> in the sense of a first work item; maybe in the future we would work
> on a second(ary) IPv6-over-LiFi within the ipwave WG, then on a third

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 9 Oct 2016 16:58:24 +0200

Hi François,

and more.

Alex

Le 09/10/2016 à 12:30, Francois Simon a écrit :
> It started with “IPWAVE”, now, I see “short-cut” with just “WAVE”. I
> suggest to you take a look at the attached. doc. which is the
> 'A' in 'wave' is indeed 'access', but I read it more than just
> access like an e.g. LTE access to Internet.
>
> IPv6-over-80211-OCB is a primary deliverable for ipwave at this
> time, in the sense of a first work item; maybe in the future we would
> work on a second(ary) IPv6-over-LiFi within the ipwave WG, then on a
> third (tertiary), and so on.  I think it could make sense.
>
> Alex
>
>
>

---

From: Tony Li <[email-masked]>
Date: Sun, 9 Oct 2016 10:04:59 -0700

> On Oct 9, 2016, at 3:30 AM, Francois Simon <[email-masked]> wrote:
> 
> You will see in this document that IPv6 is already addressed in the WAVE/DSRC Architecture.

Francois,

While it’s very true that WAVE does provide IPv6 support, there are other, perhaps more flexible ways of supporting IP, such as are found in https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-04 <https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-04>. There are a class of applications that do not require WAVE that would benefit from such an approach.

I would like to propose that the WG accept the above draft as a WG document and that we work towards revising this document.

Regards,
Tony

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 10 Oct 2016 04:13:04 +0000

Thanks Tony and Alex for your comments and clarifications. Francois, I 
understand that you are concerned but I am not sure what changes you are 
requesting to the charter. Is it just the name? If so, can you propose an 
alternative for discussion (other than the super broadly scoped "its")

Regards
Suresh

On 10/09/2016 01:05 PM, Tony Li wrote:
>
>> On Oct 9, 2016, at 3:30 AM, Francois Simon <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
> While it’s very true that WAVE does provide IPv6 support, there are other,
> perhaps more flexible ways of supporting IP, such as are found
> in https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-04. There are
> a class of applications that do not require WAVE that would benefit from such
> an approach.
>
> I would like to propose that the WG accept the above draft as a WG document
> and that we work towards revising this document.
>
> Regards,
> Tony
>

---

From: John Kenney <[email-masked]>
Date: Sun, 9 Oct 2016 21:46:32 -0700

Hi Alex and All:

I think  "IPv6 on 802.11-OCB is yet to be defined" goes too far. It is
inaccurate, and could lead to the mis-impression that this IETF WG is
starting with a blank piece of paper. While there are many things for this
WG to define, the IEEE 1609 WG has defined *some* of IPv6 over 802.11-OCB
(see IEEE 1609.3).  It is important that any work the IETF does be
complementary and consistent with this, for example with the WAVE routing
advertisement in the WSA.  It would be better to qualify the statement in
the charter so that it is accurate (e.g. "yet to be fully defined"), and to
explicitly note the need for consistency with the those aspects of IPv6
over 802.11p-OCB already specified in 1609 standards.

Best Regards,
John

On Sun, Oct 9, 2016 at 7:57 AM, Alexandre Petrescu <
[email-masked]> wrote:

> some aspects which would be written here in _ip_wave.  E.g. the MTU size,
> the use of RA (Router Advertisement) instead of WSA (WAVE Service
> meansmthat there is no definition of IPv6 on 802.11-OCB.  The pdf referred
> to above does not offer such a definition either.
>
> know how to map a multicast MAC into a multicast IP address.  The pdf does
> not say how, yet an IPv6-over-80211-OCB document would tell so.
>
> and more.
>
> Alex
>

-- 
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: Suresh Krishnan <[email-masked]>
Date: Mon, 10 Oct 2016 04:53:46 +0000

Hi John,
That is a very good point. I will make the change.

Thanks
Suresh

-----Original Message-----
From: John Kenney [[email-masked]]
Received: Monday, 10 Oct 2016, 12:46AM
To: Alexandre Petrescu [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: Re: [its] WG Review: IP Wireless Access in Vehicular Environments (ipwave) - Problem Statement work

Hi Alex and All:

I think  "IPv6 on 802.11-OCB is yet to be defined" goes too far. It is inaccurate, and could lead to the mis-impression that this IETF WG is starting with a blank piece of paper. While there are many things for this WG to define, the IEEE 1609 WG has defined some of IPv6 over 802.11-OCB (see IEEE 1609.3).  It is important that any work the IETF does be complementary and consistent with this, for example with the WAVE routing advertisement in the WSA.  It would be better to qualify the statement in the charter so that it is accurate (e.g. "yet to be fully defined"), and to explicitly note the need for consistency with the those aspects of IPv6 over 802.11p-OCB already specified in 1609 standards.

Best Regards,
John

On Sun, Oct 9, 2016 at 7:57 AM, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Francis,

I think ipwave is appropriate here.  I think the charter does not say wave, but ipwave.  I other discussions also people talk about IP-V2V to distinguish from V2V.

Aspects of IPv6 may already be addressed in that pdf, and there could be some aspects which would be written here in _ip_wave.  E.g. the MTU size, the use of RA (Router Advertisement) instead of WSA (WAVE Service Advertisement), and more.

Where the charter says "IPv6 on 802.11-OCB is yet to be defined" it meansmthat there is no definition of IPv6 on 802.11-OCB.  The pdf referred to above does not offer such a definition either.

(a definition of IPv6-over-foo is, for example, RFC2464 for IPv6-over-Ethernet; that specifies a number of parameters like MTU size, IID formation and more).

Where the pdf says "Use of multicast MAC 11 addressing is permitted" and "IPv6 also supports special multicast addresses." a programmer needs to know how to map a multicast MAC into a multicast IP address.  The pdf does not say how, yet an IPv6-over-80211-OCB document would tell so.

and more.

Alex

Francois Simon

*From:*its [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Abdussalam
Baryun *Sent:* Saturday, October 08, 2016 6:11 PM *To:* Alexandre
Petrescu <[email-masked]<mailto:[email-masked]>> *Cc:* Russ Housley
<[email-masked]<mailto:[email-masked]>>; its <[email-masked]<mailto:[email-masked]>> *Subject:* Re: [its] WG
Review: IP Wireless Access in Vehicular Environments (ipwave) -
Problem Statement work

yes I agree with you, it is not primary access just wg task,  it was
my confusion sorry,

AB

On Sat, Oct 8, 2016 at 8:09 PM, Alexandre Petrescu
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
wrote:

Alex

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

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 10 Oct 2016 10:23:03 +0200

Hi,

I would like to add a minor comment.

I would like to say that "IPv6 _straight_ over 802.11-OCB" is not
defined anywhere.  And that is what is implemented.

The P1609 document does write about IPv6-over-802.11 but the LLC layer
seems to include a mandatory P1609.4 channel scheduling access (that is
beyond 802.11-OCB).  The question has been raised several times to
people in the know, about whether that P1609.4 is mandatory in order for
IPv6 to work, or is optional - no reply at this time.

This P1609.4 channel scheduling access is not yet implemented, at least 
not in the 802.11-OCB implemenations that I have seen.  I think it is 
not yet released as a standard either.

In addition to IEEE, there is a similar situation at ETSI ITS.

For these reasons, I could very well live with a charter text that said
"IPv6 _straight_ over 802.11-OCB is yet to be defined".

The two cents worth.

Alex

Le 10/10/2016 à 06:53, Suresh Krishnan a écrit :
> Hi John, That is a very good point. I will make the change.
>
> Thanks Suresh
>
> -----Original Message----- *From:* John Kenney
> [[email-masked]] *Received:* Monday, 10 Oct 2016, 12:46AM
> *To:* Alexandre Petrescu [[email-masked]] *CC:*
> [email-masked] [[email-masked]] *Subject:* Re: [its] WG Review: IP
> Wireless Access in Vehicular Environments (ipwave) - Problem
> Statement work
>
> Hi Alex and All:
>
> I think  "IPv6 on 802.11-OCB is yet to be defined" goes too far. It
> is inaccurate, and could lead to the mis-impression that this IETF WG
> is starting with a blank piece of paper. While there are many things
> for this WG to define, the IEEE 1609 WG has defined _some_ of IPv6
> over 802.11-OCB (see IEEE 1609.3).  It is important that any work the
> IETF does be complementary and consistent with this, for example with
> the WAVE routing advertisement in the WSA.  It would be better to
> qualify the statement in the charter so that it is accurate (e.g.
> "yet to be fully defined"), and to explicitly note the need for
> consistency with the those aspects of IPv6 over 802.11p-OCB already
> specified in 1609 standards.
>
> Best Regards, John
>
>
> On Sun, Oct 9, 2016 at 7:57 AM, Alexandre Petrescu
> wave, but ipwave.  I other discussions also people talk about IP-V2V
> to distinguish from V2V.
>
> Aspects of IPv6 may already be addressed in that pdf, and there could
> be some aspects which would be written here in _ip_wave.  E.g. the
> MTU size, the use of RA (Router Advertisement) instead of WSA (WAVE
> Service Advertisement), and more.
>
> IPv6-over-Ethernet; that specifies a number of parameters like MTU
> size, IID formation and more).
>
> Where the pdf says "Use of multicast MAC 11 addressing is permitted"
> and "IPv6 also supports special multicast addresses." a programmer
> needs to know how to map a multicast MAC into a multicast IP address.
> The pdf does not say how, yet an IPv6-over-80211-OCB document would
> tell so.
>
> and more.
>
> Alex
>
> *From:*its [mailto:[email-masked]
> <mailto:[email-masked]>] *On Behalf Of *Abdussalam Baryun
> *Sent:* Saturday, October 08, 2016 6:11 PM *To:* Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* Russ Housley <[email-masked]
> <mailto:[email-masked]>>; its <[email-masked]
> <mailto:[email-masked]>> *Subject:* Re: [its] WG Review: IP Wireless
> Access in Vehicular Environments (ipwave) - Problem Statement work
>
>
>
> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]
> <mailto:[email-masked]>>> wrote:
>
> -- 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: John Kenney <[email-masked]>
Date: Mon, 10 Oct 2016 23:21:29 +1100

Hi Alex,

Thanks for raising this question. I think there has been a lot of confusion
about what IEEE 1609.4 requires.  This stems, in part, from the fact that
the requirements of 1609.4 changed in an important way between the 2006
"trial use" standard and the 2010 "full use" standard.  (I'm speaking for
myself here, not for the 1609 WG)

The 2010 version, which was updated earlier this year, significantly
liberalizes requirements about channel switching.  To put it simply, under
IEEE 1609.4-2010 (and -2016) a WAVE device is permitted to switch or not
switch, as it chooses, and it can change its switching behavior at any
time.  A device that never switches is compliant with 1609.4, which was not
true in the 2006 trial use standard.  A device that chooses to switch
channels may switch at any time for any reason.  The main thing that 1609.4
does is define an interoperable way for devices that want to rendezvous in
time and frequency to do so. It also defines management plane primitives to
support various modes of switching.

So, compliance with IEEE 1609.4 is available to all WAVE devices,
regardless of whether they switch or not. There is no mandatory channel
switching access.  In that sense, I assert that the combination of 1609.x
standards *does* define a way of achieving interoperable
IPv6-straight-over-802.11-OCB, as you referred to it.

I hope my explanation helps clarify this sometimes confusing issue.

I'm also not quite sure what this means:

This P1609.4 channel scheduling access is not yet implemented, at least not
in the 802.11-OCB implemenations that I have seen.  I think it is not yet
released as a standard either.

Various modes of switching, including "alternating access," "immediate
access," extended access," and "continuous access," are defined in
1609.4-2010 [NB: explicit mention of extended access is dropped in the 2016
standard since it can be considered redundant with combinations of the
other modes].  Implementations that support these modes are widely
available.  Finally, I note that the 1609 standards describe the channel
switching mechanism as an extension of the 802.11 MAC sublayer, not part of
the LLC (another common point of confusion).

Best Regards,
John

On Mon, Oct 10, 2016 at 7:23 PM, Alexandre Petrescu <
[email-masked]> wrote:

> not in the 802.11-OCB implemenations that I have seen.  I think it is not
> yet released as a standard either.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 11 Oct 2016 08:07:12 +0200

Hi John,

Le 10/10/2016 à 14:21, John Kenney a écrit :
> Hi Alex,
>
> Thanks for raising this question. I think there has been a lot of
> confusion about what IEEE 1609.4 requires.  This stems, in part,
> from the fact that the requirements of 1609.4 changed in an important
> way between the 2006 "trial use" standard and the 2010 "full use"
> standard. (I'm speaking for myself here, not for the 1609 WG)
>
> liberalizes requirements about channel switching.  To put it simply,
> under IEEE 1609.4-2010 (and -2016) a WAVE device is permitted to
> switch or not switch, as it chooses, and it can change its switching
>  behavior at any time.

This is good to know.

So it makes it that an 802.11p is compliant with 1609.4 even though it
does not have channel switch capability in the MAC.  I hope I understand
it right.

> A device that never switches is compliant with 1609.4, which was not
>  true in the 2006 trial use standard.  A device that chooses to
> switch channels may switch at any time for any reason.  The main
> thing that 1609.4 does is define an interoperable way for devices
> that want to rendezvous in time and frequency to do so. It also
> defines management plane primitives to support various modes of
> switching.
>
> regardless of whether they switch or not. There is no mandatory
> channel switching access.  In that sense, I assert that the
> combination of 1609.x standards _does_ define a way of achieving
> interoperable IPv6-straight-over-802.11-OCB, as you referred to it.

If channel switching is optional then yes, it defines the IEEE way.

> This P1609.4 channel scheduling access is not yet implemented, at
> least not in the 802.11-OCB implemenations that I have seen.  I think
> it is not yet released as a standard either.
>
>
> Various modes of switching, including "alternating access,"
> "immediate access," extended access," and "continuous access," are
> defined in 1609.4-2010 [NB: explicit mention of extended access is
> dropped in the 2016 standard since it can be considered redundant
> with combinations of the other modes].  Implementations that support
>  these modes are widely available.

Well, I have personally not seen something about these accesses
(alternating, immediate, continuous) in 802.11p driver in linux derived
from ath5k, with UNEX/autotalks hardware.

Maybe some other hardware/software combination implements it?

> Finally, I note that the 1609 standards describe the channel
> switching mechanism as an extension of the 802.11 MAC sublayer, not
> part of the LLC (another common point of confusion).

I would like to also note that switching between channels can also be
achieved above the MAC and IP layer, in the application layer: multiple
single-channel 802.11p cards in a router, and an IP default route
switched by a connection management software.  There are some
implementations of this.

Alex

>
> Best Regards, John
>
>
> On Mon, Oct 10, 2016 at 7:23 PM, Alexandre Petrescu
> The P1609 document does write about IPv6-over-802.11 but the LLC
> layer seems to include a mandatory P1609.4 channel scheduling access
>  (that is beyond 802.11-OCB).  The question has been raised several
> times to people in the know, about whether that P1609.4 is mandatory
>  in order for IPv6 to work, or is optional - no reply at this time.
>
> This P1609.4 channel scheduling access is not yet implemented, at
> least not in the 802.11-OCB implemenations that I have seen.  I think
> it is not yet released as a standard either.
>
> For these reasons, I could very well live with a charter text that
> said "IPv6 _straight_ over 802.11-OCB is yet to be defined".
>
> The two cents worth.
>
> Alex
>
> [[email-masked] <mailto:[email-masked]>]
> *Received:* Monday, 10 Oct 2016, 12:46AM *To:* Alexandre Petrescu
> [[email-masked] <mailto:[email-masked]>]
>  *CC:* [email-masked] <mailto:[email-masked]> [[email-masked]
> <mailto:[email-masked]>] *Subject:* Re: [its] WG Review: IP Wireless
> is inaccurate, and could lead to the mis-impression that this IETF
> WG is starting with a blank piece of paper. While there are many
> things for this WG to define, the IEEE 1609 WG has defined _some_ of
> IPv6 over 802.11-OCB (see IEEE 1609.3).  It is important that any
> work the IETF does be complementary and consistent with this, for
> example with the WAVE routing advertisement in the WSA.  It would be
> better to qualify the statement in the charter so that it is accurate
> (e.g. "yet to be fully defined"), and to explicitly note the need
> for consistency with the those aspects of IPv6 over 802.11p-OCB
> already specified in 1609 standards.
>
> Best Regards, John
>
>
> <mailto:[email-masked]>>>
>
> wrote:
>
> Hi Francis,
>
> I think ipwave is appropriate here.  I think the charter does not
> say wave, but ipwave.  I other discussions also people talk about
> IP-V2V to distinguish from V2V.
>
> Aspects of IPv6 may already be addressed in that pdf, and there
> could be some aspects which would be written here in _ip_wave.  E.g.
> the MTU size, the use of RA (Router Advertisement) instead of WSA
> (WAVE Service Advertisement), and more.
>
> needs to know how to map a multicast MAC into a multicast IP
> address. The pdf does not say how, yet an IPv6-over-80211-OCB
> document would tell so.
>
> and more.
>
> Alex
>
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>] *On Behalf Of *Abdussalam Baryun
> <mailto:[email-masked]>>> *Cc:* Russ Housley
> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>; its
> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>> *Subject:* Re: [its] WG Review: IP Wireless
> <mailto:[email-masked]>>
> <mailto:[email-masked]>
> <mailto:[email-masked]>>>> wrote:
>
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>
>
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>
>
>
>
> 94043 Tel: 650-694-4160 <tel:650-694-4160>. Mobile: 650-224-6644
> <tel:650-224-6644>
>
>
>
>