From nobody Sat Apr 2 13:04:57 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1ED012D588 for ; Sat, 2 Apr 2016 13:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nC6x54Ox2mF for ; Sat, 2 Apr 2016 13:04:53 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CA212D55A for ; Sat, 2 Apr 2016 13:04:52 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id k79so116360533lfb.2 for ; Sat, 02 Apr 2016 13:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kURUoBDboXCssdzzLqd/dToYMYMLFr8uNEj4ibZZhCQ=; b=QjB6vVqrToGyHvezLeow7F4iC3TLLh99P8Zj2WFRSp67usVhF9iq/J31SMsP4nUGas adm39Dg9wUfa+SheIDJW5s9tnvcMtxf1nSvKLT0dA/0we6mlbl28Rnj8MC4+ncCoJnEj 0NY/M4ADNKYd9UFuulctKXxTGIVF4y2bI2yottPuNzw7ya1Fhw+Viss3WN3ru7uwLUQ/ k3KKHgyr5ZghU/C44SohlmAeyGDJ1aNL67cTNllGF+sKT6hX3AYGNa0s7IiM5xeGtlTX MzZkEAlOmdj1RA/3DYY0Y1Uw5xTBoqg4Lg9Qmy7eZxywKBxztvA9PM5R7KNlKPjvvCxu 7dJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kURUoBDboXCssdzzLqd/dToYMYMLFr8uNEj4ibZZhCQ=; b=dhB9Ityw2P5+1LWRYRIOb0pCxh6FcmM306Lwti2jiYiIm9SSGzc9/avcr2buYnYW7B sfVXyWMJfk+E9dQpfxraGGBNgSiMZYPPDnoL+ZM5EG1sAVZoQCAX4yG+vrr10RXQ2CZz zILfemjQ0CLW1w5imT2dcn8tAt1u6e9r/nJAQFYcE3H9hU5JaDEle/+gxWK9qWdAqPYh n4kPQ+cTTrg/usZMUhyi983AnBfPKKsT8G/A8AuBZiYgmxYdxELaNHWimUEqeqeDDpNx bje7hXTwQqTTidI5W8dUfvVM6A7hA7iPhktJmxkD8mLHcpe6nxVc7A7qi3XkcAKhJ4Xm 8JIQ== X-Gm-Message-State: AD7BkJJ68tIzpxc/A8iyYR/jAnYtD9k7cW/0I5+sHJetirl5/tsZXQyLfcy5E4u+smdruGC3158Fej4FE82bLQ== MIME-Version: 1.0 X-Received: by 10.194.82.66 with SMTP id g2mr15015104wjy.161.1459627490255; Sat, 02 Apr 2016 13:04:50 -0700 (PDT) Received: by 10.28.224.137 with HTTP; Sat, 2 Apr 2016 13:04:50 -0700 (PDT) In-Reply-To: References: <56C465DB.8060305@gmail.com> Date: Sat, 2 Apr 2016 17:04:50 -0300 Message-ID: From: Nabil Benamar To: "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary=047d7bf0c5600faca7052f8602df Archived-At: Cc: Thierry Ernst , "its@ietf.org" , knut.evensen@q-free.com, "Dr. Hans-Joachim Fischer" , Alexandre Petrescu , dickroy@alum.mit.edu Subject: Re: [its] Comments for a New Draft of Problem Statement for V2I Networking X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 20:04:56 -0000 --047d7bf0c5600faca7052f8602df Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jaehoon, Here are some comments: *Introduction* * =E2=80=9C Recently,=E2=80=A6..=E2=80=9D This is not recent since the wo= rks on VANETs and its use cases have been done for a while =E2=80=A6 such as driving safety, effi= cient driving, and entertainment! There are a lot of journal papers tackling in details this topic.* *This section can be modified as follows: * *Vehicular Networks have become a popular topic during the last years due to the important applications that can be realized in such environment.* *=E2=80=9C =E2=80=A6 with a consideration of the vehicular network's charac= teristics such as a vehicle's velocity and collision avoidance.=E2=80=9D* *Collision avoidance is a consequence and a goal to attend and not a characteristic of this IEEE standard.* *=E2=80=9C=E2=80=A6.IPv6 [RFC2460] is suitable for vehicular networks since= the protocol has* * abundant address space, autoconfiguration features, and protocol extension ability through extension headers.=E2=80=9D* *Better to mention the draft =E2=80=98https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-03 =E2=80=99 = as a supporting reference here. * *=E2=80=9Cit is assumed that the prefix assignment for each subnet inside* * the vehicle's mobile network and the RSU's infra-node network through* * a prefix delegation protocol.=E2=80=9D* *Prefex delegation is only possible through DHCPv6-PD, is this what you mean ?* *=E2=80=9CAlso, the DNS naming service should be supported for the* * DNS name resolution for a host or server in either the vehicle's* * mobile network or the RSU's infra-node network.=E2=80=9D* *So what could be the issue here ? Is DNS an issue? DNS information are included in RA with the flag =E2=80=9CO=E2=80=9D enabled.* *=E2=80=9CThe former approach is* * usually used by Mobile Ad Hoc Networks (MANET) for a separate multi-* * link subnet.=E2=80=9D* *Site local addressing is deprecated RFC 3879=E2=80=A6so no need to mention= it in the current draft.* *=E2=80=9CDHCPv6 (or Stateless DHCPv6) can be used for the IP address* * autoconfiguration [RFC3315][RFC3736] =E2=80=9C* *There is no more autoconfiguration when we use DHCPv6=E2=80=A6So this sent= ence should be corrected accordingly.* Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Wed, Feb 24, 2016 at 8:57 AM, Mr. Jaehoon Paul Jeong < jaehoon.paul@gmail.com> wrote: > Hi Richard, > I will check the IOS standards related to ITS, which are pointed by you. > > I agree with you that you need to use well-known terminology for our ITS > work. > > For 802.11p, as I know, both industry and academia are considering it as > Dedicated Short-Range Communications (DSRC) for vehicular networking. > > Thanks. > > Best Regards, > Paul > > > On Thu, Feb 18, 2016 at 6:24 AM, Richard Roy wrote= : > >> Alex/Paul, >> >> I suspect much of what you are thinking needs standardization below has >> already been standardized. You might want to check out ISO 21217 (ITS >> station/communication architecture), followed by ISO 21210 (IPv6 >> networking >> for ITS). If nothing else, we already have terms for all of the >> configurations you describe below (see ISO 21217). It would be best to >> stick with this now well-known terminology. >> >> By the way, none of this depends on 802.11 5.9GHz in the data link and >> physical layers. I continue to wonder why 802.11p ever comes up. It >> could >> just as well be 5.4GHz BRAN, 2.4GHz ISM, IR, tin can and a string, or >> whatever ... >> >> Cheers, >> >> RR >> >> > -----Original Message----- >> > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] >> > Sent: Wednesday, February 17, 2016 4:22 AM >> > To: Mr. Jaehoon Paul Jeong >> > Cc: its@ietf.org >> > Subject: Re: [its] Comments for a New Draft of Problem Statement for V= 2I >> > Networking >> > >> > Hello Paul, >> > >> > Thanks a lot for this draft. This V2I problem statement covers many >> > things we have discussed in Yokohama. >> > >> > What do the others think about this draft? >> > >> > I hame some comments, see below. >> > >> > Le 15/02/2016 17:30, Mr. Jaehoon Paul Jeong a =C3=A9crit : >> > > Hi ITS Colleagues, >> > > >> > > Title: Problem Statement for Vehicle-to-Infrastructure Networking >> > > I-D: draft-jeong-its-v2i-problem-statement-00 Link: >> > > https://tools.ietf.org/html/draft-jeong-its-v2i-problem-statement-00 >> > > >> > > Abstract This document specifies the problem statement for >> > > IPv6-based vehicle- to-infrastructure networking. Dedicated >> > > Short-Range Communications (DSRC) is standardized as IEEE 802.11p fo= r >> > > the wireless media access in vehicular networks. This document >> > > addresses the extension of IPv6 as the network layer protocol in >> > > vehicular networks and is focused on the networking issues in >> > > one-hop communication between a Road-Side Unit (RSU) and vehicle. >> > > The RSU is connected to the Internet and allows vehicles to have the >> > > Internet access if connected. The major issues of including IPv6 in >> > > vehicular networks are neighbor discovery protocol, stateless >> > > address autoconfiguration, and DNS configuration for the Internet >> > > connectivity over DSRC. Also, when the vehicle and the RSU have an >> > > internal network, respectively, the document discusses the issues of >> > > internetworking between the vehicle's internal network and the RSU's >> > > internal network. >> > > >> > > If you have comments or questions, please let me know. >> > >> > You can use the documentation prefixes 2001:db8:1000::/63 (instead of >> > real addresses like 2001:1000::/63). >> > >> > The term "RSU infra-node network" is something new and may need to be >> > present in the definitions section. >> > >> > If I understand you correctly, the RSU infra-node network is a network >> > of IP-addressable devices which are present in the Road-Side Unit - >> right? >> > >> > I am asking because I know some such RSUs on the market which contain >> > several IP-addressable devices linked together, but we dont have a nam= e >> > for them. The "RSU infra-node network" sounds good, I think. >> > >> > For the term "mobile network" - we can rather use maybe >> > "moving network". >> > >> > In section 5 "Internetworking between the Vehicle and RSU networks": >> > > Problems are a prefix discovery and prefix exchange. The prefix >> > > discovery is defined as how routers in a mobile network discover >> > > prefixes in the mobile network. The prefix exchange is defined as >> > > how the vehicle and the RSU exchange their prefixes with each other. >> > >> > I agree with the problem of prefix exchange. >> > >> > For the "prefix discovery", I have some doubts. >> > >> > First, the routers inside the moving network can be pre-configured wit= h >> > the prefixes inside that moving network. If so, then there can be no >> > need for these routers to discover the prefixes inside the same moving >> > network. But, of course, if they are not preconfigured then they have >> > to be discovered somehow. >> > >> > Second, there is a need for one router (the mobile router?) in the >> > moving network to discover several parameters of a nearby moving >> > network, and also the parameters of a "RSU infra-node network". These >> > parameters, including the IP prefix of the other network, are listed i= n >> > draft-petrescu-its-problem-01 section 3.1 "Discovery Sub-Problem". It >> > would be good to use same terminology for this discovery. >> > >> > > This section discusses IP addressing for V2I networking. There are >> > > two policies for IPv6 addressing in vehicular networks. The one >> > > policy is to use site-local IPv6 addresses for vehicular networks >> > > [RFC4291]. >> > >> > Since the site-local IPv6 addresses (fec0::) have been deprecated, it >> > would be appropriate to mention "Unique Local Addresses" (ULAs) which >> > can somehow play the role that seems to be needed here. I suggest to >> > substitute ULA for site-local addresses. >> > >> > > The former approach is >> > > usually used by Mobile Ad Hoc Networks (MANET) for a separate >> multi- >> > > link subnet. >> > >> > MANET has a certain meaning at IETF: it's the WG MANET. I dont think >> > there is any MANET draft that recommends ULAs (but maybe they recommen= d >> > site-locals?). Maybe ask the MANET WG what is the MANET IP Addressing >> > Architecture (do they use ULAs? do they use GUA - globals?). If yes >> > then refer to MANET WG document here. >> > >> > > Sections 7 ND, 8 address autoconf, 9 DNS >> > >> > I agree with these sections 7, 8 and 9. >> > >> > > 10. IP Mobility Support >> > > >> > > This section discusses an IP mobility support in V2I networking. >> In >> > > a single subnet per RSU, vehicles keep crossing the communication >> > > coverages of adjacent RSUs. During this crossing, TCP/UDP sessio= ns >> > > can be maintained through IP mobility support, such as Mobile IPv= 6 >> > > [RFC6275]. Since vehicles move fast along roadways, this high >> speed >> > > should be configured for a parameter configuration in Mobile IPv6= . >> > > >> > > To support the mobility of a vehicle's mobile network, Network >> > > Mobility (NEMO) protocol can be used [RFC3963]. Like Mobile IPv6= , >> > > the high speed of vehicles should be considered for a parameter >> > > configuration in NEMO. >> > >> > I agree. >> > >> > I would like to add the following: >> > >> > 1. When Mobile IPv6/NEMO is used by the Mobile Router connected to >> > the RSU infra-node a tunnel is established between the MR and its >> > Home Agent in the TCC (Traffic Control Center). If a node inside >> > the moving network (not the MR) needs to exchange data with a node >> > within the RSU infra-node network then that communication must >> > go through the Home Agent. The delays on the path to the HA may b= e >> > too high for the reactivity needed between a vehicle and an RSU, o= r >> > the path can even be blocked. For this reason it is necessary to >> > accommodate direct communications (skip the HA) between a node in >> > the moving network and a node in the RSU infra-node network. This >> > can be achieved only if the two networks learn each other's >> prefixes. >> > >> > 2. A new method of connecting the moving network directly to the RSU >> > infra-node network may lead to modifying the addressing architectu= re >> > in the moving network. This can become a problem to the use of >> > Mobile IP, because Mobile IP relies on the addressing architecture >> > controlled by the Home Agent. This problem should be solved as >> well. >> > >> > >> > In section 11 Security Considerations: >> > > 11. Security Considerations >> > > >> > > The security is very important in vehicular networks for V2I >> > > networking. Only valid vehicles should be allowed to use V2I >> > > networking in vehicular networks. VIN and a user certificate can >> be >> > > used to authenticate a vehicle and the user. >> > > >> > > This document shares all the security issues of the neighbor >> > > discovery protocol. This document can get benefits from secure >> > > neighbor discovery (SEND) [RFC3971] >> > >> > Recent works in security for vehicular networks mention two additional >> > things that are worth considering: >> > >> > 1. the use of TLS certificates for vehicle communications >> > draft-lonc-tls-certieee1609-01 >> > >> > 2. privacy considerations: a new ETSI activity may consider privacy >> > aspects of identifier generation in vehicular communications. >> > >> > It is worth referring to these aspects (give references). >> > >> > Yours, >> > >> > Alex >> > >> > >> > >> > > >> > > Thanks. >> > > >> > > Best Regards, Paul -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. Jaehoon (Paul) >> > > Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan >> > > University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >> > > , pauljeong@skku.edu >> > > Personal Homepage: >> > > http://iotlab.skku.edu/people-jaehoon-jeong.php >> > > >> > > >> > > >> > > _______________________________________________ its mailing list >> > > its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > > >> > >> >> >> > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --047d7bf0c5600faca7052f8602df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jaehoon,

Here are s= ome comments:

Introduction


=C2=A0 =E2=80=9C Recently,=E2=80=A6..=E2=80=9D=C2=A0 This = is not recent since the works on VANETs and its use cases have been done fo= r a while =E2=80=A6 such as driving safety, efficient driving, and entertai= nment! There are a lot of journal papers tackling in details this topic.

This section can be modified as follows:=C2=A0

Vehicular Networks have become a popular topic during the = last years due to the important applications that can be realized in such e= nvironment.


=E2=80=9C =E2=80=A6 with a consideration of the vehicular = network's characteristics such as a vehicle's velocity and collisio= n avoidance.=E2=80=9D


Collision avoidance is a consequence and a goal to attend = and not a characteristic of this IEEE standard.


=E2=80=9C=E2=80=A6.IPv6 [RFC2460] is suitable for vehicula= r networks since the protocol has

=C2=A0=C2=A0 abundant address space, autoconfiguration fea= tures, and protocol extension ability through extension headers.=E2=80=9D


Better to mention the draft =E2=80=98https://tools.ietf.or= g/html/draft-petrescu-ipv6-over-80211p-03=E2=80=99 =C2=A0 as a supporti= ng reference here. =C2=A0


=E2=80=9Cit is assumed that the prefix assignment for each= subnet inside

=C2=A0=C2=A0 the vehicle's mobile network and the RSU&= #39;s infra-node network through

=C2=A0=C2=A0 a prefix delegation protocol.=E2=80=9D


Prefex delegation is only possible through DHCPv6-PD, is t= his what you mean ?


=E2=80=9CAlso, the DNS naming service should be supported = for the

=C2=A0=C2=A0 DNS name resolution for a host or server in e= ither the vehicle's

=C2=A0=C2=A0 mobile network or the RSU's infra-node ne= twork.=E2=80=9D


So what could be the issue here ? Is DNS an issue? DNS inf= ormation are included in RA with the flag =E2=80=9CO=E2=80=9D enabled.<= /p>


=E2=80=9CThe former approach is

=C2=A0=C2=A0 usually used by Mobile Ad Hoc Networks (MANET= ) for a separate multi-

=C2=A0=C2=A0 link subnet.=E2=80=9D


Site local addressing is deprecated RFC 3879=E2=80=A6so no= need to mention it in the current draft.


=E2=80=9CDHCPv6 (or Stateless DHCPv6) can be used for the = IP address

=C2=A0=C2=A0 autoconfiguration [RFC3315][RFC3736] =E2=80= =9C


There is no more autoconfiguration when we use DHCPv6=E2= =80=A6So this sentence should be corrected accordingly.

=

Best regards
Nabil Benamar
-------------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86= =D8=B9=D9=85=D8=B1=D9=88


On Wed, Feb 24, 2016 at 8:57 AM, Mr. Jaehoon= Paul Jeong <jaehoon.paul@gmail.com> wrote:
Hi Richard,
I will check the IO= S standards related to ITS, which are pointed by you.

<= div>I agree with you that you need to use well-known terminology for our IT= S work.

For 802.11p, as I know, both industry and = academia are considering it as=C2=A0
Dedicated Short-Range Commun= ications (DSRC) for vehicular networking.=C2=A0

Th= anks.

Best Regards,
Paul

<= /div>

On Thu, Feb 18, 2016 at 6:24 AM, Richard Roy &= lt;dickroy@alum.m= it.edu> wrote:
Alex/Paul,

I suspect much of what you are thinking needs standardization below has
already been standardized.=C2=A0 You might want to check out ISO 21217 (ITS=
station/communication architecture), followed by ISO 21210 (IPv6 networking=
for ITS).=C2=A0 If nothing else, we already have terms for all of the
configurations you describe below (see ISO 21217).=C2=A0 It would be best t= o
stick with this now well-known terminology.

By the way, none of this depends on 802.11 5.9GHz in the data link and
physical layers.=C2=A0 I continue to wonder why 802.11p ever comes up.=C2= =A0 It could
just as well be 5.4GHz BRAN, 2.4GHz ISM, IR, tin can and a string, or
whatever ...

Cheers,

RR

> -----Original Message-----
> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
> Sent: Wednesday, February 17, 2016 4:22 AM
> To: Mr. Jaehoon Paul Jeong
> Cc: its@ietf.org=
> Subject: Re: [its] Comments for a New Draft of Problem Statement for V= 2I
> Networking
>
> Hello Paul,
>
> Thanks a lot for this draft.=C2=A0 This V2I problem statement covers m= any
> things we have discussed in Yokohama.
>
> What do the others think about this draft?
>
> I hame some comments, see below.
>
> Le 15/02/2016 17:30, Mr. Jaehoon Paul Jeong a =C3=A9crit :
> > Hi ITS Colleagues,
> >
> > Title: Problem Statement for Vehicle-to-Infrastructure Networking=
> > I-D: draft-jeong-its-v2i-problem-statement-00 Link:
> > https://tools.ietf.org= /html/draft-jeong-its-v2i-problem-statement-00
> >
> > Abstract This document specifies the problem statement for
> > IPv6-based vehicle- to-infrastructure networking.=C2=A0 Dedicated=
> > Short-Range Communications (DSRC) is standardized as IEEE 802.11p= for
> > the wireless media access in vehicular networks.=C2=A0 This docum= ent
> > addresses the extension of IPv6 as the network layer protocol in<= br> > > vehicular networks and is focused on the networking issues in
> > one-hop communication between a Road-Side Unit (RSU) and vehicle.=
> > The RSU is connected to the Internet and allows vehicles to have = the
> > Internet access if connected.=C2=A0 The major issues of including= IPv6 in
> > vehicular networks are neighbor discovery protocol, stateless
> > address autoconfiguration, and DNS configuration for the Internet=
> > connectivity over DSRC.=C2=A0 Also, when the vehicle and the RSU = have an
> > internal network, respectively, the document discusses the issues= of
> > internetworking between the vehicle's internal network and th= e RSU's
> > internal network.
> >
> > If you have comments or questions, please let me know.
>
> You can use the documentation prefixes 2001:db8:1000::/63 (instead of<= br> > real addresses like 2001:1000::/63).
>
> The term "RSU infra-node network" is something new and may n= eed to be
> present in the definitions section.
>
> If I understand you correctly, the RSU infra-node network is a network=
> of IP-addressable devices which are present in the Road-Side Unit - ri= ght?
>
> I am asking because I know some such RSUs on the market which contain<= br> > several IP-addressable devices linked together, but we dont have a nam= e
> for them.=C2=A0 The "RSU infra-node network" sounds good, I = think.
>
> For the term "mobile network" - we can rather use maybe
> "moving network".
>
> In section 5 "Internetworking between the Vehicle and RSU network= s":
> > Problems are a prefix discovery and prefix exchange.=C2=A0 The pr= efix
> > discovery is defined as how routers in a mobile network discover<= br> > > prefixes in the mobile network.=C2=A0 The prefix exchange is defi= ned as
> > how the vehicle and the RSU exchange their prefixes with each oth= er.
>
> I agree with the problem of prefix exchange.
>
> For the "prefix discovery", I have some doubts.
>
> First, the routers inside the moving network can be pre-configured wit= h
> the prefixes inside that moving network.=C2=A0 If so, then there can b= e no
> need for these routers to discover the prefixes inside the same moving=
> network.=C2=A0 But, of course, if they are not preconfigured then they= have
> to be discovered somehow.
>
> Second, there is a need for one router (the mobile router?) in the
> moving network to discover several parameters of a nearby moving
> network, and also the parameters of a "RSU infra-node network&quo= t;.=C2=A0 These
> parameters, including the IP prefix of the other network, are listed i= n
> draft-petrescu-its-problem-01 section 3.1 "Discovery Sub-Problem&= quot;.=C2=A0 It
> would be good to use same terminology for this discovery.
>
> > This section discusses IP addressing for V2I networking.=C2=A0 Th= ere are
> > two policies for IPv6 addressing in vehicular networks.=C2=A0 The= one
> > policy is to use site-local IPv6 addresses for vehicular networks=
> > [RFC4291].
>
> Since the site-local IPv6 addresses (fec0::) have been deprecated, it<= br> > would be appropriate to mention "Unique Local Addresses" (UL= As) which
> can somehow play the role that seems to be needed here.=C2=A0 I sugges= t to
> substitute ULA for site-local addresses.
>
> > The former approach is
> >=C2=A0 =C2=A0 usually used by Mobile Ad Hoc Networks (MANET) for a= separate multi-
> >=C2=A0 =C2=A0 link subnet.
>
> MANET has a certain meaning at IETF: it's the WG MANET.=C2=A0 I do= nt think
> there is any MANET draft that recommends ULAs (but maybe they recommen= d
> site-locals?).=C2=A0 Maybe ask the MANET WG what is the MANET IP Addre= ssing
> Architecture (do they use ULAs?=C2=A0 do they use GUA - globals?).=C2= =A0 If yes
> then refer to MANET WG document here.
>
>=C2=A0 > Sections 7 ND, 8 address autoconf, 9 DNS
>
> I agree with these sections 7, 8 and 9.
>
> > 10.=C2=A0 IP Mobility Support
> >
> >=C2=A0 =C2=A0 This section discusses an IP mobility support in V2I= networking.=C2=A0 In
> >=C2=A0 =C2=A0 a single subnet per RSU, vehicles keep crossing the = communication
> >=C2=A0 =C2=A0 coverages of adjacent RSUs.=C2=A0 During this crossi= ng, TCP/UDP sessions
> >=C2=A0 =C2=A0 can be maintained through IP mobility support, such = as Mobile IPv6
> >=C2=A0 =C2=A0 [RFC6275].=C2=A0 Since vehicles move fast along road= ways, this high speed
> >=C2=A0 =C2=A0 should be configured for a parameter configuration i= n Mobile IPv6.
> >
> >=C2=A0 =C2=A0 To support the mobility of a vehicle's mobile ne= twork, Network
> >=C2=A0 =C2=A0 Mobility (NEMO) protocol can be used [RFC3963].=C2= =A0 Like Mobile IPv6,
> >=C2=A0 =C2=A0 the high speed of vehicles should be considered for = a parameter
> >=C2=A0 =C2=A0 configuration in NEMO.
>
> I agree.
>
> I would like to add the following:
>
> 1. When Mobile IPv6/NEMO is used by the Mobile Router connected to
>=C2=A0 =C2=A0 =C2=A0the RSU infra-node a tunnel is established between = the MR and its
>=C2=A0 =C2=A0 =C2=A0Home Agent in the TCC (Traffic Control Center).=C2= =A0 If a node inside
>=C2=A0 =C2=A0 =C2=A0the moving network (not the MR) needs to exchange d= ata with a node
>=C2=A0 =C2=A0 =C2=A0within the RSU infra-node network then that communi= cation must
>=C2=A0 =C2=A0 =C2=A0go through the Home Agent.=C2=A0 The delays on the = path to the HA may be
>=C2=A0 =C2=A0 =C2=A0too high for the reactivity needed between a vehicl= e and an RSU, or
>=C2=A0 =C2=A0 =C2=A0the path can even be blocked.=C2=A0 For this reason= it is necessary to
>=C2=A0 =C2=A0 =C2=A0accommodate direct communications (skip the HA) bet= ween a node in
>=C2=A0 =C2=A0 =C2=A0the moving network and a node in the RSU infra-node= network.=C2=A0 This
>=C2=A0 =C2=A0 =C2=A0can be achieved only if the two networks learn each= other's prefixes.
>
> 2. A new method of connecting the moving network directly to the RSU >=C2=A0 =C2=A0 =C2=A0infra-node network may lead to modifying the addres= sing architecture
>=C2=A0 =C2=A0 =C2=A0in the moving network.=C2=A0 This can become a prob= lem to the use of
>=C2=A0 =C2=A0 =C2=A0Mobile IP, because Mobile IP relies on the addressi= ng architecture
>=C2=A0 =C2=A0 =C2=A0controlled by the Home Agent.=C2=A0 This problem sh= ould be solved as well.
>
>
> In section 11 Security Considerations:
> > 11.=C2=A0 Security Considerations
> >
> >=C2=A0 =C2=A0 The security is very important in vehicular networks= for V2I
> >=C2=A0 =C2=A0 networking.=C2=A0 Only valid vehicles should be allo= wed to use V2I
> >=C2=A0 =C2=A0 networking in vehicular networks.=C2=A0 VIN and a us= er certificate can be
> >=C2=A0 =C2=A0 used to authenticate a vehicle and the user.
> >
> >=C2=A0 =C2=A0 This document shares all the security issues of the = neighbor
> >=C2=A0 =C2=A0 discovery protocol.=C2=A0 This document can get bene= fits from secure
> >=C2=A0 =C2=A0 neighbor discovery (SEND) [RFC3971]
>
> Recent works in security for vehicular networks mention two additional=
> things that are worth considering:
>
> 1. the use of TLS certificates for vehicle communications
>=C2=A0 =C2=A0 =C2=A0draft-lonc-tls-certieee1609-01
>
> 2. privacy considerations: a new ETSI activity may consider privacy >=C2=A0 =C2=A0 =C2=A0aspects of identifier generation in vehicular commu= nications.
>
> It is worth referring to these aspects (give references).
>
> Yours,
>
> Alex
>
>
>
> >
> > Thanks.
> >
> > Best Regards, Paul -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. Jaehoon (Paul)
> > Jeong, Ph.D. Assistant Professor Department of Software Sungkyunk= wan
> > University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com
> > <mailto:jaehoon.paul@gmail.com>, pauljeong@skku.edu
> > <mailto:pauljeong@skku.edu> Personal Homepage:
> > http://iotlab.skku.edu/people-jaehoon-jeo= ng.php
> > <http://cpslab.skku.edu/people-jaehoon-j= eong.php>
> >
> >
> > _______________________________________________ its mailing list<= br> > > its@ietf.org https://www.ietf.org/mailman/listinfo/its
> >
>





<= /div>--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Ass= istant Professor
Department of Software
Sungkyunkwan University
Of= fice: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.= skku.edu/people-jaehoon-jeong.php

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its


--047d7bf0c5600faca7052f8602df-- From nobody Sun Apr 3 11:46:18 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40EA012D1A7 for ; Sun, 3 Apr 2016 11:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rU5a3xmoLmS for ; Sun, 3 Apr 2016 11:46:15 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id A019812D177 for ; Sun, 3 Apr 2016 11:46:15 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 63D34F2402A for ; Sun, 3 Apr 2016 14:46:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 1kgTCAfndAAH for ; Sun, 3 Apr 2016 14:31:52 -0400 (EDT) Received: from dhcp-b4d9.meeting.ietf.org (dhcp-b4d9.meeting.ietf.org [31.133.180.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E8AC5F24062 for ; Sun, 3 Apr 2016 14:46:13 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_015ADF2D-42D5-4274-AFD1-FA0B71FC12E2" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Sun, 3 Apr 2016 14:46:11 -0400 References: <961B9F5E-F2CD-4293-8306-B4D6CE57058E@vigilsec.com> To: its@ietf.org In-Reply-To: <961B9F5E-F2CD-4293-8306-B4D6CE57058E@vigilsec.com> X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [its] ETSI ITS Privacy Work X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 18:46:17 -0000 --Apple-Mail=_015ADF2D-42D5-4274-AFD1-FA0B71FC12E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 From: Arnaud KAISER Subject: Re: [its] Updated charter (small correction) Date: February 25, 2016 at 9:04:25 AM EST To: Alexandre Petrescu , "its@ietf.org" = Dear ITSers, =20 Concerning privacy aspects in ITS, I would like to inform you that ETSI = WG5 (security and privacy WG) started a work item related to privacy. = More precisely, the WI focus on pseudonym change strategies. Pseudonyms = are used by ITS stations (vehicles, roadside units, etc.) to identify = each other without revealing their true identity. This to protect = private data and also to avoid attacks like tracking of vehicles for = example. =20 This aspect may be interesting to study in the context of IPv6 moving = networks. =20 =09 Dr. Arnaud Kaiser Research Engineer Institut de Recherche Technologique SystemX 8, Avenue de la Vauve 91120 Palaiseau =96 FRANCE =20 =20 Is this work available to the people on this list? My understanding is that this works is looking at when a vehicle would = switch from one certificate to another within the set of = somewhat-limited-lifetime certificates that have been assigned to the = vehicle. Is that right? Russ --Apple-Mail=_015ADF2D-42D5-4274-AFD1-FA0B71FC12E2 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_905EACB0-DC63-411C-B073-3F5237B18E05" --Apple-Mail=_905EACB0-DC63-411C-B073-3F5237B18E05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: Arnaud = KAISER <Arnaud.KAISER@irt-systemx.fr>
Subject: = Re: [its] Updated = charter (small correction)
Date: = February 25, 2016 at = 9:04:25 AM EST
To: = Alexandre Petrescu = <alexandre.petrescu@gmail.com>, "its@ietf.org" <its@ietf.org>

Dear ITSers,
 
Concerning privacy aspects in ITS, I would like to inform you that = ETSI WG5 (security and privacy WG) started a work item related to = privacy. More precisely, the WI focus on pseudonym change strategies. = Pseudonyms are used by ITS stations (vehicles, roadside units, etc.) to = identify each other without revealing their true identity. This to = protect private data and also to avoid attacks like tracking of vehicles = for example.
 
This aspect may be interesting to study in the context of IPv6 moving = networks.
 
Dr. Arnaud Kaiser
Research Engineer
Institut de Recherche Technologique = SystemX
8, Avenue de la Vauve
91120 Palaiseau =96 FRANCE
 
 

=


Is this work available to the people on this = list?

My understanding is that this works is = looking at when a vehicle would switch from one certificate to another = within the set of somewhat-limited-lifetime certificates that have been = assigned to the vehicle.  Is that = right?

Russ

= --Apple-Mail=_905EACB0-DC63-411C-B073-3F5237B18E05 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=image001.png Content-Type: image/png; x-unix-mode=0666; name="image001.png" Content-Id: iVBORw0KGgoAAAANSUhEUgAAALQAAABaCAMAAAAmXYzyAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAAAL1QTFRF////GhcbAJ3fxsbHU1FUpKWn4eHiAGiNw8PEjYuN8Pn9oNrz 0tLTMK/l8vHy6enpKCYpRUNG1dTV8PDxYKG4qqmq8Pb40O354+PjuLe4rK2uEKPhcG5x+Pj4u7y9 f31/MISiYmBjNzQ4m5qcnZ6fysvM2tratLS1YMLrcMjtsOH1wNrjlZaY4PP70OPqcKq/UJexjo+Q oMfVEHGUkL3NULzpgM7v4O3xkNTxhoeJIKnjsNDcQI6qgLTGQLbnI4dNngAABflJREFUeNrsmgl/ ojwQh6OQGJQFFU8qWjx72G272+PdfY/v/7F2EkJIELRaq/j+mO6REJGHycw/k+wiVFpppZVW2hnt rn95zI3qVf8Coat3F+jqxmWHd+e6d3HML7XaU9EZ77Ve7x71rn9+j7v1YmZnp9ZRma+h23uXzN+q jUIy1xRqYFa7wFwtIPV9jdm9Es5gcvStyuxscP23+sV5un9V/Vb/cEwjVISYfrgCj+VRb6iHamdU jzsemw+XV1lszPPjk7ru1V9vNYc/PZ4J9XtHYjWuGpsZqKzWLOVutNDWYvt09v6zdp07+Mi07R/Z /Y/FT+JrJiK1l3NAp5QgAzoZvs2A/vssru69bEqf1JCOHgA3G+HxoyB1Jch1onyPeqrdphLxlMw/ ttWVTK6rb0WsgKCu7OuSfP+uKF9xtoIPymrXS29SOzVZHxdp+6rk16Y/WUkkqe+OtywODDDn8Psh 9f9KRe6r7PJq899j+6k7rXBrdQ/9hvq3mzyN4KlZO/ZO1TEr0kznC6IFqI++u25VFGs5R89LVoMc OzasimbhPvdCIgzOkfdOk6Fa8Oz2iFMbezCzzx/+6NvXem5abLchZxYJydqjU0HfaNmaKk13R0cz 7ozUzhdD87JOUvMdrCqbO6Fbitun4YmgG1WFOmL+8LGppcXxfnn1ufBQqAXzh/fdbfbg5jB92QRr J03xLs6MdWZODvRgwoZH+pcZI7g2gS8YsJvDbgb1vszAxDVjkrqq+D9ptsXKKd7RmPEhQ3zOGUmx b2+uXJNYWqftNPXD3syo3Uw/KA86Ukduw3ggUUlHXaS6+pdr1kxTV/dmlv5rznZBj5IHTzehzSyw ViXDpiiDet9zpHgK1cIjC5p5rTmxprGrNehu9BWWFb2amSwClZElHjC1Rk11HhTqA86+Zlqs5kGL 5/EoscRLcGNuDSXNgLt3IKWpG0+SGceLkkD135z5d/0A+WmLeZzsgm4BTDg1rXZaPZTF1JBRLxcB R4siUz8VrW4559tuEz1EsqBbaXVUoB0JKu6wYmhT/xINWjIfSm0IFcmHNsRsOBnQvNk1jKFlWWbz g9CC+eYT1CIfrXyd7qZkOA2t2geg5ZrS+AR1lDfTfOh4NuL03wZt7oRW1sFPUc9iLciBRk6oJuw2 6HAXtLZ2f4ba0ZQiAxpCpFnRgzwNzSoNyxoOdkG/avocUR929rQbWsjwJAXN666ZkRFvedBsy66s KYefPRlboduzUH9uWqe7cUaPjN3QjLqhVaoHnj1x/XA0qY2WYkMMjuIaZAN6msjlTKZzBnQXwke8 XF+v+ff9TyrRvA7MZDveiqueKBqMeKGeQU0tFz8VehSLocM1qJkHfTQDjJZlhUrJJg4WQvVit5Ku PQ05MfByGTL9ldDG5tOQM9UYjFSdaSY3tgZa0aWd+XwhdLjJnC7fU2W+YIp2BaFevajnVF8I7Ujq qSptZhoawpVTNq24+uhqGxFDls1bJO941uY70skw4+pkqG/X5ZYwplZPWgdQL6libUD5FI1Dwzrl CdpWJw2HqJD2BTNbQpfQxYDG6JdHieuPEX4eE2qv5y5GlIyfMRvEOCBr1vLnC+jZgY9dQuEmaKP1 nKAxtnmfzscnhX7GlCwob8LzKWEI7A9+xV4QGrXYD1osESIrwtsIE+qORR/uOCk09jEJxn42NKFk bbPW3AbvcjaCKfM0Qs9rj70R79O5e1po7xdxyTyBXi19T0ATTMCRAWut4LdLVksvCg/iIkztAMaj 8FiQE0Lb8LP0XOqxpkcQ8VDAAGw+SF3kURqw7gJ6S0QWAXzI5m07gDuox/uELkr1+P9B2xi7Nh6j JQSpjcZozP5aYph7SCzqu8j1V6xNVy6M2q6LcQE8DYkHvzwfiQSbEwodH7Qb5C7AaB4E8AF74c25 qkQCWATouculaw1exOMV5RoSvQxccEUPR9BcAIvm6eBZ9zQGFwtP+8HYPaun5b9uQbza2E9iGtki piHQWUwTHtOBP2fhTRHEtHcxiRucorYorbTSSiuttKPYHwEGAIHTXywv5IdRAAAAAElFTkSuQmCC --Apple-Mail=_905EACB0-DC63-411C-B073-3F5237B18E05-- --Apple-Mail=_015ADF2D-42D5-4274-AFD1-FA0B71FC12E2-- From nobody Mon Apr 4 06:46:19 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CF912D16C for ; Mon, 4 Apr 2016 06:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzklIE7nWAEe for ; Mon, 4 Apr 2016 06:46:17 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 63DEE12D6BA for ; Mon, 4 Apr 2016 06:46:12 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id A1D81F2407D for ; Mon, 4 Apr 2016 09:46:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id eMM6LuuMKmih for ; Mon, 4 Apr 2016 09:31:46 -0400 (EDT) Received: from dhcp-9a55.meeting.ietf.org (dhcp-9a55.meeting.ietf.org [31.133.154.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id DCCDAF2403D for ; Mon, 4 Apr 2016 09:46:10 -0400 (EDT) From: Russ Housley X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_973BDCCC-A3A9-41C6-943F-1A2F8D366443"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Mon, 4 Apr 2016 09:46:08 -0400 Message-Id: To: its@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [its] minute takers and jabber scribes are needed for the ITS BoF X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 13:46:18 -0000 --Apple-Mail=_973BDCCC-A3A9-41C6-943F-1A2F8D366443 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We need minute takers and jabber scribes for the ITS BoF. If you are = not making a presentation, please volunteer. Of course, we cannot get = to the content of the session until these roles are filled. I=92ll = hoping to get volunteers on the list to avoid spending session time = recruiting people. Thanks in advance, Russ =85 speaking as one of the co-chairs --Apple-Mail=_973BDCCC-A3A9-41C6-943F-1A2F8D366443 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlcCcCAACgkQiuTu0PWcEctVQQCghxesbeYkqFeISYGsEwa1J/5P bnAAn3ikVqYivMDF7gJI150dYVvIU9RE =HKVW -----END PGP SIGNATURE----- --Apple-Mail=_973BDCCC-A3A9-41C6-943F-1A2F8D366443-- From nobody Mon Apr 4 07:34:36 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B680712D611 for ; Mon, 4 Apr 2016 07:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvlju2-EOo_Z for ; Mon, 4 Apr 2016 07:34:33 -0700 (PDT) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6882D12D6CF for ; Mon, 4 Apr 2016 07:33:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id BE75194138; Mon, 4 Apr 2016 10:33:53 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTKPST1C_ctP; Mon, 4 Apr 2016 10:33:53 -0400 (EDT) Received: from mail2.standardsmail.org (mail2.standardsmail.org [66.244.86.41]) by mail.opengeospatial.org (Postfix) with ESMTPS id 3542E94137; Mon, 4 Apr 2016 10:33:53 -0400 (EDT) Received: from mail2.standardsmail.org (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTPS id 2F5C01149A95; Mon, 4 Apr 2016 10:33:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id 219721149A94; Mon, 4 Apr 2016 10:33:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.standardsmail.org Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Eo47cxLZ70xP; Mon, 4 Apr 2016 10:33:53 -0400 (EDT) Received: from OfficeHP (c-67-176-39-130.hsd1.co.comcast.net [67.176.39.130]) by mail2.standardsmail.org (Postfix) with ESMTPSA id B2B6D1149A93; Mon, 4 Apr 2016 10:33:52 -0400 (EDT) Message-ID: <85D6CCC5E0F147A392045EC4D496E375@OfficeHP> From: "Carl Reed" To: "Russ Housley" , References: <961B9F5E-F2CD-4293-8306-B4D6CE57058E@vigilsec.com> In-Reply-To: Date: Mon, 4 Apr 2016 08:30:56 -0600 Organization: OGC MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0209_01D18E4C.4F0150C0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Archived-At: Subject: Re: [its] ETSI ITS Privacy Work X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:34:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0209_01D18E4C.4F0150C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_020A_01D18E4C.4F0150C0" ------=_NextPart_001_020A_01D18E4C.4F0150C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Russ et. al. I would check various documents crafted by the GeoPriv WG. GeoPriv began = addressing privacy and location issues in (about) 2002 and generated a = number of documents that deal with numerous aspects related to location = and privacy. https://datatracker.ietf.org/wg/geopriv/charter/ Regards Carl From: Russ Housley=20 Sent: Sunday, April 03, 2016 12:46 PM To: its@ietf.org=20 Subject: Re: [its] ETSI ITS Privacy Work From: Arnaud KAISER Subject: Re: [its] Updated charter (small correction) Date: February 25, 2016 at 9:04:25 AM EST To: Alexandre Petrescu , "its@ietf.org" = Dear ITSers, Concerning privacy aspects in ITS, I would like to inform you that = ETSI WG5 (security and privacy WG) started a work item related to = privacy. More precisely, the WI focus on pseudonym change strategies. = Pseudonyms are used by ITS stations (vehicles, roadside units, etc.) to = identify each other without revealing their true identity. This to = protect private data and also to avoid attacks like tracking of vehicles = for example. This aspect may be interesting to study in the context of IPv6 moving = networks. Dr. Arnaud Kaiser Research Engineer Institut de Recherche Technologique SystemX 8, Avenue de la Vauve 91120 Palaiseau =96 FRANCE=20 Is this work available to the people on this list? My understanding is that this works is looking at when a vehicle would = switch from one certificate to another within the set of = somewhat-limited-lifetime certificates that have been assigned to the = vehicle. Is that right? Russ -------------------------------------------------------------------------= ------- _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its ------=_NextPart_001_020A_01D18E4C.4F0150C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Russ et. al.
 
I would check various documents crafted by the GeoPriv WG. GeoPriv = began=20 addressing privacy and location issues in (about) 2002 and generated a = number of=20 documents that deal with numerous aspects related to location and = privacy. https://datatra= cker.ietf.org/wg/geopriv/charter/
 
Regards
 
Carl
 
 
Sent: Sunday, April 03, 2016 12:46 PM
Subject: Re: [its] ETSI ITS Privacy Work
 
From: Arnaud KAISER <Arnaud.KAISER@irt-systemx.fr>
Subject: = Re: [its] Updated charter (small = correction)
Date: February 25, 2016 at 9:04:25 AM=20 EST
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "its@ietf.org" <its@ietf.org>
 
Dear=20 ITSers,
 
Concerning=20 privacy aspects in ITS, I would like to inform you that ETSI WG5 = (security and=20 privacy WG) started a work item related to privacy. More precisely, = the WI=20 focus on pseudonym change strategies. Pseudonyms are used by ITS = stations=20 (vehicles, roadside units, etc.) to identify each other without = revealing=20 their true identity. This to protect private data and also to avoid = attacks=20 like tracking of vehicles for example.
 
This=20 aspect may be interesting to study in the context of IPv6 moving=20 networks.
 
Dr.=20 Arnaud Kaiser
Research=20 Engineer
Institut=20 de Recherche Technologique SystemX
8,=20 Avenue de la Vauve 91120=20 Palaiseau =96 FRANCE    
 
 
 
Is this work available to the people on this list?
 
My understanding is that this works is looking at when a vehicle = would=20 switch from one certificate to another within the set of=20 somewhat-limited-lifetime certificates that have been assigned to the=20 vehicle.  Is that right?
 
Russ
 

_______________________________________________
its mailing=20 list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
------=_NextPart_001_020A_01D18E4C.4F0150C0-- ------=_NextPart_000_0209_01D18E4C.4F0150C0 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: <35F21B8CE2A04FAC9B8F52385F66C69B@OfficeHP> iVBORw0KGgoAAAANSUhEUgAAALQAAABaCAMAAAAmXYzyAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAAAL1QTFRF////GhcbAJ3fxsbHU1FUpKWn4eHiAGiNw8PEjYuN8Pn9oNrz 0tLTMK/l8vHy6enpKCYpRUNG1dTV8PDxYKG4qqmq8Pb40O354+PjuLe4rK2uEKPhcG5x+Pj4u7y9 f31/MISiYmBjNzQ4m5qcnZ6fysvM2tratLS1YMLrcMjtsOH1wNrjlZaY4PP70OPqcKq/UJexjo+Q oMfVEHGUkL3NULzpgM7v4O3xkNTxhoeJIKnjsNDcQI6qgLTGQLbnI4dNngAABflJREFUeNrsmgl/ ojwQh6OQGJQFFU8qWjx72G272+PdfY/v/7F2EkJIELRaq/j+mO6REJGHycw/k+wiVFpppZVW2hnt rn95zI3qVf8Coat3F+jqxmWHd+e6d3HML7XaU9EZ77Ve7x71rn9+j7v1YmZnp9ZRma+h23uXzN+q jUIy1xRqYFa7wFwtIPV9jdm9Es5gcvStyuxscP23+sV5un9V/Vb/cEwjVISYfrgCj+VRb6iHamdU jzsemw+XV1lszPPjk7ru1V9vNYc/PZ4J9XtHYjWuGpsZqKzWLOVutNDWYvt09v6zdp07+Mi07R/Z /Y/FT+JrJiK1l3NAp5QgAzoZvs2A/vssru69bEqf1JCOHgA3G+HxoyB1Jch1onyPeqrdphLxlMw/ ttWVTK6rb0WsgKCu7OuSfP+uKF9xtoIPymrXS29SOzVZHxdp+6rk16Y/WUkkqe+OtywODDDn8Psh 9f9KRe6r7PJq899j+6k7rXBrdQ/9hvq3mzyN4KlZO/ZO1TEr0kznC6IFqI++u25VFGs5R89LVoMc OzasimbhPvdCIgzOkfdOk6Fa8Oz2iFMbezCzzx/+6NvXem5abLchZxYJydqjU0HfaNmaKk13R0cz 7ozUzhdD87JOUvMdrCqbO6Fbitun4YmgG1WFOmL+8LGppcXxfnn1ufBQqAXzh/fdbfbg5jB92QRr J03xLs6MdWZODvRgwoZH+pcZI7g2gS8YsJvDbgb1vszAxDVjkrqq+D9ptsXKKd7RmPEhQ3zOGUmx b2+uXJNYWqftNPXD3syo3Uw/KA86Ukduw3ggUUlHXaS6+pdr1kxTV/dmlv5rznZBj5IHTzehzSyw ViXDpiiDet9zpHgK1cIjC5p5rTmxprGrNehu9BWWFb2amSwClZElHjC1Rk11HhTqA86+Zlqs5kGL 5/EoscRLcGNuDSXNgLt3IKWpG0+SGceLkkD135z5d/0A+WmLeZzsgm4BTDg1rXZaPZTF1JBRLxcB R4siUz8VrW4559tuEz1EsqBbaXVUoB0JKu6wYmhT/xINWjIfSm0IFcmHNsRsOBnQvNk1jKFlWWbz g9CC+eYT1CIfrXyd7qZkOA2t2geg5ZrS+AR1lDfTfOh4NuL03wZt7oRW1sFPUc9iLciBRk6oJuw2 6HAXtLZ2f4ba0ZQiAxpCpFnRgzwNzSoNyxoOdkG/avocUR929rQbWsjwJAXN666ZkRFvedBsy66s KYefPRlboduzUH9uWqe7cUaPjN3QjLqhVaoHnj1x/XA0qY2WYkMMjuIaZAN6msjlTKZzBnQXwke8 XF+v+ff9TyrRvA7MZDveiqueKBqMeKGeQU0tFz8VehSLocM1qJkHfTQDjJZlhUrJJg4WQvVit5Ku PQ05MfByGTL9ldDG5tOQM9UYjFSdaSY3tgZa0aWd+XwhdLjJnC7fU2W+YIp2BaFevajnVF8I7Ujq qSptZhoawpVTNq24+uhqGxFDls1bJO941uY70skw4+pkqG/X5ZYwplZPWgdQL6libUD5FI1Dwzrl CdpWJw2HqJD2BTNbQpfQxYDG6JdHieuPEX4eE2qv5y5GlIyfMRvEOCBr1vLnC+jZgY9dQuEmaKP1 nKAxtnmfzscnhX7GlCwob8LzKWEI7A9+xV4QGrXYD1osESIrwtsIE+qORR/uOCk09jEJxn42NKFk bbPW3AbvcjaCKfM0Qs9rj70R79O5e1po7xdxyTyBXi19T0ATTMCRAWut4LdLVksvCg/iIkztAMaj 8FiQE0Lb8LP0XOqxpkcQ8VDAAGw+SF3kURqw7gJ6S0QWAXzI5m07gDuox/uELkr1+P9B2xi7Nh6j JQSpjcZozP5aYph7SCzqu8j1V6xNVy6M2q6LcQE8DYkHvzwfiQSbEwodH7Qb5C7AaB4E8AF74c25 qkQCWATouculaw1exOMV5RoSvQxccEUPR9BcAIvm6eBZ9zQGFwtP+8HYPaun5b9uQbza2E9iGtki piHQWUwTHtOBP2fhTRHEtHcxiRucorYorbTSSiuttKPYHwEGAIHTXywv5IdRAAAAAElFTkSuQmCC ------=_NextPart_000_0209_01D18E4C.4F0150C0-- From nobody Mon Apr 4 07:37:03 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C0D12D573 for ; Mon, 4 Apr 2016 07:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.889 X-Spam-Level: X-Spam-Status: No, score=-101.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhuTBfSa-x78 for ; Mon, 4 Apr 2016 07:37:00 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 00B3112D582 for ; Mon, 4 Apr 2016 07:36:54 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 8FAF8F2407D; Mon, 4 Apr 2016 10:36:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id acorflyI0ASk; Mon, 4 Apr 2016 10:22:27 -0400 (EDT) Received: from dhcp-9a55.meeting.ietf.org (dhcp-9a55.meeting.ietf.org [31.133.154.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E4AAAF2403D; Mon, 4 Apr 2016 10:36:51 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_E703CC30-97B4-4A16-924C-06238A3AF786" From: Russ Housley X-Priority: 3 In-Reply-To: <85D6CCC5E0F147A392045EC4D496E375@OfficeHP> Date: Mon, 4 Apr 2016 10:36:49 -0400 Message-Id: References: <961B9F5E-F2CD-4293-8306-B4D6CE57058E@vigilsec.com> <85D6CCC5E0F147A392045EC4D496E375@OfficeHP> To: Carl Reed X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: its@ietf.org Subject: Re: [its] ETSI ITS Privacy Work X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:37:02 -0000 --Apple-Mail=_E703CC30-97B4-4A16-924C-06238A3AF786 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Carl: I am very aware of the GeoPriv WG output. Maybe other are not, so thank = for telling everyone about it. Does the ETSI ITS Privacy work gave any dependency on the GeoPriv WG = output? Russ On Apr 4, 2016, at 10:30 AM, Carl Reed wrote: > Russ et. al. > =20 > I would check various documents crafted by the GeoPriv WG. GeoPriv = began addressing privacy and location issues in (about) 2002 and = generated a number of documents that deal with numerous aspects related = to location and privacy. = https://datatracker.ietf.org/wg/geopriv/charter/ > =20 > Regards > =20 > Carl > =20 > =20 > From: Russ Housley > Sent: Sunday, April 03, 2016 12:46 PM > To: its@ietf.org > Subject: Re: [its] ETSI ITS Privacy Work > =20 > From: Arnaud KAISER > Subject: Re: [its] Updated charter (small correction) > Date: February 25, 2016 at 9:04:25 AM EST > To: Alexandre Petrescu , "its@ietf.org" = > =20 > Dear ITSers, > =20 > Concerning privacy aspects in ITS, I would like to inform you that = ETSI WG5 (security and privacy WG) started a work item related to = privacy. More precisely, the WI focus on pseudonym change strategies. = Pseudonyms are used by ITS stations (vehicles, roadside units, etc.) to = identify each other without revealing their true identity. This to = protect private data and also to avoid attacks like tracking of vehicles = for example. > =20 > This aspect may be interesting to study in the context of IPv6 moving = networks. > =20 > > Dr. Arnaud Kaiser > Research Engineer > Institut de Recherche Technologique SystemX > 8, Avenue de la Vauve > 91120 Palaiseau =96 FRANCE > =20 > =20 > =20 > =20 > =20 > Is this work available to the people on this list? > =20 > My understanding is that this works is looking at when a vehicle would = switch from one certificate to another within the set of = somewhat-limited-lifetime certificates that have been assigned to the = vehicle. Is that right? > =20 > Russ > =20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_E703CC30-97B4-4A16-924C-06238A3AF786 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Carl:

I am very aware of the = GeoPriv WG output.  Maybe other are not, so thank for telling = everyone about it.

Does the ETSI ITS Privacy = work gave any dependency on the GeoPriv WG = output?

Russ


<= div>
On Apr 4, 2016, at 10:30 AM, Carl Reed <creed@opengeospatial.org> = wrote:

Russ et. al.
 
I would check various documents crafted by the GeoPriv WG. GeoPriv = began=20 addressing privacy and location issues in (about) 2002 and generated a = number of=20 documents that deal with numerous aspects related to location and = privacy. https://datatrac= ker.ietf.org/wg/geopriv/charter/
 
Regards
 
Carl
 
 
Sent: Sunday, April 03, 2016 12:46 PM
Subject: Re: [its] ETSI ITS Privacy Work
 
From: Arnaud KAISER <Arnaud.KAISER@irt-systemx.fr>
Subject: Re: [its] Updated charter (small=20 correction)
Date: February 25, 2016 at 9:04:25 AM=20 EST
 
Dear=20 ITSers,
 
Concerning=20 privacy aspects in ITS, I would like to inform you that ETSI WG5 = (security and=20 privacy WG) started a work item related to privacy. More precisely, = the WI=20 focus on pseudonym change strategies. Pseudonyms are used by ITS = stations=20 (vehicles, roadside units, etc.) to identify each other without = revealing=20 their true identity. This to protect private data and also to avoid = attacks=20 like tracking of vehicles for example.
 
This=20 aspect may be interesting to study in the context of IPv6 moving=20 networks.
 
<image001.png>
Dr.=20 Arnaud Kaiser
Research=20= Engineer
Institut=20= de Recherche Technologique SystemX
8,=20 Avenue de la Vauve
91120=20 Palaiseau =96 FRANCE
 
 
 
 
 
Is this work available to the people on this list?
 
My understanding is that this works is looking at when a vehicle = would=20 switch from one certificate to another within the set of=20 somewhat-limited-lifetime certificates that have been assigned to the=20 vehicle.  Is that right?
 
Russ
 

_______________________________________________
its mailing=20 list
its@ietf.org
https://www.ietf.org/mail= man/listinfo/its

= --Apple-Mail=_E703CC30-97B4-4A16-924C-06238A3AF786-- From nobody Mon Apr 4 07:41:46 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B6512D762 for ; Mon, 4 Apr 2016 07:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=securityinnovation.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fqj5WNv9T4gT for ; Mon, 4 Apr 2016 07:41:42 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E6C12D75F for ; Mon, 4 Apr 2016 07:41:39 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id w85so38352047oiw.0 for ; Mon, 04 Apr 2016 07:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=3uABYC07wjCAyObi4V4JUnWszmi7/H6U+vnbR7PMDak=; b=cjvLz31mUyosCQKezPvx1ZdlUbwWrphTpZcQDP+d+fgIiggsGDAHdSaTmd2HJ/dM2Q KVJ16o8V3RJngjtYppFnbBC4Yflug/oC8/PTqKSThajlEDEtKrIiAkhLRK66r/N6ZHzm /QnABq3H0xF9i9iqBP0vWjGegc0UvEv9OnhFM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3uABYC07wjCAyObi4V4JUnWszmi7/H6U+vnbR7PMDak=; b=CdsEPKd2X9fEnkTG5ncC96CPEodR6SOhcYpegbTsXKdNg8N/x9wIOlk+Vmcgj3RwZL fFG3vVuxUq6sriiewdqRAKPP5eaBRkyURppfESGXZZ2C+kOFCGni476va6SYF/DI06vF oVJtvxSgE5jhWhFp6LtoZYP4Zt3siY97VMQvFAA5jolG0taG8seQFS081GXGrOjlav1L qop3fG9+I80xx2cAp8sRQEQUSG2pmIDpXSgSkuQY3pF+cpuJ7GmGXLLOVddeIzGi1F// RDWSLEkas5TOBgV9/OfWPvpGelpHArHQKMN0KV0s3v6MrBuzOgXKuTQsamAw+fBkE9rR dKxQ== X-Gm-Message-State: AD7BkJLiUq/KhRrShps/De7TtwXoyvh7pXZfydyiFKrZSw3UX9DV5i+8i81R+1osTqCCyfBtH38z241rzGLAf4rs MIME-Version: 1.0 X-Received: by 10.202.91.196 with SMTP id p187mr10300960oib.39.1459780893088; Mon, 04 Apr 2016 07:41:33 -0700 (PDT) Received: by 10.202.84.84 with HTTP; Mon, 4 Apr 2016 07:41:32 -0700 (PDT) In-Reply-To: References: <961B9F5E-F2CD-4293-8306-B4D6CE57058E@vigilsec.com> Date: Mon, 4 Apr 2016 10:41:32 -0400 Message-ID: From: William Whyte To: Russ Housley Content-Type: multipart/related; boundary=001a113d467095b22d052fa9b918 Archived-At: Cc: its@ietf.org Subject: Re: [its] ETSI ITS Privacy Work X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:41:46 -0000 --001a113d467095b22d052fa9b918 Content-Type: multipart/alternative; boundary=001a113d467095b22a052fa9b917 --001a113d467095b22a052fa9b917 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Russ, > Is this work available to the people on this list? To access ETSI working documents or participate in ETSI mailing lists you need to be an ETSI member or sponsored by an ETSI member. However, the ETSI ITS standards are free once issued. > My understanding is that this works is looking at when a vehicle would switch from one certificate to another within the set of somewhat-limited-lifetime certificates that have been assigned to the vehicle. Is that right? Yes, that's right, though the scope could expand. Cheers, William On Sun, Apr 3, 2016 at 2:46 PM, Russ Housley wrote: > *From: *Arnaud KAISER >> *Subject: **Re: [its] Updated charter (small correction)* >> *Date: *February 25, 2016 at 9:04:25 AM EST >> *To: *Alexandre Petrescu , "its@ietf.org" = < >> its@ietf.org> >> >> Dear ITSers, >> >> Concerning privacy aspects in ITS, I would like to inform you that ETSI >> WG5 (security and privacy WG) started a work item related to privacy. Mo= re >> precisely, the WI focus on pseudonym change strategies. Pseudonyms are u= sed >> by ITS stations (vehicles, roadside units, etc.) to identify each other >> without revealing their true identity. This to protect private data and >> also to avoid attacks like tracking of vehicles for example. >> >> This aspect may be interesting to study in the context of IPv6 moving >> networks. >> >> *Dr. Arnaud Kaiser* >> Research Engineer >> Institut de Recherche Technologique SystemX >> 8, Avenue de la Vauve >> 91120 Palaiseau =E2=80=93 FRANCE >> >> >> >> > > Is this work available to the people on this list? > > My understanding is that this works is looking at when a vehicle would > switch from one certificate to another within the set of > somewhat-limited-lifetime certificates that have been assigned to the > vehicle. Is that right? > > Russ > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --001a113d467095b22a052fa9b917 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Russ,

> Is this work available to the people on this list?

To access E= TSI working documents or participate in ETSI mailing lists you need to be a= n ETSI member or sponsored by an ETSI member. However, the ETSI ITS standar= ds are free once issued.

>=C2=A0My = understanding is that this works is looking at when a vehicle would switch = from one certificate to another within the set of somewhat-limited-lifetime= certificates that have been assigned to the vehicle.=C2=A0 Is that right?<= /span>

Yes, that's right, though the sco= pe could expand.

Cheers,

= William




On Sun, Apr 3, 2016 at 2:46= PM, Russ Housley <housley@vigilsec.com> wrote:
=
From: Arnaud KAISER &l= t;Arnaud.= KAISER@irt-systemx.fr>
Subject: Re: [its] Updated charter (small correct= ion)
Date: February 25, 2016 at 9:04:25 AM EST
= To: Alexandre Pe= trescu <alexandre.petrescu@gmail.com>, "its@ietf.org" <its@ietf.org>

Dear ITSers,
=C2=A0
Co= ncerning privacy aspects in ITS, I would like to inform you that ETSI WG5 (= security and privacy WG) started a work item related to privacy. More preci= sely, the WI focus on pseudonym change strategies. Pseudonyms are used by I= TS stations (vehicles, roadside units, etc.) to identify each other without= revealing their true identity. This to protect private data and also to av= oid attacks like tracking of vehicles for example.
=C2=A0
= This aspect may be interesting to study in the context of IPv6 movi= ng networks.
=C2= =A0
Dr. Arnaud Kaiser
Research Engineer
Institut de Recherche Technol= ogique SystemX
8, Avenue de la Vauve
91120 Palaiseau =E2=80=93 FRANCE
=C2=A0
=C2=A0



Is this work available to the peop= le on this list?

My understanding is that this wor= ks is looking at when a vehicle would switch from one certificate to anothe= r within the set of somewhat-limited-lifetime certificates that have been a= ssigned to the vehicle.=C2=A0 Is that right?

Russ

<= /span>

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its


--001a113d467095b22a052fa9b917-- --001a113d467095b22d052fa9b918 Content-Type: image/png; x-unix-mode=0666; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 2c927408eace7aea_0.0.1.1 iVBORw0KGgoAAAANSUhEUgAAALQAAABaCAMAAAAmXYzyAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAAAL1QTFRF////GhcbAJ3fxsbHU1FUpKWn4eHiAGiNw8PEjYuN8Pn9oNrz 0tLTMK/l8vHy6enpKCYpRUNG1dTV8PDxYKG4qqmq8Pb40O354+PjuLe4rK2uEKPhcG5x+Pj4u7y9 f31/MISiYmBjNzQ4m5qcnZ6fysvM2tratLS1YMLrcMjtsOH1wNrjlZaY4PP70OPqcKq/UJexjo+Q oMfVEHGUkL3NULzpgM7v4O3xkNTxhoeJIKnjsNDcQI6qgLTGQLbnI4dNngAABflJREFUeNrsmgl/ ojwQh6OQGJQFFU8qWjx72G272+PdfY/v/7F2EkJIELRaq/j+mO6REJGHycw/k+wiVFpppZVW2hnt rn95zI3qVf8Coat3F+jqxmWHd+e6d3HML7XaU9EZ77Ve7x71rn9+j7v1YmZnp9ZRma+h23uXzN+q jUIy1xRqYFa7wFwtIPV9jdm9Es5gcvStyuxscP23+sV5un9V/Vb/cEwjVISYfrgCj+VRb6iHamdU jzsemw+XV1lszPPjk7ru1V9vNYc/PZ4J9XtHYjWuGpsZqKzWLOVutNDWYvt09v6zdp07+Mi07R/Z /Y/FT+JrJiK1l3NAp5QgAzoZvs2A/vssru69bEqf1JCOHgA3G+HxoyB1Jch1onyPeqrdphLxlMw/ ttWVTK6rb0WsgKCu7OuSfP+uKF9xtoIPymrXS29SOzVZHxdp+6rk16Y/WUkkqe+OtywODDDn8Psh 9f9KRe6r7PJq899j+6k7rXBrdQ/9hvq3mzyN4KlZO/ZO1TEr0kznC6IFqI++u25VFGs5R89LVoMc OzasimbhPvdCIgzOkfdOk6Fa8Oz2iFMbezCzzx/+6NvXem5abLchZxYJydqjU0HfaNmaKk13R0cz 7ozUzhdD87JOUvMdrCqbO6Fbitun4YmgG1WFOmL+8LGppcXxfnn1ufBQqAXzh/fdbfbg5jB92QRr J03xLs6MdWZODvRgwoZH+pcZI7g2gS8YsJvDbgb1vszAxDVjkrqq+D9ptsXKKd7RmPEhQ3zOGUmx b2+uXJNYWqftNPXD3syo3Uw/KA86Ukduw3ggUUlHXaS6+pdr1kxTV/dmlv5rznZBj5IHTzehzSyw ViXDpiiDet9zpHgK1cIjC5p5rTmxprGrNehu9BWWFb2amSwClZElHjC1Rk11HhTqA86+Zlqs5kGL 5/EoscRLcGNuDSXNgLt3IKWpG0+SGceLkkD135z5d/0A+WmLeZzsgm4BTDg1rXZaPZTF1JBRLxcB R4siUz8VrW4559tuEz1EsqBbaXVUoB0JKu6wYmhT/xINWjIfSm0IFcmHNsRsOBnQvNk1jKFlWWbz g9CC+eYT1CIfrXyd7qZkOA2t2geg5ZrS+AR1lDfTfOh4NuL03wZt7oRW1sFPUc9iLciBRk6oJuw2 6HAXtLZ2f4ba0ZQiAxpCpFnRgzwNzSoNyxoOdkG/avocUR929rQbWsjwJAXN666ZkRFvedBsy66s KYefPRlboduzUH9uWqe7cUaPjN3QjLqhVaoHnj1x/XA0qY2WYkMMjuIaZAN6msjlTKZzBnQXwke8 XF+v+ff9TyrRvA7MZDveiqueKBqMeKGeQU0tFz8VehSLocM1qJkHfTQDjJZlhUrJJg4WQvVit5Ku PQ05MfByGTL9ldDG5tOQM9UYjFSdaSY3tgZa0aWd+XwhdLjJnC7fU2W+YIp2BaFevajnVF8I7Ujq qSptZhoawpVTNq24+uhqGxFDls1bJO941uY70skw4+pkqG/X5ZYwplZPWgdQL6libUD5FI1Dwzrl CdpWJw2HqJD2BTNbQpfQxYDG6JdHieuPEX4eE2qv5y5GlIyfMRvEOCBr1vLnC+jZgY9dQuEmaKP1 nKAxtnmfzscnhX7GlCwob8LzKWEI7A9+xV4QGrXYD1osESIrwtsIE+qORR/uOCk09jEJxn42NKFk bbPW3AbvcjaCKfM0Qs9rj70R79O5e1po7xdxyTyBXi19T0ATTMCRAWut4LdLVksvCg/iIkztAMaj 8FiQE0Lb8LP0XOqxpkcQ8VDAAGw+SF3kURqw7gJ6S0QWAXzI5m07gDuox/uELkr1+P9B2xi7Nh6j JQSpjcZozP5aYph7SCzqu8j1V6xNVy6M2q6LcQE8DYkHvzwfiQSbEwodH7Qb5C7AaB4E8AF74c25 qkQCWATouculaw1exOMV5RoSvQxccEUPR9BcAIvm6eBZ9zQGFwtP+8HYPaun5b9uQbza2E9iGtki piHQWUwTHtOBP2fhTRHEtHcxiRucorYorbTSSiuttKPYHwEGAIHTXywv5IdRAAAAAElFTkSuQmCC --001a113d467095b22d052fa9b918-- From nobody Mon Apr 4 15:09:00 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1337212D711 for ; Mon, 4 Apr 2016 15:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTI-X1ITQEsF for ; Mon, 4 Apr 2016 15:08:56 -0700 (PDT) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE0E12D190 for ; Mon, 4 Apr 2016 15:08:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 48B1A94138; Mon, 4 Apr 2016 18:08:55 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5uYhWP5ygag; Mon, 4 Apr 2016 18:08:54 -0400 (EDT) Received: from mail2.standardsmail.org (mail2.standardsmail.org [66.244.86.41]) by mail.opengeospatial.org (Postfix) with ESMTPS id 786BA94137; Mon, 4 Apr 2016 18:08:54 -0400 (EDT) Received: from mail2.standardsmail.org (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTPS id 71EAF1149E8F; Mon, 4 Apr 2016 18:08:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id 637EB1149E8D; Mon, 4 Apr 2016 18:08:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.standardsmail.org Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2Xuj_mgg5dVQ; Mon, 4 Apr 2016 18:08:54 -0400 (EDT) Received: from OfficeHP (c-67-176-39-130.hsd1.co.comcast.net [67.176.39.130]) by mail2.standardsmail.org (Postfix) with ESMTPSA id 0AA8E1149E54; Mon, 4 Apr 2016 18:08:53 -0400 (EDT) Message-ID: <531EFCC0B00A4D0282A83AD4E3357B62@OfficeHP> From: "Carl Reed" To: "Russ Housley" References: <961B9F5E-F2CD-4293-8306-B4D6CE57058E@vigilsec.com> <85D6CCC5E0F147A392045EC4D496E375@OfficeHP> In-Reply-To: Date: Mon, 4 Apr 2016 16:08:45 -0600 Organization: OGC MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F0_01D18E8C.4406FF90" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Archived-At: Cc: its@ietf.org Subject: Re: [its] ETSI ITS Privacy Work X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:08:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00F0_01D18E8C.4406FF90 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Russ - I will need to check. Regards Carl From: Russ Housley=20 Sent: Monday, April 04, 2016 8:36 AM To: Carl Reed=20 Cc: its@ietf.org=20 Subject: Re: [its] ETSI ITS Privacy Work Carl:=20 I am very aware of the GeoPriv WG output. Maybe other are not, so thank = for telling everyone about it. Does the ETSI ITS Privacy work gave any dependency on the GeoPriv WG = output? Russ On Apr 4, 2016, at 10:30 AM, Carl Reed wrote: Russ et. al. I would check various documents crafted by the GeoPriv WG. GeoPriv = began addressing privacy and location issues in (about) 2002 and = generated a number of documents that deal with numerous aspects related = to location and privacy. = https://datatracker.ietf.org/wg/geopriv/charter/ Regards Carl From: Russ Housley=20 Sent: Sunday, April 03, 2016 12:46 PM To: its@ietf.org=20 Subject: Re: [its] ETSI ITS Privacy Work From: Arnaud KAISER Subject: Re: [its] Updated charter (small correction) Date: February 25, 2016 at 9:04:25 AM EST To: Alexandre Petrescu , = "its@ietf.org" Dear ITSers, Concerning privacy aspects in ITS, I would like to inform you that = ETSI WG5 (security and privacy WG) started a work item related to = privacy. More precisely, the WI focus on pseudonym change strategies. = Pseudonyms are used by ITS stations (vehicles, roadside units, etc.) to = identify each other without revealing their true identity. This to = protect private data and also to avoid attacks like tracking of vehicles = for example. This aspect may be interesting to study in the context of IPv6 = moving networks. Dr. Arnaud Kaiser Research Engineer Institut de Recherche Technologique SystemX 8, Avenue de la Vauve 91120 Palaiseau =96 FRANCE=20 Is this work available to the people on this list? My understanding is that this works is looking at when a vehicle would = switch from one certificate to another within the set of = somewhat-limited-lifetime certificates that have been assigned to the = vehicle. Is that right? Russ -------------------------------------------------------------------------= ----- _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_00F0_01D18E8C.4406FF90 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Russ -
 
I will need to check.
 
Regards

Carl
 
 
Sent: Monday, April 04, 2016 8:36 AM
Subject: Re: [its] ETSI ITS Privacy Work
 
Carl:=20
 
I am very aware of the GeoPriv WG output.  Maybe other are = not, so=20 thank for telling everyone about it.
 
Does the ETSI ITS Privacy work gave any dependency on the GeoPriv = WG=20 output?
 
Russ
 
 
 
On Apr 4, 2016, at 10:30 AM, Carl Reed <creed@opengeospatial.org>= =20 wrote:

Russ et. al.
 
I would check various documents crafted by the GeoPriv WG. = GeoPriv began=20 addressing privacy and location issues in (about) 2002 and generated a = number=20 of documents that deal with numerous aspects related to location and = privacy.=20 https://datatra= cker.ietf.org/wg/geopriv/charter/
 
Regards
 
Carl
 
 
Sent: Sunday, April 03, 2016 12:46 PM
Subject: Re: [its] ETSI ITS Privacy Work
 
From: Arnaud KAISER <Arnaud.KAISER@irt-systemx.fr>
Subject: = Re: [its] Updated charter = (small=20 correction)
Date: = February 25, 2016 at 9:04:25 AM=20 EST
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "its@ietf.org" = <its@ietf.org>
 
Dear=20 ITSers,
 
Concerning=20 privacy aspects in ITS, I would like to inform you that ETSI WG5 = (security=20 and privacy WG) started a work item related to privacy. More = precisely, the=20 WI focus on pseudonym change strategies. Pseudonyms are used by ITS = stations=20 (vehicles, roadside units, etc.) to identify each other without = revealing=20 their true identity. This to protect private data and also to avoid = attacks=20 like tracking of vehicles for example.
 
This=20 aspect may be interesting to study in the context of IPv6 moving=20 networks.
 
<image001.png> Dr.=20 Arnaud Kaiser
Research=20 Engineer
Institut=20 de Recherche Technologique SystemX
8,=20 Avenue de la Vauve
91120=20 Palaiseau =96 FRANCE
 
 
 
 
 
Is this work available to the people on this list?
 
My understanding is that this works is looking at when a vehicle = would=20 switch from one certificate to another within the set of=20 somewhat-limited-lifetime certificates that have been assigned to the=20 vehicle.  Is that right?
 
Russ
 
 
_______________________________________________
its mailing = list
its@ietf.org
https://www.ietf.org/mai= lman/listinfo/its
 
------=_NextPart_000_00F0_01D18E8C.4406FF90-- From nobody Mon Apr 4 18:55:42 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C63512D5A5 for ; Mon, 4 Apr 2016 18:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWtPq-yXBjY0 for ; Mon, 4 Apr 2016 18:55:36 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4C812D580 for ; Mon, 4 Apr 2016 18:55:36 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id d68so137890230ywe.1 for ; Mon, 04 Apr 2016 18:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9YVV50CUp/DXBFvufP5SWdk64YA9W8J9aqfWPZNVjQE=; b=pyx4iOdQCeGr9rhKNMA0/2HtaLelhOpmgdotGklhWCvdf8XZ6zpWAE/a1xLkt5HQWW +zCIO6FjA7U2H6nXh/VuUGCVoJ5hS37MXdfdK53ocMqYC2wDLIvMvyZxWyLmk6P4SBJ3 Lx4gbIqdG+JL0mnJYajnSDRGVsUA2qk6+6cBK/496+i2FyRnb1dXiac2iwdloNI9jof7 7J5fPfpTQx6gOunCeREqWeRK7F35scJ+KUMhGS23+8Cuhql5PVqVTx32Eqki/g00LPe4 Py6NSSarUwzPqHH57hhdwE4RDjXM6LX1a9dxxGNBo8qk4vimDBUrHGhFe5S/7Mc+VXO1 /RQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9YVV50CUp/DXBFvufP5SWdk64YA9W8J9aqfWPZNVjQE=; b=QEqiueBFunnUfNVarLVq264ximeK4M/Ca4LTwn7W/wkfOeDzoBC+RWjVPERvRFBtnr RKYeC9z26YOMK/XgQCUGQtdCsmGnbU+Hg5vSpCoLKYPNzkVJBqgdCnQOlevbPALpFPoh N30ZQGYulM/kJgmenKuSMmqZ1Wpc14m911OGCtzGkFgGfdBSQh/MtF1B1k9e2mS1XuKH 9EHfSph5ecYkrtBMq2ceeB2fXNRRc3lv6HqDy6uGfHV0nIxqA1SRk9nrWwXLhvs/1fgq 89FRwFucIMYML6buovmWE/xkduq90B9vMzFZlEYH77fSDpn8s6tHB1laRRVJTI7XTZAM ueaw== X-Gm-Message-State: AD7BkJJvwm9XJjnm1UZkclqYF/nLArasIRPJKUaU4GFZM8jngrz+U/KgXAytOjOsM0bnWQ1i5Uu7oFFt9uFYHw== X-Received: by 10.37.50.149 with SMTP id y143mr1554619yby.10.1459821335626; Mon, 04 Apr 2016 18:55:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.4.22 with HTTP; Mon, 4 Apr 2016 18:55:06 -0700 (PDT) In-Reply-To: References: <56C465DB.8060305@gmail.com> From: "Mr. Jaehoon Paul Jeong" Date: Mon, 4 Apr 2016 22:55:06 -0300 Message-ID: To: Nabil Benamar Content-Type: multipart/alternative; boundary=001a1146e086254cd2052fb32491 Archived-At: Cc: Thierry Ernst , "its@ietf.org" , knut.evensen@q-free.com, "Dr. Hans-Joachim Fischer" , Alexandre Petrescu , Richard Roy Subject: Re: [its] Comments for a New Draft of Problem Statement for V2I Networking X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 01:55:40 -0000 --001a1146e086254cd2052fb32491 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Nabil, Thanks for your good comments. I answers your questions and comments in lines with "=3D>" below. On Sat, Apr 2, 2016 at 5:04 PM, Nabil Benamar wrote: > Hi Jaehoon, > > Here are some comments: > > *Introduction* > > > * =E2=80=9C Recently,=E2=80=A6..=E2=80=9D This is not recent since the = works on VANETs and its > use cases have been done for a while =E2=80=A6 such as driving safety, ef= ficient > driving, and entertainment! There are a lot of journal papers tackling in > details this topic.* > > *This section can be modified as follows: * > > *Vehicular Networks have become a popular topic during the last years due > to the important applications that can be realized in such environment.* > *=3D> Will be reflected on the revision.* > > *=E2=80=9C =E2=80=A6 with a consideration of the vehicular network's char= acteristics such > as a vehicle's velocity and collision avoidance.=E2=80=9D * > *Collision avoidance is a consequence and a goal to attend and not a > characteristic of this IEEE standard.* > > *=3D> You are right. I will update it as follows: =E2=80=9C... with a con= sideration > of the vehicular network's characteristics such as a vehicle's velocity a= nd > its directed movement along a roadway.=E2=80=9D* > > > *=E2=80=9C=E2=80=A6.IPv6 [RFC2460] is suitable for vehicular networks since= the protocol > has* > > * abundant address space, autoconfiguration features, and protocol > extension ability through extension headers.=E2=80=9D* > > > *Better to mention the draft > =E2=80=98https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-03 > =E2=80=99= as a > supporting reference here.* > *=3D> Will be reflected on the revision.* > > > *=E2=80=9Cit is assumed that the prefix assignment for each subnet inside* > > * the vehicle's mobile network and the RSU's infra-node network through= * > > * a prefix delegation protocol.=E2=80=9D* > > > *Prefex delegation is only possible through DHCPv6-PD, is this what you > mean ? * > *=3D> Yes, DHCPv6-PD can be used as a solution. We may invent another one f= or vehicular networks.** Also, prefix configuration can be manually done at the manufacturing time as factory default.* > > *=E2=80=9CAlso, the DNS naming service should be supported for the* > > * DNS name resolution for a host or server in either the vehicle's* > > * mobile network or the RSU's infra-node network.=E2=80=9D* > > > *So what could be the issue here ? Is DNS an issue? DNS information are > included in RA with the flag =E2=80=9CO=E2=80=9D enabled. * > *=3D> We need to consider three issues, such as IPv6 host DNS configuration= , > DNS name resolution, and DNS name autoconfiguration. * > *The first is IPv6 host DNS configuration for Recursive DNS Server (RDNSS) > and DNS Search List (DNSSL) t**hrough RA Options (RFC 6106) and DHCP > Options (RFC 3646).* > > *The second is DNS name resolution through an appropriate RDNSS w**ithin > a vehicle=E2=80=99s moving network or an RSU=E2=80=99s fixed network. * > > *The third is DNS name autoconfiguration of vehicle and in-vehicle device= s > t**hrough DNSNA (draft-jeong-its-iot-dns-autoconf-00), mDNS (RFC 6762), > and DNS Update (RFC 2136).* > > > *=E2=80=9CThe former approach is* > > * usually used by Mobile Ad Hoc Networks (MANET) for a separate multi-* > > * link subnet.=E2=80=9D* > > > *Site local addressing is deprecated RFC 3879=E2=80=A6so no need to menti= on it in > the current draft. * > *=3D> Yes, Site-local addressing will be replaced by Unique Local IPv6 > Addresses (ULA) in RFC 4193.* > > > *=E2=80=9CDHCPv6 (or Stateless DHCPv6) can be used for the IP address* > > * autoconfiguration [RFC3315][RFC3736] =E2=80=9C * > *=3D> **As an alternative protocol, DHCPv6 (or Stateless DHCPv6) can also b= e > used for the IP address **autoconfiguration [RFC3315][RFC3736].* > > *There is no more autoconfiguration when we use DHCPv6=E2=80=A6So this se= ntence > should be corrected accordingly. * > *=3D> What do you mean by "**There is no more autoconfiguration when we use > DHCPv6**"? * > *I intend that DHCPv6 can be used for an IPv6 host's address > autoconfiguration instead of RA. * > *Thanks. * > *Best Regards,* > *Paul* > > Best regards > Nabil Benamar > ------------------- > =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 > > http://nabilbenamar.ipv6-lab.net/ > > On Wed, Feb 24, 2016 at 8:57 AM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > >> Hi Richard, >> I will check the IOS standards related to ITS, which are pointed by you. >> >> I agree with you that you need to use well-known terminology for our ITS >> work. >> >> For 802.11p, as I know, both industry and academia are considering it as >> Dedicated Short-Range Communications (DSRC) for vehicular networking. >> >> Thanks. >> >> Best Regards, >> Paul >> >> >> On Thu, Feb 18, 2016 at 6:24 AM, Richard Roy >> wrote: >> >>> Alex/Paul, >>> >>> I suspect much of what you are thinking needs standardization below has >>> already been standardized. You might want to check out ISO 21217 (ITS >>> station/communication architecture), followed by ISO 21210 (IPv6 >>> networking >>> for ITS). If nothing else, we already have terms for all of the >>> configurations you describe below (see ISO 21217). It would be best to >>> stick with this now well-known terminology. >>> >>> By the way, none of this depends on 802.11 5.9GHz in the data link and >>> physical layers. I continue to wonder why 802.11p ever comes up. It >>> could >>> just as well be 5.4GHz BRAN, 2.4GHz ISM, IR, tin can and a string, or >>> whatever ... >>> >>> Cheers, >>> >>> RR >>> >>> > -----Original Message----- >>> > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] >>> > Sent: Wednesday, February 17, 2016 4:22 AM >>> > To: Mr. Jaehoon Paul Jeong >>> > Cc: its@ietf.org >>> > Subject: Re: [its] Comments for a New Draft of Problem Statement for >>> V2I >>> > Networking >>> > >>> > Hello Paul, >>> > >>> > Thanks a lot for this draft. This V2I problem statement covers many >>> > things we have discussed in Yokohama. >>> > >>> > What do the others think about this draft? >>> > >>> > I hame some comments, see below. >>> > >>> > Le 15/02/2016 17:30, Mr. Jaehoon Paul Jeong a =C3=A9crit : >>> > > Hi ITS Colleagues, >>> > > >>> > > Title: Problem Statement for Vehicle-to-Infrastructure Networking >>> > > I-D: draft-jeong-its-v2i-problem-statement-00 Link: >>> > > https://tools.ietf.org/html/draft-jeong-its-v2i-problem-statement-0= 0 >>> > > >>> > > Abstract This document specifies the problem statement for >>> > > IPv6-based vehicle- to-infrastructure networking. Dedicated >>> > > Short-Range Communications (DSRC) is standardized as IEEE 802.11p f= or >>> > > the wireless media access in vehicular networks. This document >>> > > addresses the extension of IPv6 as the network layer protocol in >>> > > vehicular networks and is focused on the networking issues in >>> > > one-hop communication between a Road-Side Unit (RSU) and vehicle. >>> > > The RSU is connected to the Internet and allows vehicles to have th= e >>> > > Internet access if connected. The major issues of including IPv6 i= n >>> > > vehicular networks are neighbor discovery protocol, stateless >>> > > address autoconfiguration, and DNS configuration for the Internet >>> > > connectivity over DSRC. Also, when the vehicle and the RSU have an >>> > > internal network, respectively, the document discusses the issues o= f >>> > > internetworking between the vehicle's internal network and the RSU'= s >>> > > internal network. >>> > > >>> > > If you have comments or questions, please let me know. >>> > >>> > You can use the documentation prefixes 2001:db8:1000::/63 (instead of >>> > real addresses like 2001:1000::/63). >>> > >>> > The term "RSU infra-node network" is something new and may need to be >>> > present in the definitions section. >>> > >>> > If I understand you correctly, the RSU infra-node network is a networ= k >>> > of IP-addressable devices which are present in the Road-Side Unit - >>> right? >>> > >>> > I am asking because I know some such RSUs on the market which contain >>> > several IP-addressable devices linked together, but we dont have a na= me >>> > for them. The "RSU infra-node network" sounds good, I think. >>> > >>> > For the term "mobile network" - we can rather use maybe >>> > "moving network". >>> > >>> > In section 5 "Internetworking between the Vehicle and RSU networks": >>> > > Problems are a prefix discovery and prefix exchange. The prefix >>> > > discovery is defined as how routers in a mobile network discover >>> > > prefixes in the mobile network. The prefix exchange is defined as >>> > > how the vehicle and the RSU exchange their prefixes with each other= . >>> > >>> > I agree with the problem of prefix exchange. >>> > >>> > For the "prefix discovery", I have some doubts. >>> > >>> > First, the routers inside the moving network can be pre-configured wi= th >>> > the prefixes inside that moving network. If so, then there can be no >>> > need for these routers to discover the prefixes inside the same movin= g >>> > network. But, of course, if they are not preconfigured then they hav= e >>> > to be discovered somehow. >>> > >>> > Second, there is a need for one router (the mobile router?) in the >>> > moving network to discover several parameters of a nearby moving >>> > network, and also the parameters of a "RSU infra-node network". Thes= e >>> > parameters, including the IP prefix of the other network, are listed = in >>> > draft-petrescu-its-problem-01 section 3.1 "Discovery Sub-Problem". I= t >>> > would be good to use same terminology for this discovery. >>> > >>> > > This section discusses IP addressing for V2I networking. There are >>> > > two policies for IPv6 addressing in vehicular networks. The one >>> > > policy is to use site-local IPv6 addresses for vehicular networks >>> > > [RFC4291]. >>> > >>> > Since the site-local IPv6 addresses (fec0::) have been deprecated, it >>> > would be appropriate to mention "Unique Local Addresses" (ULAs) which >>> > can somehow play the role that seems to be needed here. I suggest to >>> > substitute ULA for site-local addresses. >>> > >>> > > The former approach is >>> > > usually used by Mobile Ad Hoc Networks (MANET) for a separate >>> multi- >>> > > link subnet. >>> > >>> > MANET has a certain meaning at IETF: it's the WG MANET. I dont think >>> > there is any MANET draft that recommends ULAs (but maybe they recomme= nd >>> > site-locals?). Maybe ask the MANET WG what is the MANET IP Addressin= g >>> > Architecture (do they use ULAs? do they use GUA - globals?). If yes >>> > then refer to MANET WG document here. >>> > >>> > > Sections 7 ND, 8 address autoconf, 9 DNS >>> > >>> > I agree with these sections 7, 8 and 9. >>> > >>> > > 10. IP Mobility Support >>> > > >>> > > This section discusses an IP mobility support in V2I networking. >>> In >>> > > a single subnet per RSU, vehicles keep crossing the communicatio= n >>> > > coverages of adjacent RSUs. During this crossing, TCP/UDP >>> sessions >>> > > can be maintained through IP mobility support, such as Mobile IP= v6 >>> > > [RFC6275]. Since vehicles move fast along roadways, this high >>> speed >>> > > should be configured for a parameter configuration in Mobile IPv= 6. >>> > > >>> > > To support the mobility of a vehicle's mobile network, Network >>> > > Mobility (NEMO) protocol can be used [RFC3963]. Like Mobile IPv= 6, >>> > > the high speed of vehicles should be considered for a parameter >>> > > configuration in NEMO. >>> > >>> > I agree. >>> > >>> > I would like to add the following: >>> > >>> > 1. When Mobile IPv6/NEMO is used by the Mobile Router connected to >>> > the RSU infra-node a tunnel is established between the MR and its >>> > Home Agent in the TCC (Traffic Control Center). If a node inside >>> > the moving network (not the MR) needs to exchange data with a nod= e >>> > within the RSU infra-node network then that communication must >>> > go through the Home Agent. The delays on the path to the HA may = be >>> > too high for the reactivity needed between a vehicle and an RSU, = or >>> > the path can even be blocked. For this reason it is necessary to >>> > accommodate direct communications (skip the HA) between a node in >>> > the moving network and a node in the RSU infra-node network. Thi= s >>> > can be achieved only if the two networks learn each other's >>> prefixes. >>> > >>> > 2. A new method of connecting the moving network directly to the RSU >>> > infra-node network may lead to modifying the addressing >>> architecture >>> > in the moving network. This can become a problem to the use of >>> > Mobile IP, because Mobile IP relies on the addressing architectur= e >>> > controlled by the Home Agent. This problem should be solved as >>> well. >>> > >>> > >>> > In section 11 Security Considerations: >>> > > 11. Security Considerations >>> > > >>> > > The security is very important in vehicular networks for V2I >>> > > networking. Only valid vehicles should be allowed to use V2I >>> > > networking in vehicular networks. VIN and a user certificate ca= n >>> be >>> > > used to authenticate a vehicle and the user. >>> > > >>> > > This document shares all the security issues of the neighbor >>> > > discovery protocol. This document can get benefits from secure >>> > > neighbor discovery (SEND) [RFC3971] >>> > >>> > Recent works in security for vehicular networks mention two additiona= l >>> > things that are worth considering: >>> > >>> > 1. the use of TLS certificates for vehicle communications >>> > draft-lonc-tls-certieee1609-01 >>> > >>> > 2. privacy considerations: a new ETSI activity may consider privacy >>> > aspects of identifier generation in vehicular communications. >>> > >>> > It is worth referring to these aspects (give references). >>> > >>> > Yours, >>> > >>> > Alex >>> > >>> > >>> > >>> > > >>> > > Thanks. >>> > > >>> > > Best Regards, Paul -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. Jaehoon (Paul) >>> > > Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwa= n >>> > > University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>> > > , pauljeong@skku.edu >>> > > Personal Homepage: >>> > > http://iotlab.skku.edu/people-jaehoon-jeong.php >>> > > >>> > > >>> > > >>> > > _______________________________________________ its mailing list >>> > > its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> > > >>> > >>> >>> >>> >> >> >> -- >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Assistant Professor >> Department of Software >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a1146e086254cd2052fb32491 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Nabil,
Thanks for your good comments.
I answers your questions and comments in lines with "=3D&g= t;" below.

On Sat, Apr 2, 2016 at 5:04 PM, Nabil Benamar <benamar73@gmail.com> wrote:
Hi Jaehoon,

Here are some comments= :

Introduction


=C2=A0 =E2=80=9C Recently,=E2=80=A6..=E2=80=9D=C2=A0 This is not r= ecent since the works on VANETs and its use cases have been done for a whil= e =E2=80=A6 such as driving safety, efficient driving, and entertainment! T= here are a lot of journal papers tackling in details this topic.

This section can be modified as follows:=C2=A0

Vehicular Networks have become a popular topic during the last yea= rs due to the important applications that can be realized in such environme= nt.

=3D> Will be reflected on the revision.

=E2=80=9C =E2=80=A6 with a consideration of the vehicular network&= #39;s characteristics such as a vehicle's velocity and collision avoida= nce.=E2=80=9D=C2=A0

=3D> Will be reflected on the rev= ision.=C2=A0=C2=A0

=C2= =A0

=E2=80=9Cit is assumed that the prefix assignment for each subnet ins= ide

=C2=A0=C2=A0 the vehicle's mobile network and the RSU's infra= -node network through

=C2=A0=C2=A0 a prefix delegation protocol.=E2=80=9D


Prefex delegation is only possible through DHCPv6-PD, is this what yo= u mean ?

=C2=A0=C2=A0=3D> Yes, DHCPv6-PD can be use= d as a solution. We may invent another one for
=C2=A0 vehicular networks.
=C2=A0 Also, pref= ix configuration can be manually done at the manufacturing time as factory = default.=C2=A0 =C2=A0
<= div dir=3D"ltr">


=E2=80=9CAlso, the DNS naming service should be supported for the=

=C2=A0=C2=A0 DNS name resolution for a host or server in either the v= ehicle's

=C2=A0=C2=A0 mobile network or the RSU's infra-node network.=E2= =80=9D


So what could be the issue here ? Is DNS an issue? DNS information ar= e included in RA with the flag =E2=80=9CO=E2=80=9D enabled.

<= /div>

=3D> We need to consider three issues, such as IPv6= host DNS configuration, DNS name resolution, and DNS name autoconfiguratio= n.=C2=A0

The first is IPv6 host DNS configuration for Recursive D= NS Server (RDNSS) and DNS Search List (DNSSL) through RA Options (RFC 6106= ) and DHCP Options (RFC 3646).

The second is DNS name resolution through an appropri= ate RDNSS within a vehicle=E2=80=99s moving network or an RSU=E2=80=99s fi= xed network.=C2=A0

The third is DNS name autoconfiguration of vehicle and in-veh= icle devices through DNSNA (draft-jeong-its-iot-dns-autoconf-00), mDNS (RF= C 6762), and DNS Update (RFC 2136).


=E2=80=9CThe former approach is

=C2=A0=C2=A0 usually used by Mobile Ad Hoc Networks (MANET) for a sep= arate multi-

=C2=A0=C2=A0 link subnet.=E2=80=9D


Site local addressing is deprecated RFC 3879=E2=80=A6so no need to= mention it in the current draft.=C2=A0

=3D> Yes, Site-local a= ddressing will be replaced by Unique Local IPv6 Addresses (ULA) in RFC 4193= .


=E2=80=9CDHCPv6 (or Statel= ess DHCPv6) can be used for the IP address

=C2=A0=C2=A0 autoconfiguration [RFC3315][RFC3736] =E2=80=9C

=3D>=C2=A0As an alternative protocol, DHCPv6 (or Stateles= s DHCPv6) can also be used for the IP address=C2=A0autoconfiguration [RFC3= 315][RFC3736].

There is no more autoconfiguration when we use DHCPv6=E2=80=A6So t= his sentence should be corrected accordingly. =C2=A0

=3D> What do you mean by "There is no more au= toconfiguration when we use DHCPv6"?

I intend that DHCPv6 can be used for an IPv6 host's address a= utoconfiguration instead of RA.

Thanks.=

Best Regards,

Paul=C2=A0

=C2=A0=C2=A0
B= est regards
Nabil Benamar
-------------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9= =D9=85=D8=B1=D9=88


On Wed, Feb 24, 2016 at 8:57 AM, Mr. Jaehoon= Paul Jeong <jaehoon.paul@gmail.com> wrote:
Hi Richard,
I will check the IOS standards re= lated to ITS, which are pointed by you.

I agree wi= th you that you need to use well-known terminology for our ITS work.
<= div>
For 802.11p, as I know, both industry and academia are c= onsidering it as=C2=A0
Dedicated Short-Range Communications (DSRC= ) for vehicular networking.=C2=A0

Thanks.

Best Regards,
Paul


On Thu, Feb 18= , 2016 at 6:24 AM, Richard Roy <dickroy@alum.mit.edu> wro= te:
Alex/Paul,

I suspect much of what you are thinking needs standardization below has
already been standardized.=C2=A0 You might want to check out ISO 21217 (ITS=
station/communication architecture), followed by ISO 21210 (IPv6 networking=
for ITS).=C2=A0 If nothing else, we already have terms for all of the
configurations you describe below (see ISO 21217).=C2=A0 It would be best t= o
stick with this now well-known terminology.

By the way, none of this depends on 802.11 5.9GHz in the data link and
physical layers.=C2=A0 I continue to wonder why 802.11p ever comes up.=C2= =A0 It could
just as well be 5.4GHz BRAN, 2.4GHz ISM, IR, tin can and a string, or
whatever ...

Cheers,

RR

> -----Original Message-----
> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
> Sent: Wednesday, February 17, 2016 4:22 AM
> To: Mr. Jaehoon Paul Jeong
> Cc: its@ietf.org=
> Subject: Re: [its] Comments for a New Draft of Problem Statement for V= 2I
> Networking
>
> Hello Paul,
>
> Thanks a lot for this draft.=C2=A0 This V2I problem statement covers m= any
> things we have discussed in Yokohama.
>
> What do the others think about this draft?
>
> I hame some comments, see below.
>
> Le 15/02/2016 17:30, Mr. Jaehoon Paul Jeong a =C3=A9crit :
> > Hi ITS Colleagues,
> >
> > Title: Problem Statement for Vehicle-to-Infrastructure Networking=
> > I-D: draft-jeong-its-v2i-problem-statement-00 Link:
> > https://tools.ietf.org= /html/draft-jeong-its-v2i-problem-statement-00
> >
> > Abstract This document specifies the problem statement for
> > IPv6-based vehicle- to-infrastructure networking.=C2=A0 Dedicated=
> > Short-Range Communications (DSRC) is standardized as IEEE 802.11p= for
> > the wireless media access in vehicular networks.=C2=A0 This docum= ent
> > addresses the extension of IPv6 as the network layer protocol in<= br> > > vehicular networks and is focused on the networking issues in
> > one-hop communication between a Road-Side Unit (RSU) and vehicle.=
> > The RSU is connected to the Internet and allows vehicles to have = the
> > Internet access if connected.=C2=A0 The major issues of including= IPv6 in
> > vehicular networks are neighbor discovery protocol, stateless
> > address autoconfiguration, and DNS configuration for the Internet=
> > connectivity over DSRC.=C2=A0 Also, when the vehicle and the RSU = have an
> > internal network, respectively, the document discusses the issues= of
> > internetworking between the vehicle's internal network and th= e RSU's
> > internal network.
> >
> > If you have comments or questions, please let me know.
>
> You can use the documentation prefixes 2001:db8:1000::/63 (instead of<= br> > real addresses like 2001:1000::/63).
>
> The term "RSU infra-node network" is something new and may n= eed to be
> present in the definitions section.
>
> If I understand you correctly, the RSU infra-node network is a network=
> of IP-addressable devices which are present in the Road-Side Unit - ri= ght?
>
> I am asking because I know some such RSUs on the market which contain<= br> > several IP-addressable devices linked together, but we dont have a nam= e
> for them.=C2=A0 The "RSU infra-node network" sounds good, I = think.
>
> For the term "mobile network" - we can rather use maybe
> "moving network".
>
> In section 5 "Internetworking between the Vehicle and RSU network= s":
> > Problems are a prefix discovery and prefix exchange.=C2=A0 The pr= efix
> > discovery is defined as how routers in a mobile network discover<= br> > > prefixes in the mobile network.=C2=A0 The prefix exchange is defi= ned as
> > how the vehicle and the RSU exchange their prefixes with each oth= er.
>
> I agree with the problem of prefix exchange.
>
> For the "prefix discovery", I have some doubts.
>
> First, the routers inside the moving network can be pre-configured wit= h
> the prefixes inside that moving network.=C2=A0 If so, then there can b= e no
> need for these routers to discover the prefixes inside the same moving=
> network.=C2=A0 But, of course, if they are not preconfigured then they= have
> to be discovered somehow.
>
> Second, there is a need for one router (the mobile router?) in the
> moving network to discover several parameters of a nearby moving
> network, and also the parameters of a "RSU infra-node network&quo= t;.=C2=A0 These
> parameters, including the IP prefix of the other network, are listed i= n
> draft-petrescu-its-problem-01 section 3.1 "Discovery Sub-Problem&= quot;.=C2=A0 It
> would be good to use same terminology for this discovery.
>
> > This section discusses IP addressing for V2I networking.=C2=A0 Th= ere are
> > two policies for IPv6 addressing in vehicular networks.=C2=A0 The= one
> > policy is to use site-local IPv6 addresses for vehicular networks=
> > [RFC4291].
>
> Since the site-local IPv6 addresses (fec0::) have been deprecated, it<= br> > would be appropriate to mention "Unique Local Addresses" (UL= As) which
> can somehow play the role that seems to be needed here.=C2=A0 I sugges= t to
> substitute ULA for site-local addresses.
>
> > The former approach is
> >=C2=A0 =C2=A0 usually used by Mobile Ad Hoc Networks (MANET) for a= separate multi-
> >=C2=A0 =C2=A0 link subnet.
>
> MANET has a certain meaning at IETF: it's the WG MANET.=C2=A0 I do= nt think
> there is any MANET draft that recommends ULAs (but maybe they recommen= d
> site-locals?).=C2=A0 Maybe ask the MANET WG what is the MANET IP Addre= ssing
> Architecture (do they use ULAs?=C2=A0 do they use GUA - globals?).=C2= =A0 If yes
> then refer to MANET WG document here.
>
>=C2=A0 > Sections 7 ND, 8 address autoconf, 9 DNS
>
> I agree with these sections 7, 8 and 9.
>
> > 10.=C2=A0 IP Mobility Support
> >
> >=C2=A0 =C2=A0 This section discusses an IP mobility support in V2I= networking.=C2=A0 In
> >=C2=A0 =C2=A0 a single subnet per RSU, vehicles keep crossing the = communication
> >=C2=A0 =C2=A0 coverages of adjacent RSUs.=C2=A0 During this crossi= ng, TCP/UDP sessions
> >=C2=A0 =C2=A0 can be maintained through IP mobility support, such = as Mobile IPv6
> >=C2=A0 =C2=A0 [RFC6275].=C2=A0 Since vehicles move fast along road= ways, this high speed
> >=C2=A0 =C2=A0 should be configured for a parameter configuration i= n Mobile IPv6.
> >
> >=C2=A0 =C2=A0 To support the mobility of a vehicle's mobile ne= twork, Network
> >=C2=A0 =C2=A0 Mobility (NEMO) protocol can be used [RFC3963].=C2= =A0 Like Mobile IPv6,
> >=C2=A0 =C2=A0 the high speed of vehicles should be considered for = a parameter
> >=C2=A0 =C2=A0 configuration in NEMO.
>
> I agree.
>
> I would like to add the following:
>
> 1. When Mobile IPv6/NEMO is used by the Mobile Router connected to
>=C2=A0 =C2=A0 =C2=A0the RSU infra-node a tunnel is established between = the MR and its
>=C2=A0 =C2=A0 =C2=A0Home Agent in the TCC (Traffic Control Center).=C2= =A0 If a node inside
>=C2=A0 =C2=A0 =C2=A0the moving network (not the MR) needs to exchange d= ata with a node
>=C2=A0 =C2=A0 =C2=A0within the RSU infra-node network then that communi= cation must
>=C2=A0 =C2=A0 =C2=A0go through the Home Agent.=C2=A0 The delays on the = path to the HA may be
>=C2=A0 =C2=A0 =C2=A0too high for the reactivity needed between a vehicl= e and an RSU, or
>=C2=A0 =C2=A0 =C2=A0the path can even be blocked.=C2=A0 For this reason= it is necessary to
>=C2=A0 =C2=A0 =C2=A0accommodate direct communications (skip the HA) bet= ween a node in
>=C2=A0 =C2=A0 =C2=A0the moving network and a node in the RSU infra-node= network.=C2=A0 This
>=C2=A0 =C2=A0 =C2=A0can be achieved only if the two networks learn each= other's prefixes.
>
> 2. A new method of connecting the moving network directly to the RSU >=C2=A0 =C2=A0 =C2=A0infra-node network may lead to modifying the addres= sing architecture
>=C2=A0 =C2=A0 =C2=A0in the moving network.=C2=A0 This can become a prob= lem to the use of
>=C2=A0 =C2=A0 =C2=A0Mobile IP, because Mobile IP relies on the addressi= ng architecture
>=C2=A0 =C2=A0 =C2=A0controlled by the Home Agent.=C2=A0 This problem sh= ould be solved as well.
>
>
> In section 11 Security Considerations:
> > 11.=C2=A0 Security Considerations
> >
> >=C2=A0 =C2=A0 The security is very important in vehicular networks= for V2I
> >=C2=A0 =C2=A0 networking.=C2=A0 Only valid vehicles should be allo= wed to use V2I
> >=C2=A0 =C2=A0 networking in vehicular networks.=C2=A0 VIN and a us= er certificate can be
> >=C2=A0 =C2=A0 used to authenticate a vehicle and the user.
> >
> >=C2=A0 =C2=A0 This document shares all the security issues of the = neighbor
> >=C2=A0 =C2=A0 discovery protocol.=C2=A0 This document can get bene= fits from secure
> >=C2=A0 =C2=A0 neighbor discovery (SEND) [RFC3971]
>
> Recent works in security for vehicular networks mention two additional=
> things that are worth considering:
>
> 1. the use of TLS certificates for vehicle communications
>=C2=A0 =C2=A0 =C2=A0draft-lonc-tls-certieee1609-01
>
> 2. privacy considerations: a new ETSI activity may consider privacy >=C2=A0 =C2=A0 =C2=A0aspects of identifier generation in vehicular commu= nications.
>
> It is worth referring to these aspects (give references).
>
> Yours,
>
> Alex
>
>
>
> >
> > Thanks.
> >
> > Best Regards, Paul -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. Jaehoon (Paul)
> > Jeong, Ph.D. Assistant Professor Department of Software Sungkyunk= wan
> > University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com
> > <mailto:jaehoon.paul@gmail.com>, pauljeong@skku.edu
> > <mailto:pauljeong@skku.edu> Personal Homepage:
> > http://iotlab.skku.edu/people-jaehoon-jeo= ng.php
> > <http://cpslab.skku.edu/people-jaehoon-j= eong.php>
> >
> >
> > _______________________________________________ its mailing list<= br> > > its@ietf.org https://www.ietf.org/mailman/listinfo/its
> >
>





<= /div>--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Profe= ssor
Department of Software
Sungkyunkwan University
Office: +82-31= -299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skk= u.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-je= ong.php

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its





--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant ProfessorDepartment of Software
Sungkyunkwan University
Office: +82-31-299-4= 957
Email: j= aehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<= /div>
--001a1146e086254cd2052fb32491-- From nobody Tue Apr 5 04:28:13 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C38112D1E8 for ; Tue, 5 Apr 2016 04:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqkGeDkTrhHy for ; Tue, 5 Apr 2016 04:28:07 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4388712D1B6 for ; Tue, 5 Apr 2016 04:28:07 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id 191so21115791wmq.0 for ; Tue, 05 Apr 2016 04:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=lQdaSe34V7wBOHK3auHAo9ltROzmiBiagcPJK3Bw6Do=; b=rtwMemPUmSvbB1YIoGCHuys4ewGCxlm9qmGRNrGa6EaS5J62FDgn+M1hWsg5JV+xPK Uuj6OxyDbqx/hekmsljbrvFc+LZ/kT6BpEDfQiB5ZTJwWNUyIKfPpJ5B4oVfs35bb4eF /5AufiU4XXjiZggrVRSh5RxSN+evEjrQrq/SoWvVSv2fpWO/8aZGC+1xpndxbmx5FL82 Axt2naQgwMVcQL4+i0YSJo4u7ImpSsUnoxhbIyHUfTdfgW9CY/uKZ49fN/30vyVRV4ut wviGALGfmJntf4b9VWgYUD6u6yo00/U4ZRTTnfryvYMjLsNAUq8HviAkeu+GA+N5X56d rBiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=lQdaSe34V7wBOHK3auHAo9ltROzmiBiagcPJK3Bw6Do=; b=U6fGw5NU97vRMY0SGBO07vkMEY5Q3od+xZdrHpTLKXkwxNegGjYnvcmLGi2pJ0NrqM MoEsYvHkX8fvV6p1DD6PIpwlgr86Y+cRIq31N4JNP2UToZ4jcfEk1Ar8RPddyQBWtMdJ 4LIBpBSqCPpM60V/5tY+puyyj4ORaUsXAg8cgY8pswP9JCUx33ec+HaHah40bGBvYVuW q5noPvjsxyDS8l8OcV3XQjtj5cBlNIvxn0YR36olPRFe/5K19oZzPPyiwnPhegkGJkBz PYdKwfXnuYh9Qk/rPgW0r/PTAYfjaCob8jmQrjQbzX4NkHLbp07AhIk4hQyQWfARLq3h TVEQ== X-Gm-Message-State: AD7BkJIvQ4iFnq4fXJukd+hK3+3FZeXIqBoEgLNNHravmVII5CxcdShXNTy7Qt81Eukqhsbnby2PC1KMTRaVrQ== MIME-Version: 1.0 X-Received: by 10.28.211.130 with SMTP id k124mr17660503wmg.7.1459855685712; Tue, 05 Apr 2016 04:28:05 -0700 (PDT) Received: by 10.28.224.137 with HTTP; Tue, 5 Apr 2016 04:28:05 -0700 (PDT) Date: Tue, 5 Apr 2016 08:28:05 -0300 Message-ID: From: Nabil Benamar To: "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary=001a1146998e92027b052fbb23da Archived-At: Cc: Thierry Ernst , "its@ietf.org" , knut.evensen@q-free.com, "Dr. Hans-Joachim Fischer" , Alexandre Petrescu , Richard Roy Subject: Re: [its] Comments for a New Draft of Problem Statement for V2I Networking X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 11:28:11 -0000 --001a1146998e92027b052fbb23da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jaehoon, Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Mon, Apr 4, 2016 at 10:55 PM, Mr. Jaehoon Paul Jeong < jaehoon.paul@gmail.com> wrote: > Hi Nabil, > Thanks for your good comments. > > I answers your questions and comments in lines with "=3D>" below. > > On Sat, Apr 2, 2016 at 5:04 PM, Nabil Benamar wrote= : > >> Hi Jaehoon, >> >> Here are some comments: >> >> *Introduction* >> >> >> * =E2=80=9C Recently,=E2=80=A6..=E2=80=9D This is not recent since the= works on VANETs and its >> use cases have been done for a while =E2=80=A6 such as driving safety, e= fficient >> driving, and entertainment! There are a lot of journal papers tackling i= n >> details this topic.* >> >> *This section can be modified as follows: * >> >> *Vehicular Networks have become a popular topic during the last years du= e >> to the important applications that can be realized in such environment.* >> > *=3D> Will be reflected on the revision.* >> >> *=E2=80=9C =E2=80=A6 with a consideration of the vehicular network's cha= racteristics such >> as a vehicle's velocity and collision avoidance.=E2=80=9D * >> > *Collision avoidance is a consequence and a goal to attend and not a >> characteristic of this IEEE standard.* >> >> *=3D> You are right. I will update it as follows: =E2=80=9C... with a co= nsideration >> of the vehicular network's characteristics such as a vehicle's velocity = and >> its directed movement along a roadway.=E2=80=9D* >> >> >> > *=E2=80=9C=E2=80=A6.IPv6 [RFC2460] is suitable for vehicular networks sin= ce the protocol >> has* >> >> * abundant address space, autoconfiguration features, and protocol >> extension ability through extension headers.=E2=80=9D* >> >> >> *Better to mention the draft >> =E2=80=98https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-03 >> =E2=80= =99 as a >> supporting reference here.* >> > *=3D> Will be reflected on the revision.* >> >> >> > *=E2=80=9Cit is assumed that the prefix assignment for each subnet inside= * >> >> * the vehicle's mobile network and the RSU's infra-node network throug= h* >> >> * a prefix delegation protocol.=E2=80=9D* >> >> >> *Prefex delegation is only possible through DHCPv6-PD, is this what you >> mean ? * >> > > > *=3D> Yes, DHCPv6-PD can be used as a solution. We may invent another one > for vehicular networks.** Also, prefix configuration can be manually > done at the manufacturing time as factory default.* > >> >> *=E2=80=9CAlso, the DNS naming service should be supported for the* >> >> * DNS name resolution for a host or server in either the vehicle's* >> >> * mobile network or the RSU's infra-node network.=E2=80=9D* >> >> >> *So what could be the issue here ? Is DNS an issue? DNS information are >> included in RA with the flag =E2=80=9CO=E2=80=9D enabled. * >> > *=3D> We need to consider three issues, such as IPv6 host DNS configurati= on, >> DNS name resolution, and DNS name autoconfiguration. * >> > *The first is IPv6 host DNS configuration for Recursive DNS Server (RDNSS= ) >> and DNS Search List (DNSSL) t**hrough RA Options (RFC 6106) and DHCP >> Options (RFC 3646).* >> >> *The second is DNS name resolution through an appropriate RDNSS w**ithin >> a vehicle=E2=80=99s moving network or an RSU=E2=80=99s fixed network. * >> >> *The third is DNS name autoconfiguration of vehicle and in-vehicle >> devices t**hrough DNSNA (draft-jeong-its-iot-dns-autoconf-00), mDNS (RFC >> 6762), and DNS Update (RFC 2136).* >> >> >> *=E2=80=9CThe former approach is* >> >> * usually used by Mobile Ad Hoc Networks (MANET) for a separate multi-= * >> >> * link subnet.=E2=80=9D* >> >> >> *Site local addressing is deprecated RFC 3879=E2=80=A6so no need to ment= ion it in >> the current draft. * >> > *=3D> Yes, Site-local addressing will be replaced by Unique Local IPv6 >> Addresses (ULA) in RFC 4193.* >> > =E2=80=8BIndeed, site local have already been replaced by ULAs=E2=80=8B > >> *=E2=80=9CDHCPv6 (or Stateless DHCPv6) can be used for the IP address* >> >> * autoconfiguration [RFC3315][RFC3736] =E2=80=9C * >> > *=3D> **As an alternative protocol, DHCPv6 (or Stateless DHCPv6) can also >> be used for the IP address **autoconfiguration [RFC3315][RFC3736].* >> >> *There is no more autoconfiguration when we use DHCPv6=E2=80=A6So this s= entence >> should be corrected accordingly. * >> > *=3D> What do you mean by "**There is no more autoconfiguration when we u= se >> DHCPv6**"?* >> > =E2=80=8BI mean that when you use DHCPv6 that means that your DHCP sever = will send all the configuration =E2=80=8Bdetails needed (IPv6@ + prefix length +gw + = @DNS) if the M flag is enabled, which means that there is no "auto" configuration! So the term "auto" in this case should be removed. > *I intend that DHCPv6 can be used for an IPv6 host's address >> autoconfiguration instead of RA. * >> > *Thanks. * >> > *Best Regards,* >> > *Paul* >> > > >> Best regards >> Nabil Benamar >> ------------------- >> =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 >> >> http://nabilbenamar.ipv6-lab.net/ >> >> On Wed, Feb 24, 2016 at 8:57 AM, Mr. Jaehoon Paul Jeong < >> jaehoon.paul@gmail.com> wrote: >> >>> Hi Richard, >>> I will check the IOS standards related to ITS, which are pointed by you= . >>> >>> I agree with you that you need to use well-known terminology for our IT= S >>> work. >>> >>> For 802.11p, as I know, both industry and academia are considering it a= s >>> Dedicated Short-Range Communications (DSRC) for vehicular networking. >>> >>> Thanks. >>> >>> Best Regards, >>> Paul >>> >>> >>> On Thu, Feb 18, 2016 at 6:24 AM, Richard Roy >>> wrote: >>> >>>> Alex/Paul, >>>> >>>> I suspect much of what you are thinking needs standardization below ha= s >>>> already been standardized. You might want to check out ISO 21217 (ITS >>>> station/communication architecture), followed by ISO 21210 (IPv6 >>>> networking >>>> for ITS). If nothing else, we already have terms for all of the >>>> configurations you describe below (see ISO 21217). It would be best t= o >>>> stick with this now well-known terminology. >>>> >>>> By the way, none of this depends on 802.11 5.9GHz in the data link and >>>> physical layers. I continue to wonder why 802.11p ever comes up. It >>>> could >>>> just as well be 5.4GHz BRAN, 2.4GHz ISM, IR, tin can and a string, or >>>> whatever ... >>>> >>>> Cheers, >>>> >>>> RR >>>> >>>> > -----Original Message----- >>>> > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] >>>> > Sent: Wednesday, February 17, 2016 4:22 AM >>>> > To: Mr. Jaehoon Paul Jeong >>>> > Cc: its@ietf.org >>>> > Subject: Re: [its] Comments for a New Draft of Problem Statement for >>>> V2I >>>> > Networking >>>> > >>>> > Hello Paul, >>>> > >>>> > Thanks a lot for this draft. This V2I problem statement covers many >>>> > things we have discussed in Yokohama. >>>> > >>>> > What do the others think about this draft? >>>> > >>>> > I hame some comments, see below. >>>> > >>>> > Le 15/02/2016 17:30, Mr. Jaehoon Paul Jeong a =C3=A9crit : >>>> > > Hi ITS Colleagues, >>>> > > >>>> > > Title: Problem Statement for Vehicle-to-Infrastructure Networking >>>> > > I-D: draft-jeong-its-v2i-problem-statement-00 Link: >>>> > > >>>> https://tools.ietf.org/html/draft-jeong-its-v2i-problem-statement-00 >>>> > > >>>> > > Abstract This document specifies the problem statement for >>>> > > IPv6-based vehicle- to-infrastructure networking. Dedicated >>>> > > Short-Range Communications (DSRC) is standardized as IEEE 802.11p >>>> for >>>> > > the wireless media access in vehicular networks. This document >>>> > > addresses the extension of IPv6 as the network layer protocol in >>>> > > vehicular networks and is focused on the networking issues in >>>> > > one-hop communication between a Road-Side Unit (RSU) and vehicle. >>>> > > The RSU is connected to the Internet and allows vehicles to have t= he >>>> > > Internet access if connected. The major issues of including IPv6 = in >>>> > > vehicular networks are neighbor discovery protocol, stateless >>>> > > address autoconfiguration, and DNS configuration for the Internet >>>> > > connectivity over DSRC. Also, when the vehicle and the RSU have a= n >>>> > > internal network, respectively, the document discusses the issues = of >>>> > > internetworking between the vehicle's internal network and the RSU= 's >>>> > > internal network. >>>> > > >>>> > > If you have comments or questions, please let me know. >>>> > >>>> > You can use the documentation prefixes 2001:db8:1000::/63 (instead o= f >>>> > real addresses like 2001:1000::/63). >>>> > >>>> > The term "RSU infra-node network" is something new and may need to b= e >>>> > present in the definitions section. >>>> > >>>> > If I understand you correctly, the RSU infra-node network is a netwo= rk >>>> > of IP-addressable devices which are present in the Road-Side Unit - >>>> right? >>>> > >>>> > I am asking because I know some such RSUs on the market which contai= n >>>> > several IP-addressable devices linked together, but we dont have a >>>> name >>>> > for them. The "RSU infra-node network" sounds good, I think. >>>> > >>>> > For the term "mobile network" - we can rather use maybe >>>> > "moving network". >>>> > >>>> > In section 5 "Internetworking between the Vehicle and RSU networks": >>>> > > Problems are a prefix discovery and prefix exchange. The prefix >>>> > > discovery is defined as how routers in a mobile network discover >>>> > > prefixes in the mobile network. The prefix exchange is defined as >>>> > > how the vehicle and the RSU exchange their prefixes with each othe= r. >>>> > >>>> > I agree with the problem of prefix exchange. >>>> > >>>> > For the "prefix discovery", I have some doubts. >>>> > >>>> > First, the routers inside the moving network can be pre-configured >>>> with >>>> > the prefixes inside that moving network. If so, then there can be n= o >>>> > need for these routers to discover the prefixes inside the same movi= ng >>>> > network. But, of course, if they are not preconfigured then they ha= ve >>>> > to be discovered somehow. >>>> > >>>> > Second, there is a need for one router (the mobile router?) in the >>>> > moving network to discover several parameters of a nearby moving >>>> > network, and also the parameters of a "RSU infra-node network". The= se >>>> > parameters, including the IP prefix of the other network, are listed >>>> in >>>> > draft-petrescu-its-problem-01 section 3.1 "Discovery Sub-Problem". = It >>>> > would be good to use same terminology for this discovery. >>>> > >>>> > > This section discusses IP addressing for V2I networking. There ar= e >>>> > > two policies for IPv6 addressing in vehicular networks. The one >>>> > > policy is to use site-local IPv6 addresses for vehicular networks >>>> > > [RFC4291]. >>>> > >>>> > Since the site-local IPv6 addresses (fec0::) have been deprecated, i= t >>>> > would be appropriate to mention "Unique Local Addresses" (ULAs) whic= h >>>> > can somehow play the role that seems to be needed here. I suggest t= o >>>> > substitute ULA for site-local addresses. >>>> > >>>> > > The former approach is >>>> > > usually used by Mobile Ad Hoc Networks (MANET) for a separate >>>> multi- >>>> > > link subnet. >>>> > >>>> > MANET has a certain meaning at IETF: it's the WG MANET. I dont thin= k >>>> > there is any MANET draft that recommends ULAs (but maybe they >>>> recommend >>>> > site-locals?). Maybe ask the MANET WG what is the MANET IP Addressi= ng >>>> > Architecture (do they use ULAs? do they use GUA - globals?). If ye= s >>>> > then refer to MANET WG document here. >>>> > >>>> > > Sections 7 ND, 8 address autoconf, 9 DNS >>>> > >>>> > I agree with these sections 7, 8 and 9. >>>> > >>>> > > 10. IP Mobility Support >>>> > > >>>> > > This section discusses an IP mobility support in V2I >>>> networking. In >>>> > > a single subnet per RSU, vehicles keep crossing the communicati= on >>>> > > coverages of adjacent RSUs. During this crossing, TCP/UDP >>>> sessions >>>> > > can be maintained through IP mobility support, such as Mobile >>>> IPv6 >>>> > > [RFC6275]. Since vehicles move fast along roadways, this high >>>> speed >>>> > > should be configured for a parameter configuration in Mobile >>>> IPv6. >>>> > > >>>> > > To support the mobility of a vehicle's mobile network, Network >>>> > > Mobility (NEMO) protocol can be used [RFC3963]. Like Mobile >>>> IPv6, >>>> > > the high speed of vehicles should be considered for a parameter >>>> > > configuration in NEMO. >>>> > >>>> > I agree. >>>> > >>>> > I would like to add the following: >>>> > >>>> > 1. When Mobile IPv6/NEMO is used by the Mobile Router connected to >>>> > the RSU infra-node a tunnel is established between the MR and it= s >>>> > Home Agent in the TCC (Traffic Control Center). If a node insid= e >>>> > the moving network (not the MR) needs to exchange data with a no= de >>>> > within the RSU infra-node network then that communication must >>>> > go through the Home Agent. The delays on the path to the HA may >>>> be >>>> > too high for the reactivity needed between a vehicle and an RSU, >>>> or >>>> > the path can even be blocked. For this reason it is necessary t= o >>>> > accommodate direct communications (skip the HA) between a node i= n >>>> > the moving network and a node in the RSU infra-node network. Th= is >>>> > can be achieved only if the two networks learn each other's >>>> prefixes. >>>> > >>>> > 2. A new method of connecting the moving network directly to the RSU >>>> > infra-node network may lead to modifying the addressing >>>> architecture >>>> > in the moving network. This can become a problem to the use of >>>> > Mobile IP, because Mobile IP relies on the addressing architectu= re >>>> > controlled by the Home Agent. This problem should be solved as >>>> well. >>>> > >>>> > >>>> > In section 11 Security Considerations: >>>> > > 11. Security Considerations >>>> > > >>>> > > The security is very important in vehicular networks for V2I >>>> > > networking. Only valid vehicles should be allowed to use V2I >>>> > > networking in vehicular networks. VIN and a user certificate >>>> can be >>>> > > used to authenticate a vehicle and the user. >>>> > > >>>> > > This document shares all the security issues of the neighbor >>>> > > discovery protocol. This document can get benefits from secure >>>> > > neighbor discovery (SEND) [RFC3971] >>>> > >>>> > Recent works in security for vehicular networks mention two addition= al >>>> > things that are worth considering: >>>> > >>>> > 1. the use of TLS certificates for vehicle communications >>>> > draft-lonc-tls-certieee1609-01 >>>> > >>>> > 2. privacy considerations: a new ETSI activity may consider privacy >>>> > aspects of identifier generation in vehicular communications. >>>> > >>>> > It is worth referring to these aspects (give references). >>>> > >>>> > Yours, >>>> > >>>> > Alex >>>> > >>>> > >>>> > >>>> > > >>>> > > Thanks. >>>> > > >>>> > > Best Regards, Paul -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. Jaehoon (Paul) >>>> > > Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkw= an >>>> > > University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>>> > > , pauljeong@skku.edu >>>> > > Personal Homepage: >>>> > > http://iotlab.skku.edu/people-jaehoon-jeong.php >>>> > > >>>> > > >>>> > > >>>> > > _______________________________________________ its mailing list >>>> > > its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> > > >>>> > >>>> >>>> >>>> >>> >>> >>> -- >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>> Assistant Professor >>> Department of Software >>> Sungkyunkwan University >>> Office: +82-31-299-4957 >>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>> >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>> >> > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > --001a1146998e92027b052fbb23da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jaehoon,

Best regar= ds
Nabil Benamar
-------------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8= =B1=D9=88


On Mon, Apr 4, 2016 at 10:55 PM, Mr. Jaehoon= Paul Jeong <jaehoon.paul@gmail.com> wrote:
Hi Nabil,
Thanks for your good comments.

<= div>I answers your questions and comments in lines with "=3D>"= below.

On Sat, Apr 2, 2016 at 5:04 PM, Nabil Benamar <benamar73@gm= ail.com> wrote:
Hi Jaehoon,

Here are some comments:

Introduction


=C2=A0 =E2=80=9C Recently,=E2=80=A6..=E2=80=9D=C2=A0 This is not r= ecent since the works on VANETs and its use cases have been done for a whil= e =E2=80=A6 such as driving safety, efficient driving, and entertainment! T= here are a lot of journal papers tackling in details this topic.

This section can be modified as follows:=C2=A0

Vehicular Networks have become a popular topic during the last yea= rs due to the important applications that can be realized in such environme= nt.

=3D> Will be reflected on the revision.

=E2=80=9C =E2=80=A6 with a consideration of the vehicular network&= #39;s characteristics such as a vehicle's velocity and collision avoida= nce.=E2=80=9D=C2=A0

Collision avoidance is = a consequence and a goal to attend and not a characteristic of this IEEE st= andard.

=3D> Y= ou are right. I will update it as follows: =E2=80=9C... with a consideratio= n of the vehicular network's characteristics such as a vehicle's ve= locity and its directed movement along a roadway.=E2=80=9D

=C2= =A0 =C2=A0 =C2=A0

=E2=80=9C=E2=80=A6.IPv6 [RFC2460] is suitable for vehicular networ= ks since the protocol has

=C2=A0=C2=A0 abundant address space, autoconfiguration features, a= nd protocol extension ability through extension headers.=E2=80=9D


Better to mention the draft =E2=80=98https://too= ls.ietf.org/html/draft-petrescu-ipv6-over-80211p-03=E2=80=99 =C2=A0 as = a supporting reference here.

=3D> Will be reflected on the revisio= n.=C2=A0=C2=A0

=C2= =A0

=E2=80=9Cit is assumed that the prefix assignment for each subnet ins= ide

=C2=A0=C2=A0 the vehicle's mobile network and the RSU's infra= -node network through

=C2=A0=C2=A0 a prefix delegation protocol.=E2=80=9D


Prefex delegation is only possible through DHCPv6-PD, is this what yo= u mean ?

=C2=A0=C2=A0=3D> Yes, DHCPv6-PD can b= e used as a solution. We may invent another one for
=C2=A0 vehicular networks.
=C2=A0 Also= , prefix configuration can be manually done at the manufacturing time as fa= ctory default.=C2=A0 =C2=A0


=E2=80=9CAlso, the DNS naming service should be supported for the=

=C2=A0=C2=A0 DNS name resolution for a host or server in either the v= ehicle's

=C2=A0=C2=A0 mobile network or the RSU's infra-node network.=E2= =80=9D


So what could be the issue here ? Is DNS an issue? DNS information ar= e included in RA with the flag =E2=80=9CO=E2=80=9D enabled.

<= /div>

=3D> We need to consider three issues, such as IPv6 hos= t DNS configuration, DNS name resolution, and DNS name autoconfiguration.= =C2=A0

=

The first is IPv6 host DNS configuration for Recursive DNS Server (RD= NSS) and DNS Search List (DNSSL) through RA Options (RFC 6106) and DHCP Op= tions (RFC 3646).

The second is DNS name resolution through an appropriate RDNSS wi= thin a vehicle=E2=80=99s moving network or an RSU=E2=80=99s fixed network.= =C2=A0

<= b>The third is DNS name autoconfiguration of vehicle and in-vehicle devices= through DNSNA (draft-jeong-its-iot-dns-autoconf-00), mDNS (RFC 6762), and= DNS Update (RFC 2136).


<= span class=3D"">

=E2=80=9CThe former approach is

=C2=A0=C2=A0 usually used by Mobile Ad Hoc Networks (MANET) for a sep= arate multi-

=C2=A0=C2=A0 link subnet.=E2=80=9D


Site local addressing is deprecated RFC 3879=E2=80=A6so no need to= mention it in the current draft.=C2=A0

=3D> Yes, Site-local addre= ssing will be replaced by Unique Local IPv6 Addresses (ULA) in RFC 4193.

=E2=80=8BIndeed= , site local have already been replaced by ULAs=E2=80=8B
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 .8ex;border-left:1px #cc= c solid;border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex">


=E2=80=9CDHCPv6 (or = Stateless DHCPv6) can be used for the IP address

=C2=A0=C2=A0 autoconfiguration [RFC3315][RFC3736] =E2=80=9C

=3D>=C2=A0As an alternative protocol, DHCPv6 (or Stateles= s DHCPv6) can also be used for the IP address=C2=A0autoconfiguration [RFC3= 315][RFC3736].

There is no more autoconfiguration when we use DHCPv6=E2=80=A6So t= his sentence should be corrected accordingly. =C2=A0

=

=3D> What do you mean by "There is no more autoconf= iguration when we use DHCPv6"?

=
=E2=80=8BI mean that when you use DHCPv6 that means that your DHCP = sever will send all the configuration =E2=80=8Bdetails needed (IPv6@ + pref= ix length +gw + @DNS) if the M flag is enabled, which means that there is n= o "auto" configuration! So the term "auto" in this case= should be removed.

I intend that DHCPv6 can be used= for an IPv6 host's address autoconfiguration instead of RA.

Thanks.

Best Regards,

<= div>

Paul=C2=A0

=C2=A0=C2=A0
Best regards
Nabil Benamar
<= div dir=3D"rtl" style=3D"text-align:left">-------------------
=D9=86=D8=A8=D9=8A=D9= =84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88


On Wed, Feb 24, 2016 at 8:57 AM, Mr. Jaehoon= Paul Jeong <jaehoon.paul@gmail.com> wrote:
Hi Richard,
I will check the IOS standards re= lated to ITS, which are pointed by you.

I agree wi= th you that you need to use well-known terminology for our ITS work.
<= div>
For 802.11p, as I know, both industry and academia are c= onsidering it as=C2=A0
Dedicated Short-Range Communications (DSRC= ) for vehicular networking.=C2=A0

Thanks.

Best Regards,
Paul


On Thu, Feb 18= , 2016 at 6:24 AM, Richard Roy <dickroy@alum.mit.edu> wro= te:
Alex/Paul,

I suspect much of what you are thinking needs standardization below has
already been standardized.=C2=A0 You might want to check out ISO 21217 (ITS=
station/communication architecture), followed by ISO 21210 (IPv6 networking=
for ITS).=C2=A0 If nothing else, we already have terms for all of the
configurations you describe below (see ISO 21217).=C2=A0 It would be best t= o
stick with this now well-known terminology.

By the way, none of this depends on 802.11 5.9GHz in the data link and
physical layers.=C2=A0 I continue to wonder why 802.11p ever comes up.=C2= =A0 It could
just as well be 5.4GHz BRAN, 2.4GHz ISM, IR, tin can and a string, or
whatever ...

Cheers,

RR

> -----Original Message-----
> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
> Sent: Wednesday, February 17, 2016 4:22 AM
> To: Mr. Jaehoon Paul Jeong
> Cc: its@ietf.org=
> Subject: Re: [its] Comments for a New Draft of Problem Statement for V= 2I
> Networking
>
> Hello Paul,
>
> Thanks a lot for this draft.=C2=A0 This V2I problem statement covers m= any
> things we have discussed in Yokohama.
>
> What do the others think about this draft?
>
> I hame some comments, see below.
>
> Le 15/02/2016 17:30, Mr. Jaehoon Paul Jeong a =C3=A9crit :
> > Hi ITS Colleagues,
> >
> > Title: Problem Statement for Vehicle-to-Infrastructure Networking=
> > I-D: draft-jeong-its-v2i-problem-statement-00 Link:
> > https://tools.ietf.org= /html/draft-jeong-its-v2i-problem-statement-00
> >
> > Abstract This document specifies the problem statement for
> > IPv6-based vehicle- to-infrastructure networking.=C2=A0 Dedicated=
> > Short-Range Communications (DSRC) is standardized as IEEE 802.11p= for
> > the wireless media access in vehicular networks.=C2=A0 This docum= ent
> > addresses the extension of IPv6 as the network layer protocol in<= br> > > vehicular networks and is focused on the networking issues in
> > one-hop communication between a Road-Side Unit (RSU) and vehicle.=
> > The RSU is connected to the Internet and allows vehicles to have = the
> > Internet access if connected.=C2=A0 The major issues of including= IPv6 in
> > vehicular networks are neighbor discovery protocol, stateless
> > address autoconfiguration, and DNS configuration for the Internet=
> > connectivity over DSRC.=C2=A0 Also, when the vehicle and the RSU = have an
> > internal network, respectively, the document discusses the issues= of
> > internetworking between the vehicle's internal network and th= e RSU's
> > internal network.
> >
> > If you have comments or questions, please let me know.
>
> You can use the documentation prefixes 2001:db8:1000::/63 (instead of<= br> > real addresses like 2001:1000::/63).
>
> The term "RSU infra-node network" is something new and may n= eed to be
> present in the definitions section.
>
> If I understand you correctly, the RSU infra-node network is a network=
> of IP-addressable devices which are present in the Road-Side Unit - ri= ght?
>
> I am asking because I know some such RSUs on the market which contain<= br> > several IP-addressable devices linked together, but we dont have a nam= e
> for them.=C2=A0 The "RSU infra-node network" sounds good, I = think.
>
> For the term "mobile network" - we can rather use maybe
> "moving network".
>
> In section 5 "Internetworking between the Vehicle and RSU network= s":
> > Problems are a prefix discovery and prefix exchange.=C2=A0 The pr= efix
> > discovery is defined as how routers in a mobile network discover<= br> > > prefixes in the mobile network.=C2=A0 The prefix exchange is defi= ned as
> > how the vehicle and the RSU exchange their prefixes with each oth= er.
>
> I agree with the problem of prefix exchange.
>
> For the "prefix discovery", I have some doubts.
>
> First, the routers inside the moving network can be pre-configured wit= h
> the prefixes inside that moving network.=C2=A0 If so, then there can b= e no
> need for these routers to discover the prefixes inside the same moving=
> network.=C2=A0 But, of course, if they are not preconfigured then they= have
> to be discovered somehow.
>
> Second, there is a need for one router (the mobile router?) in the
> moving network to discover several parameters of a nearby moving
> network, and also the parameters of a "RSU infra-node network&quo= t;.=C2=A0 These
> parameters, including the IP prefix of the other network, are listed i= n
> draft-petrescu-its-problem-01 section 3.1 "Discovery Sub-Problem&= quot;.=C2=A0 It
> would be good to use same terminology for this discovery.
>
> > This section discusses IP addressing for V2I networking.=C2=A0 Th= ere are
> > two policies for IPv6 addressing in vehicular networks.=C2=A0 The= one
> > policy is to use site-local IPv6 addresses for vehicular networks=
> > [RFC4291].
>
> Since the site-local IPv6 addresses (fec0::) have been deprecated, it<= br> > would be appropriate to mention "Unique Local Addresses" (UL= As) which
> can somehow play the role that seems to be needed here.=C2=A0 I sugges= t to
> substitute ULA for site-local addresses.
>
> > The former approach is
> >=C2=A0 =C2=A0 usually used by Mobile Ad Hoc Networks (MANET) for a= separate multi-
> >=C2=A0 =C2=A0 link subnet.
>
> MANET has a certain meaning at IETF: it's the WG MANET.=C2=A0 I do= nt think
> there is any MANET draft that recommends ULAs (but maybe they recommen= d
> site-locals?).=C2=A0 Maybe ask the MANET WG what is the MANET IP Addre= ssing
> Architecture (do they use ULAs?=C2=A0 do they use GUA - globals?).=C2= =A0 If yes
> then refer to MANET WG document here.
>
>=C2=A0 > Sections 7 ND, 8 address autoconf, 9 DNS
>
> I agree with these sections 7, 8 and 9.
>
> > 10.=C2=A0 IP Mobility Support
> >
> >=C2=A0 =C2=A0 This section discusses an IP mobility support in V2I= networking.=C2=A0 In
> >=C2=A0 =C2=A0 a single subnet per RSU, vehicles keep crossing the = communication
> >=C2=A0 =C2=A0 coverages of adjacent RSUs.=C2=A0 During this crossi= ng, TCP/UDP sessions
> >=C2=A0 =C2=A0 can be maintained through IP mobility support, such = as Mobile IPv6
> >=C2=A0 =C2=A0 [RFC6275].=C2=A0 Since vehicles move fast along road= ways, this high speed
> >=C2=A0 =C2=A0 should be configured for a parameter configuration i= n Mobile IPv6.
> >
> >=C2=A0 =C2=A0 To support the mobility of a vehicle's mobile ne= twork, Network
> >=C2=A0 =C2=A0 Mobility (NEMO) protocol can be used [RFC3963].=C2= =A0 Like Mobile IPv6,
> >=C2=A0 =C2=A0 the high speed of vehicles should be considered for = a parameter
> >=C2=A0 =C2=A0 configuration in NEMO.
>
> I agree.
>
> I would like to add the following:
>
> 1. When Mobile IPv6/NEMO is used by the Mobile Router connected to
>=C2=A0 =C2=A0 =C2=A0the RSU infra-node a tunnel is established between = the MR and its
>=C2=A0 =C2=A0 =C2=A0Home Agent in the TCC (Traffic Control Center).=C2= =A0 If a node inside
>=C2=A0 =C2=A0 =C2=A0the moving network (not the MR) needs to exchange d= ata with a node
>=C2=A0 =C2=A0 =C2=A0within the RSU infra-node network then that communi= cation must
>=C2=A0 =C2=A0 =C2=A0go through the Home Agent.=C2=A0 The delays on the = path to the HA may be
>=C2=A0 =C2=A0 =C2=A0too high for the reactivity needed between a vehicl= e and an RSU, or
>=C2=A0 =C2=A0 =C2=A0the path can even be blocked.=C2=A0 For this reason= it is necessary to
>=C2=A0 =C2=A0 =C2=A0accommodate direct communications (skip the HA) bet= ween a node in
>=C2=A0 =C2=A0 =C2=A0the moving network and a node in the RSU infra-node= network.=C2=A0 This
>=C2=A0 =C2=A0 =C2=A0can be achieved only if the two networks learn each= other's prefixes.
>
> 2. A new method of connecting the moving network directly to the RSU >=C2=A0 =C2=A0 =C2=A0infra-node network may lead to modifying the addres= sing architecture
>=C2=A0 =C2=A0 =C2=A0in the moving network.=C2=A0 This can become a prob= lem to the use of
>=C2=A0 =C2=A0 =C2=A0Mobile IP, because Mobile IP relies on the addressi= ng architecture
>=C2=A0 =C2=A0 =C2=A0controlled by the Home Agent.=C2=A0 This problem sh= ould be solved as well.
>
>
> In section 11 Security Considerations:
> > 11.=C2=A0 Security Considerations
> >
> >=C2=A0 =C2=A0 The security is very important in vehicular networks= for V2I
> >=C2=A0 =C2=A0 networking.=C2=A0 Only valid vehicles should be allo= wed to use V2I
> >=C2=A0 =C2=A0 networking in vehicular networks.=C2=A0 VIN and a us= er certificate can be
> >=C2=A0 =C2=A0 used to authenticate a vehicle and the user.
> >
> >=C2=A0 =C2=A0 This document shares all the security issues of the = neighbor
> >=C2=A0 =C2=A0 discovery protocol.=C2=A0 This document can get bene= fits from secure
> >=C2=A0 =C2=A0 neighbor discovery (SEND) [RFC3971]
>
> Recent works in security for vehicular networks mention two additional=
> things that are worth considering:
>
> 1. the use of TLS certificates for vehicle communications
>=C2=A0 =C2=A0 =C2=A0draft-lonc-tls-certieee1609-01
>
> 2. privacy considerations: a new ETSI activity may consider privacy >=C2=A0 =C2=A0 =C2=A0aspects of identifier generation in vehicular commu= nications.
>
> It is worth referring to these aspects (give references).
>
> Yours,
>
> Alex
>
>
>
> >
> > Thanks.
> >
> > Best Regards, Paul -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. Jaehoon (Paul)
> > Jeong, Ph.D. Assistant Professor Department of Software Sungkyunk= wan
> > University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com
> > <mailto:jaehoon.paul@gmail.com>, pauljeong@skku.edu
> > <mailto:pauljeong@skku.edu> Personal Homepage:
> > http://iotlab.skku.edu/people-jaehoon-jeo= ng.php
> > <http://cpslab.skku.edu/people-jaehoon-j= eong.php>
> >
> >
> > _______________________________________________ its mailing list<= br> > > its@ietf.org https://www.ietf.org/mailman/listinfo/its
> >
>





<= /div>--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Profe= ssor
Department of Software
Sungkyunkwan University
Office: +82-31= -299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skk= u.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-je= ong.php

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its





--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Profe= ssor
Department of Software
Sungkyunkwan University
Office: +82-31= -299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.eduPersonal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<= br>

--001a1146998e92027b052fbb23da-- From nobody Tue Apr 5 06:50:59 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8EF12D1EB for ; Tue, 5 Apr 2016 06:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz1ooNpjXm1e for ; Tue, 5 Apr 2016 06:50:55 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C995E12D947 for ; Tue, 5 Apr 2016 06:50:54 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id g3so16855654ywa.3 for ; Tue, 05 Apr 2016 06:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vo0wjMWykfqvV+YR/yYvWiWVDBXLEKyAybEPAk7qmv8=; b=v2qkbVloYddhjy07vT3jkw2e6ELp2LGLx7pMBRmGfqBi59XqlIE2riyYeBQnvurI7N 1uugVcmXVtzVdulFIuQsRap2WCLri+Su3WvFyTnq9NP1203UItCTyPa5+mlba8PHSvAE xcOyYLVYi0z4heZlXY8ljgDH4ypcVG/nvMXFX0HUSwYEoEQYOc+GL0b8xI9r/6Z5kVKm sIAsOaMyBTSLqWWVkNvca8DPQHWQdbKrh91Dbm0DkkuOwS+BJaF/4TiHehONe/NS4ocg DCf12sARjzoRS4pFHUqCpW6mxfH77bfrrQcoB0eZJqRQ8L7ptDp7qxBByINbn8zhWGPu nhMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vo0wjMWykfqvV+YR/yYvWiWVDBXLEKyAybEPAk7qmv8=; b=et4K2PMYL08mM07w4jR0zPfYrq+H3SBYjqDh1/87B5nZXHyjqYgSdS9RtjKgABj3el atyZvBNnw81bEmchOvL6beMOGDw965U50sGFmXLe0XftHkJw7f2bjZPwxMYTcDOz9fc6 iyubqm2rOA3rkuoeZQP5t7rLeNDzR8ef9VgUKTsi5XZNH4ePVCrY2PzhFR5ztWgqjImT Di9ehdGnAzveol/EZ3hJl//K9TxKuU3xqKE4Bk46yBANFSYtV4EfIKwFX4S5kmjlwSie nRBfAuK+WKG2SAD0fSzWOB0CmAliijPKnO3FxI7Gc7TM2tn67EXpJWTg4AhjZ9ZYmEjM Decw== X-Gm-Message-State: AD7BkJJ9vzoO3MBMYyo1rLl75KqN9KCxD1z5HKI7m+51tYcoz/ZIXY1ctG/rkq6Xk+ewMCAgnQMPzXkJCFCfnQ== X-Received: by 10.37.42.83 with SMTP id q80mr12996431ybq.27.1459864253889; Tue, 05 Apr 2016 06:50:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.4.22 with HTTP; Tue, 5 Apr 2016 06:50:24 -0700 (PDT) In-Reply-To: References: From: "Mr. Jaehoon Paul Jeong" Date: Tue, 5 Apr 2016 10:50:24 -0300 Message-ID: To: Nabil Benamar Content-Type: multipart/alternative; boundary=001a11440486460775052fbd22d8 Archived-At: Cc: Thierry Ernst , "its@ietf.org" , knut.evensen@q-free.com, "Dr. Hans-Joachim Fischer" , Alexandre Petrescu , Richard Roy Subject: Re: [its] Comments for a New Draft of Problem Statement for V2I Networking X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 13:50:58 -0000 --001a11440486460775052fbd22d8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nabil, I will replace Site-local addresses with ULA in the revision. For DHCPv6, I will replace autoconfiguration with configuration as follows: As an alternative protocol, DHCPv6 (or Stateless DHCPv6) can also be used for the IPv6 host address configuration [RFC3315][RFC3736]. Thanks. Paul On Tue, Apr 5, 2016 at 8:28 AM, Nabil Benamar wrote: > Hi Jaehoon, > > Best regards > Nabil Benamar > ------------------- > =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 > > http://nabilbenamar.ipv6-lab.net/ > > On Mon, Apr 4, 2016 at 10:55 PM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > >> Hi Nabil, >> Thanks for your good comments. >> >> I answers your questions and comments in lines with "=3D>" below. >> >> On Sat, Apr 2, 2016 at 5:04 PM, Nabil Benamar >> wrote: >> >>> Hi Jaehoon, >>> >>> Here are some comments: >>> >>> *Introduction* >>> >>> >>> * =E2=80=9C Recently,=E2=80=A6..=E2=80=9D This is not recent since th= e works on VANETs and its >>> use cases have been done for a while =E2=80=A6 such as driving safety, = efficient >>> driving, and entertainment! There are a lot of journal papers tackling = in >>> details this topic.* >>> >>> *This section can be modified as follows: * >>> >>> *Vehicular Networks have become a popular topic during the last years >>> due to the important applications that can be realized in such environm= ent.* >>> >> *=3D> Will be reflected on the revision.* >>> >>> *=E2=80=9C =E2=80=A6 with a consideration of the vehicular network's ch= aracteristics >>> such as a vehicle's velocity and collision avoidance.=E2=80=9D * >>> >> *Collision avoidance is a consequence and a goal to attend and not a >>> characteristic of this IEEE standard.* >>> >>> *=3D> You are right. I will update it as follows: =E2=80=9C... with a >>> consideration of the vehicular network's characteristics such as a >>> vehicle's velocity and its directed movement along a roadway.=E2=80=9D* >>> >>> >>> >> *=E2=80=9C=E2=80=A6.IPv6 [RFC2460] is suitable for vehicular networks si= nce the protocol >>> has* >>> >>> * abundant address space, autoconfiguration features, and protocol >>> extension ability through extension headers.=E2=80=9D* >>> >>> >>> *Better to mention the draft >>> =E2=80=98https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-03 >>> =E2=80= =99 as a >>> supporting reference here.* >>> >> *=3D> Will be reflected on the revision.* >>> >>> >>> >> *=E2=80=9Cit is assumed that the prefix assignment for each subnet insid= e* >>> >>> * the vehicle's mobile network and the RSU's infra-node network >>> through* >>> >>> * a prefix delegation protocol.=E2=80=9D* >>> >>> >>> *Prefex delegation is only possible through DHCPv6-PD, is this what you >>> mean ? * >>> >> >> >> *=3D> Yes, DHCPv6-PD can be used as a solution. We may invent another on= e >> for vehicular networks.** Also, prefix configuration can be manually >> done at the manufacturing time as factory default.* >> >>> >>> *=E2=80=9CAlso, the DNS naming service should be supported for the* >>> >>> * DNS name resolution for a host or server in either the vehicle's* >>> >>> * mobile network or the RSU's infra-node network.=E2=80=9D* >>> >>> >>> *So what could be the issue here ? Is DNS an issue? DNS information are >>> included in RA with the flag =E2=80=9CO=E2=80=9D enabled. * >>> >> *=3D> We need to consider three issues, such as IPv6 host DNS >>> configuration, DNS name resolution, and DNS name autoconfiguration. * >>> >> *The first is IPv6 host DNS configuration for Recursive DNS Server >>> (RDNSS) and DNS Search List (DNSSL) t**hrough RA Options (RFC 6106) and >>> DHCP Options (RFC 3646).* >>> >>> *The second is DNS name resolution through an appropriate RDNSS w**ithi= n >>> a vehicle=E2=80=99s moving network or an RSU=E2=80=99s fixed network. * >>> >>> *The third is DNS name autoconfiguration of vehicle and in-vehicle >>> devices t**hrough DNSNA (draft-jeong-its-iot-dns-autoconf-00), mDNS >>> (RFC 6762), and DNS Update (RFC 2136).* >>> >>> >>> *=E2=80=9CThe former approach is* >>> >>> * usually used by Mobile Ad Hoc Networks (MANET) for a separate multi= -* >>> >>> * link subnet.=E2=80=9D* >>> >>> >>> *Site local addressing is deprecated RFC 3879=E2=80=A6so no need to men= tion it >>> in the current draft. * >>> >> *=3D> Yes, Site-local addressing will be replaced by Unique Local IPv6 >>> Addresses (ULA) in RFC 4193.* >>> >> > =E2=80=8BIndeed, site local have already been replaced by ULAs=E2=80=8B > > >> >>> *=E2=80=9CDHCPv6 (or Stateless DHCPv6) can be used for the IP address* >>> >>> * autoconfiguration [RFC3315][RFC3736] =E2=80=9C * >>> >> *=3D> **As an alternative protocol, DHCPv6 (or Stateless DHCPv6) can als= o >>> be used for the IP address **autoconfiguration [RFC3315][RFC3736].* >>> >>> *There is no more autoconfiguration when we use DHCPv6=E2=80=A6So this = sentence >>> should be corrected accordingly. * >>> >> *=3D> What do you mean by "**There is no more autoconfiguration when we >>> use DHCPv6**"?* >>> >> =E2=80=8BI mean that when you use DHCPv6 that means that your DHCP sever= will > send all the configuration =E2=80=8Bdetails needed (IPv6@ + prefix length= +gw + > @DNS) if the M flag is enabled, which means that there is no "auto" > configuration! So the term "auto" in this case should be removed. > >> *I intend that DHCPv6 can be used for an IPv6 host's address >>> autoconfiguration instead of RA. * >>> >> *Thanks. * >>> >> *Best Regards,* >>> >> *Paul* >>> >> >> >>> Best regards >>> Nabil Benamar >>> ------------------- >>> =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 >>> >>> http://nabilbenamar.ipv6-lab.net/ >>> >>> On Wed, Feb 24, 2016 at 8:57 AM, Mr. Jaehoon Paul Jeong < >>> jaehoon.paul@gmail.com> wrote: >>> >>>> Hi Richard, >>>> I will check the IOS standards related to ITS, which are pointed by yo= u. >>>> >>>> I agree with you that you need to use well-known terminology for our >>>> ITS work. >>>> >>>> For 802.11p, as I know, both industry and academia are considering it >>>> as >>>> Dedicated Short-Range Communications (DSRC) for vehicular networking. >>>> >>>> Thanks. >>>> >>>> Best Regards, >>>> Paul >>>> >>>> >>>> On Thu, Feb 18, 2016 at 6:24 AM, Richard Roy >>>> wrote: >>>> >>>>> Alex/Paul, >>>>> >>>>> I suspect much of what you are thinking needs standardization below h= as >>>>> already been standardized. You might want to check out ISO 21217 (IT= S >>>>> station/communication architecture), followed by ISO 21210 (IPv6 >>>>> networking >>>>> for ITS). If nothing else, we already have terms for all of the >>>>> configurations you describe below (see ISO 21217). It would be best = to >>>>> stick with this now well-known terminology. >>>>> >>>>> By the way, none of this depends on 802.11 5.9GHz in the data link an= d >>>>> physical layers. I continue to wonder why 802.11p ever comes up. It >>>>> could >>>>> just as well be 5.4GHz BRAN, 2.4GHz ISM, IR, tin can and a string, or >>>>> whatever ... >>>>> >>>>> Cheers, >>>>> >>>>> RR >>>>> >>>>> > -----Original Message----- >>>>> > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] >>>>> > Sent: Wednesday, February 17, 2016 4:22 AM >>>>> > To: Mr. Jaehoon Paul Jeong >>>>> > Cc: its@ietf.org >>>>> > Subject: Re: [its] Comments for a New Draft of Problem Statement fo= r >>>>> V2I >>>>> > Networking >>>>> > >>>>> > Hello Paul, >>>>> > >>>>> > Thanks a lot for this draft. This V2I problem statement covers man= y >>>>> > things we have discussed in Yokohama. >>>>> > >>>>> > What do the others think about this draft? >>>>> > >>>>> > I hame some comments, see below. >>>>> > >>>>> > Le 15/02/2016 17:30, Mr. Jaehoon Paul Jeong a =C3=A9crit : >>>>> > > Hi ITS Colleagues, >>>>> > > >>>>> > > Title: Problem Statement for Vehicle-to-Infrastructure Networking >>>>> > > I-D: draft-jeong-its-v2i-problem-statement-00 Link: >>>>> > > >>>>> https://tools.ietf.org/html/draft-jeong-its-v2i-problem-statement-00 >>>>> > > >>>>> > > Abstract This document specifies the problem statement for >>>>> > > IPv6-based vehicle- to-infrastructure networking. Dedicated >>>>> > > Short-Range Communications (DSRC) is standardized as IEEE 802.11p >>>>> for >>>>> > > the wireless media access in vehicular networks. This document >>>>> > > addresses the extension of IPv6 as the network layer protocol in >>>>> > > vehicular networks and is focused on the networking issues in >>>>> > > one-hop communication between a Road-Side Unit (RSU) and vehicle. >>>>> > > The RSU is connected to the Internet and allows vehicles to have >>>>> the >>>>> > > Internet access if connected. The major issues of including IPv6 >>>>> in >>>>> > > vehicular networks are neighbor discovery protocol, stateless >>>>> > > address autoconfiguration, and DNS configuration for the Internet >>>>> > > connectivity over DSRC. Also, when the vehicle and the RSU have = an >>>>> > > internal network, respectively, the document discusses the issues >>>>> of >>>>> > > internetworking between the vehicle's internal network and the >>>>> RSU's >>>>> > > internal network. >>>>> > > >>>>> > > If you have comments or questions, please let me know. >>>>> > >>>>> > You can use the documentation prefixes 2001:db8:1000::/63 (instead = of >>>>> > real addresses like 2001:1000::/63). >>>>> > >>>>> > The term "RSU infra-node network" is something new and may need to = be >>>>> > present in the definitions section. >>>>> > >>>>> > If I understand you correctly, the RSU infra-node network is a >>>>> network >>>>> > of IP-addressable devices which are present in the Road-Side Unit - >>>>> right? >>>>> > >>>>> > I am asking because I know some such RSUs on the market which conta= in >>>>> > several IP-addressable devices linked together, but we dont have a >>>>> name >>>>> > for them. The "RSU infra-node network" sounds good, I think. >>>>> > >>>>> > For the term "mobile network" - we can rather use maybe >>>>> > "moving network". >>>>> > >>>>> > In section 5 "Internetworking between the Vehicle and RSU networks"= : >>>>> > > Problems are a prefix discovery and prefix exchange. The prefix >>>>> > > discovery is defined as how routers in a mobile network discover >>>>> > > prefixes in the mobile network. The prefix exchange is defined a= s >>>>> > > how the vehicle and the RSU exchange their prefixes with each >>>>> other. >>>>> > >>>>> > I agree with the problem of prefix exchange. >>>>> > >>>>> > For the "prefix discovery", I have some doubts. >>>>> > >>>>> > First, the routers inside the moving network can be pre-configured >>>>> with >>>>> > the prefixes inside that moving network. If so, then there can be = no >>>>> > need for these routers to discover the prefixes inside the same >>>>> moving >>>>> > network. But, of course, if they are not preconfigured then they >>>>> have >>>>> > to be discovered somehow. >>>>> > >>>>> > Second, there is a need for one router (the mobile router?) in the >>>>> > moving network to discover several parameters of a nearby moving >>>>> > network, and also the parameters of a "RSU infra-node network". >>>>> These >>>>> > parameters, including the IP prefix of the other network, are liste= d >>>>> in >>>>> > draft-petrescu-its-problem-01 section 3.1 "Discovery Sub-Problem". >>>>> It >>>>> > would be good to use same terminology for this discovery. >>>>> > >>>>> > > This section discusses IP addressing for V2I networking. There a= re >>>>> > > two policies for IPv6 addressing in vehicular networks. The one >>>>> > > policy is to use site-local IPv6 addresses for vehicular networks >>>>> > > [RFC4291]. >>>>> > >>>>> > Since the site-local IPv6 addresses (fec0::) have been deprecated, = it >>>>> > would be appropriate to mention "Unique Local Addresses" (ULAs) whi= ch >>>>> > can somehow play the role that seems to be needed here. I suggest = to >>>>> > substitute ULA for site-local addresses. >>>>> > >>>>> > > The former approach is >>>>> > > usually used by Mobile Ad Hoc Networks (MANET) for a separate >>>>> multi- >>>>> > > link subnet. >>>>> > >>>>> > MANET has a certain meaning at IETF: it's the WG MANET. I dont thi= nk >>>>> > there is any MANET draft that recommends ULAs (but maybe they >>>>> recommend >>>>> > site-locals?). Maybe ask the MANET WG what is the MANET IP >>>>> Addressing >>>>> > Architecture (do they use ULAs? do they use GUA - globals?). If y= es >>>>> > then refer to MANET WG document here. >>>>> > >>>>> > > Sections 7 ND, 8 address autoconf, 9 DNS >>>>> > >>>>> > I agree with these sections 7, 8 and 9. >>>>> > >>>>> > > 10. IP Mobility Support >>>>> > > >>>>> > > This section discusses an IP mobility support in V2I >>>>> networking. In >>>>> > > a single subnet per RSU, vehicles keep crossing the >>>>> communication >>>>> > > coverages of adjacent RSUs. During this crossing, TCP/UDP >>>>> sessions >>>>> > > can be maintained through IP mobility support, such as Mobile >>>>> IPv6 >>>>> > > [RFC6275]. Since vehicles move fast along roadways, this high >>>>> speed >>>>> > > should be configured for a parameter configuration in Mobile >>>>> IPv6. >>>>> > > >>>>> > > To support the mobility of a vehicle's mobile network, Network >>>>> > > Mobility (NEMO) protocol can be used [RFC3963]. Like Mobile >>>>> IPv6, >>>>> > > the high speed of vehicles should be considered for a paramete= r >>>>> > > configuration in NEMO. >>>>> > >>>>> > I agree. >>>>> > >>>>> > I would like to add the following: >>>>> > >>>>> > 1. When Mobile IPv6/NEMO is used by the Mobile Router connected to >>>>> > the RSU infra-node a tunnel is established between the MR and i= ts >>>>> > Home Agent in the TCC (Traffic Control Center). If a node insi= de >>>>> > the moving network (not the MR) needs to exchange data with a >>>>> node >>>>> > within the RSU infra-node network then that communication must >>>>> > go through the Home Agent. The delays on the path to the HA ma= y >>>>> be >>>>> > too high for the reactivity needed between a vehicle and an RSU= , >>>>> or >>>>> > the path can even be blocked. For this reason it is necessary = to >>>>> > accommodate direct communications (skip the HA) between a node = in >>>>> > the moving network and a node in the RSU infra-node network. >>>>> This >>>>> > can be achieved only if the two networks learn each other's >>>>> prefixes. >>>>> > >>>>> > 2. A new method of connecting the moving network directly to the RS= U >>>>> > infra-node network may lead to modifying the addressing >>>>> architecture >>>>> > in the moving network. This can become a problem to the use of >>>>> > Mobile IP, because Mobile IP relies on the addressing >>>>> architecture >>>>> > controlled by the Home Agent. This problem should be solved as >>>>> well. >>>>> > >>>>> > >>>>> > In section 11 Security Considerations: >>>>> > > 11. Security Considerations >>>>> > > >>>>> > > The security is very important in vehicular networks for V2I >>>>> > > networking. Only valid vehicles should be allowed to use V2I >>>>> > > networking in vehicular networks. VIN and a user certificate >>>>> can be >>>>> > > used to authenticate a vehicle and the user. >>>>> > > >>>>> > > This document shares all the security issues of the neighbor >>>>> > > discovery protocol. This document can get benefits from secur= e >>>>> > > neighbor discovery (SEND) [RFC3971] >>>>> > >>>>> > Recent works in security for vehicular networks mention two >>>>> additional >>>>> > things that are worth considering: >>>>> > >>>>> > 1. the use of TLS certificates for vehicle communications >>>>> > draft-lonc-tls-certieee1609-01 >>>>> > >>>>> > 2. privacy considerations: a new ETSI activity may consider privacy >>>>> > aspects of identifier generation in vehicular communications. >>>>> > >>>>> > It is worth referring to these aspects (give references). >>>>> > >>>>> > Yours, >>>>> > >>>>> > Alex >>>>> > >>>>> > >>>>> > >>>>> > > >>>>> > > Thanks. >>>>> > > >>>>> > > Best Regards, Paul -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. Jaehoon >>>>> (Paul) >>>>> > > Jeong, Ph.D. Assistant Professor Department of Software >>>>> Sungkyunkwan >>>>> > > University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>>>> > > , pauljeong@skku.edu >>>>> > > Personal Homepage: >>>>> > > http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>> > > >>>>> > > >>>>> > > >>>>> > > _______________________________________________ its mailing list >>>>> > > its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> > > >>>>> > >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>>> Assistant Professor >>>> Department of Software >>>> Sungkyunkwan University >>>> Office: +82-31-299-4957 >>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>> >>>> >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>> >> >> >> -- >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Assistant Professor >> Department of Software >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >> >> > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a11440486460775052fbd22d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nabil,
I will replace Site-local addresses with ULA in= the revision.

For DHCPv6, I will replace autoconf= iguration with configuration as follows:

As an alt= ernative protocol, DHCPv6 (or Stateless DHCPv6) can also be used for the IP= v6 host address configuration [RFC3315][RFC3736].

<= div>Thanks.

Paul

On Tue, Apr 5, 2016 at 8:28 AM, Nabil B= enamar <benamar73@gmail.com> wrote:
Hi Jaehoon,

Best re= gards
Nabil Benamar
-------------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85= =D8=B1=D9=88

<= /div>

On Mon, Apr 4, 2016 = at 10:55 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:
Hi Nabil,
Thanks= for your good comments.

I answers your questions = and comments in lines with "=3D>" below.

On = Sat, Apr 2, 2016 at 5:04 PM, Nabil Benamar <benamar73@gmail.com><= /span> wrote:
Hi Jaehoon,

Here are some c= omments:

Introduction


=C2=A0 =E2=80=9C Recently,=E2=80=A6..=E2=80=9D=C2=A0 This is not r= ecent since the works on VANETs and its use cases have been done for a whil= e =E2=80=A6 such as driving safety, efficient driving, and entertainment! T= here are a lot of journal papers tackling in details this topic.

This section can be modified as follows:=C2=A0

Vehicular Networks have become a popular topic during the last yea= rs due to the important applications that can be realized in such environme= nt.

=3D> Will be reflected on the revision.

<= span>

=E2=80=9C =E2=80=A6 with a consideration of the vehicular network&= #39;s characteristics such as a vehicle's velocity and collision avoida= nce.=E2=80=9D=C2=A0

Collision avoidan= ce is a consequence and a goal to attend and not a characteristic of this I= EEE standard.

= =3D> You are right. I will update it as follows: =E2=80=9C... with a con= sideration of the vehicular network's characteristics such as a vehicle= 's velocity and its directed movement along a roadway.=E2=80=9D
<= /p>

=C2=A0 =C2=A0 =C2=A0

=E2=80=9C=E2=80=A6.IPv6 [RFC2460] is suitable for vehicular networ= ks since the protocol has

=C2=A0=C2=A0 abundant address space, autoconfiguration features, a= nd protocol extension ability through extension headers.=E2=80=9D


Better to mention the draft =E2=80=98https://too= ls.ietf.org/html/draft-petrescu-ipv6-over-80211p-03=E2=80=99 =C2=A0 as = a supporting reference here.

=

=3D> Will be reflected on the = revision.=C2=A0=C2=A0

=C2= =A0

=E2=80=9Cit is assumed that the prefix assignment for each subnet ins= ide

=C2=A0=C2=A0 the vehicle's mobile network and the RSU's infra= -node network through

=C2=A0=C2=A0 a prefix delegation protocol.=E2=80=9D


Prefex delegation is only possible through DHCPv6-PD, is this what yo= u mean ?

=C2=A0=C2=A0=3D> Yes, DHCPv6-P= D can be used as a solution. We may invent another one for
=C2=A0 vehicular networks.<= br>=C2=A0 Also, prefix configuration can be manually done at the m= anufacturing time as factory default.=C2=A0 =C2=A0
<= span>


=E2=80=9CAlso, the DNS naming service should be supported for the=

=C2=A0=C2=A0 DNS name resolution for a host or server in either the v= ehicle's

=C2=A0=C2=A0 mobile network or the RSU's infra-node network.=E2= =80=9D


So what could be the issue here ? Is DNS an issue? DNS information ar= e included in RA with the flag =E2=80=9CO=E2=80=9D enabled.

=

=3D> We need to consider three issues, such as I= Pv6 host DNS configuration, DNS name resolution, and DNS name autoconfigura= tion.=C2=A0

The first is IPv6 host DNS configuration for Re= cursive DNS Server (RDNSS) and DNS Search List (DNSSL) through RA Options = (RFC 6106) and DHCP Options (RFC 3646).

The second is DNS name resolution through an= appropriate RDNSS within a vehicle=E2=80=99s moving network or an RSU=E2= =80=99s fixed network.=C2=A0

The third is DNS name autoconfiguration of vehicle = and in-vehicle devices through DNSNA (draft-jeong-its-iot-dns-autoconf-00)= , mDNS (RFC 6762), and DNS Update (RFC 2136).


=E2=80=9CThe former approach is

=C2=A0=C2=A0 usually used by Mobile Ad Hoc Networks (MANET) for a sep= arate multi-

=C2=A0=C2=A0 link subnet.=E2=80=9D


Site local addressing is deprecated RFC 3879=E2=80=A6so no need to= mention it in the current draft.=C2=A0

=3D> Yes, Site-loca= l addressing will be replaced by Unique Local IPv6 Addresses (ULA) in RFC 4= 193.

=

=E2=80= =8BIndeed, site local have already been replaced by ULAs=E2=80=8B
=C2= =A0


=E2=80=9CDHCPv6 (or Stateless D= HCPv6) can be used for the IP address

=C2=A0=C2=A0 autoconfiguration [RFC3315][RFC3736] =E2=80=9C

=3D>=C2=A0As an alternative protocol, DHCPv6 (or State= less DHCPv6) can also be used for the IP address=C2=A0autoconfiguration = [RFC3315][RFC3736].

There is no more autoconfiguration when we use DHCPv6=E2=80=A6So t= his sentence should be corrected accordingly. =C2=A0

<= /div>

=3D> What do you mean by "There is no more a= utoconfiguration when we use DHCPv6"?

=E2=80=8BI mean that when you use DHCPv6 that means that you= r DHCP sever will send all the configuration =E2=80=8Bdetails needed (IPv6@= + prefix length +gw + @DNS) if the M flag is enabled, which means that the= re is no "auto" configuration! So the term "auto" in th= is case should be removed.

=

I intend= that DHCPv6 can be used for an IPv6 host's address autoconfiguration i= nstead of RA.

Thanks.

Bes= t Regards,

Paul=C2=A0

=
=C2=A0=C2=A0
Best regards
Nabil Benamar
-------------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9= =88


On Wed, Feb 24, 2016 at 8:57 AM, Mr. Jaehoon= Paul Jeong <jaehoon.paul@gmail.com> wrote:
Hi Richard,
I will check the IOS standards re= lated to ITS, which are pointed by you.

I agree wi= th you that you need to use well-known terminology for our ITS work.
<= div>
For 802.11p, as I know, both industry and academia are c= onsidering it as=C2=A0
Dedicated Short-Range Communications (DSRC= ) for vehicular networking.=C2=A0

Thanks.

Best Regards,
Paul


On Thu, Feb 18= , 2016 at 6:24 AM, Richard Roy <dickroy@alum.mit.edu> wro= te:
Alex/Paul,

I suspect much of what you are thinking needs standardization below has
already been standardized.=C2=A0 You might want to check out ISO 21217 (ITS=
station/communication architecture), followed by ISO 21210 (IPv6 networking=
for ITS).=C2=A0 If nothing else, we already have terms for all of the
configurations you describe below (see ISO 21217).=C2=A0 It would be best t= o
stick with this now well-known terminology.

By the way, none of this depends on 802.11 5.9GHz in the data link and
physical layers.=C2=A0 I continue to wonder why 802.11p ever comes up.=C2= =A0 It could
just as well be 5.4GHz BRAN, 2.4GHz ISM, IR, tin can and a string, or
whatever ...

Cheers,

RR

> -----Original Message-----
> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
> Sent: Wednesday, February 17, 2016 4:22 AM
> To: Mr. Jaehoon Paul Jeong
> Cc: its@ietf.org=
> Subject: Re: [its] Comments for a New Draft of Problem Statement for V= 2I
> Networking
>
> Hello Paul,
>
> Thanks a lot for this draft.=C2=A0 This V2I problem statement covers m= any
> things we have discussed in Yokohama.
>
> What do the others think about this draft?
>
> I hame some comments, see below.
>
> Le 15/02/2016 17:30, Mr. Jaehoon Paul Jeong a =C3=A9crit :
> > Hi ITS Colleagues,
> >
> > Title: Problem Statement for Vehicle-to-Infrastructure Networking=
> > I-D: draft-jeong-its-v2i-problem-statement-00 Link:
> > https://tools.ietf.org= /html/draft-jeong-its-v2i-problem-statement-00
> >
> > Abstract This document specifies the problem statement for
> > IPv6-based vehicle- to-infrastructure networking.=C2=A0 Dedicated=
> > Short-Range Communications (DSRC) is standardized as IEEE 802.11p= for
> > the wireless media access in vehicular networks.=C2=A0 This docum= ent
> > addresses the extension of IPv6 as the network layer protocol in<= br> > > vehicular networks and is focused on the networking issues in
> > one-hop communication between a Road-Side Unit (RSU) and vehicle.=
> > The RSU is connected to the Internet and allows vehicles to have = the
> > Internet access if connected.=C2=A0 The major issues of including= IPv6 in
> > vehicular networks are neighbor discovery protocol, stateless
> > address autoconfiguration, and DNS configuration for the Internet=
> > connectivity over DSRC.=C2=A0 Also, when the vehicle and the RSU = have an
> > internal network, respectively, the document discusses the issues= of
> > internetworking between the vehicle's internal network and th= e RSU's
> > internal network.
> >
> > If you have comments or questions, please let me know.
>
> You can use the documentation prefixes 2001:db8:1000::/63 (instead of<= br> > real addresses like 2001:1000::/63).
>
> The term "RSU infra-node network" is something new and may n= eed to be
> present in the definitions section.
>
> If I understand you correctly, the RSU infra-node network is a network=
> of IP-addressable devices which are present in the Road-Side Unit - ri= ght?
>
> I am asking because I know some such RSUs on the market which contain<= br> > several IP-addressable devices linked together, but we dont have a nam= e
> for them.=C2=A0 The "RSU infra-node network" sounds good, I = think.
>
> For the term "mobile network" - we can rather use maybe
> "moving network".
>
> In section 5 "Internetworking between the Vehicle and RSU network= s":
> > Problems are a prefix discovery and prefix exchange.=C2=A0 The pr= efix
> > discovery is defined as how routers in a mobile network discover<= br> > > prefixes in the mobile network.=C2=A0 The prefix exchange is defi= ned as
> > how the vehicle and the RSU exchange their prefixes with each oth= er.
>
> I agree with the problem of prefix exchange.
>
> For the "prefix discovery", I have some doubts.
>
> First, the routers inside the moving network can be pre-configured wit= h
> the prefixes inside that moving network.=C2=A0 If so, then there can b= e no
> need for these routers to discover the prefixes inside the same moving=
> network.=C2=A0 But, of course, if they are not preconfigured then they= have
> to be discovered somehow.
>
> Second, there is a need for one router (the mobile router?) in the
> moving network to discover several parameters of a nearby moving
> network, and also the parameters of a "RSU infra-node network&quo= t;.=C2=A0 These
> parameters, including the IP prefix of the other network, are listed i= n
> draft-petrescu-its-problem-01 section 3.1 "Discovery Sub-Problem&= quot;.=C2=A0 It
> would be good to use same terminology for this discovery.
>
> > This section discusses IP addressing for V2I networking.=C2=A0 Th= ere are
> > two policies for IPv6 addressing in vehicular networks.=C2=A0 The= one
> > policy is to use site-local IPv6 addresses for vehicular networks=
> > [RFC4291].
>
> Since the site-local IPv6 addresses (fec0::) have been deprecated, it<= br> > would be appropriate to mention "Unique Local Addresses" (UL= As) which
> can somehow play the role that seems to be needed here.=C2=A0 I sugges= t to
> substitute ULA for site-local addresses.
>
> > The former approach is
> >=C2=A0 =C2=A0 usually used by Mobile Ad Hoc Networks (MANET) for a= separate multi-
> >=C2=A0 =C2=A0 link subnet.
>
> MANET has a certain meaning at IETF: it's the WG MANET.=C2=A0 I do= nt think
> there is any MANET draft that recommends ULAs (but maybe they recommen= d
> site-locals?).=C2=A0 Maybe ask the MANET WG what is the MANET IP Addre= ssing
> Architecture (do they use ULAs?=C2=A0 do they use GUA - globals?).=C2= =A0 If yes
> then refer to MANET WG document here.
>
>=C2=A0 > Sections 7 ND, 8 address autoconf, 9 DNS
>
> I agree with these sections 7, 8 and 9.
>
> > 10.=C2=A0 IP Mobility Support
> >
> >=C2=A0 =C2=A0 This section discusses an IP mobility support in V2I= networking.=C2=A0 In
> >=C2=A0 =C2=A0 a single subnet per RSU, vehicles keep crossing the = communication
> >=C2=A0 =C2=A0 coverages of adjacent RSUs.=C2=A0 During this crossi= ng, TCP/UDP sessions
> >=C2=A0 =C2=A0 can be maintained through IP mobility support, such = as Mobile IPv6
> >=C2=A0 =C2=A0 [RFC6275].=C2=A0 Since vehicles move fast along road= ways, this high speed
> >=C2=A0 =C2=A0 should be configured for a parameter configuration i= n Mobile IPv6.
> >
> >=C2=A0 =C2=A0 To support the mobility of a vehicle's mobile ne= twork, Network
> >=C2=A0 =C2=A0 Mobility (NEMO) protocol can be used [RFC3963].=C2= =A0 Like Mobile IPv6,
> >=C2=A0 =C2=A0 the high speed of vehicles should be considered for = a parameter
> >=C2=A0 =C2=A0 configuration in NEMO.
>
> I agree.
>
> I would like to add the following:
>
> 1. When Mobile IPv6/NEMO is used by the Mobile Router connected to
>=C2=A0 =C2=A0 =C2=A0the RSU infra-node a tunnel is established between = the MR and its
>=C2=A0 =C2=A0 =C2=A0Home Agent in the TCC (Traffic Control Center).=C2= =A0 If a node inside
>=C2=A0 =C2=A0 =C2=A0the moving network (not the MR) needs to exchange d= ata with a node
>=C2=A0 =C2=A0 =C2=A0within the RSU infra-node network then that communi= cation must
>=C2=A0 =C2=A0 =C2=A0go through the Home Agent.=C2=A0 The delays on the = path to the HA may be
>=C2=A0 =C2=A0 =C2=A0too high for the reactivity needed between a vehicl= e and an RSU, or
>=C2=A0 =C2=A0 =C2=A0the path can even be blocked.=C2=A0 For this reason= it is necessary to
>=C2=A0 =C2=A0 =C2=A0accommodate direct communications (skip the HA) bet= ween a node in
>=C2=A0 =C2=A0 =C2=A0the moving network and a node in the RSU infra-node= network.=C2=A0 This
>=C2=A0 =C2=A0 =C2=A0can be achieved only if the two networks learn each= other's prefixes.
>
> 2. A new method of connecting the moving network directly to the RSU >=C2=A0 =C2=A0 =C2=A0infra-node network may lead to modifying the addres= sing architecture
>=C2=A0 =C2=A0 =C2=A0in the moving network.=C2=A0 This can become a prob= lem to the use of
>=C2=A0 =C2=A0 =C2=A0Mobile IP, because Mobile IP relies on the addressi= ng architecture
>=C2=A0 =C2=A0 =C2=A0controlled by the Home Agent.=C2=A0 This problem sh= ould be solved as well.
>
>
> In section 11 Security Considerations:
> > 11.=C2=A0 Security Considerations
> >
> >=C2=A0 =C2=A0 The security is very important in vehicular networks= for V2I
> >=C2=A0 =C2=A0 networking.=C2=A0 Only valid vehicles should be allo= wed to use V2I
> >=C2=A0 =C2=A0 networking in vehicular networks.=C2=A0 VIN and a us= er certificate can be
> >=C2=A0 =C2=A0 used to authenticate a vehicle and the user.
> >
> >=C2=A0 =C2=A0 This document shares all the security issues of the = neighbor
> >=C2=A0 =C2=A0 discovery protocol.=C2=A0 This document can get bene= fits from secure
> >=C2=A0 =C2=A0 neighbor discovery (SEND) [RFC3971]
>
> Recent works in security for vehicular networks mention two additional=
> things that are worth considering:
>
> 1. the use of TLS certificates for vehicle communications
>=C2=A0 =C2=A0 =C2=A0draft-lonc-tls-certieee1609-01
>
> 2. privacy considerations: a new ETSI activity may consider privacy >=C2=A0 =C2=A0 =C2=A0aspects of identifier generation in vehicular commu= nications.
>
> It is worth referring to these aspects (give references).
>
> Yours,
>
> Alex
>
>
>
> >
> > Thanks.
> >
> > Best Regards, Paul -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. Jaehoon (Paul)
> > Jeong, Ph.D. Assistant Professor Department of Software Sungkyunk= wan
> > University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com
> > <mailto:jaehoon.paul@gmail.com>, pauljeong@skku.edu
> > <mailto:pauljeong@skku.edu> Personal Homepage:
> > http://iotlab.skku.edu/people-jaehoon-jeo= ng.php
> > <http://cpslab.skku.edu/people-jaehoon-j= eong.php>
> >
> >
> > _______________________________________________ its mailing list<= br> > > its@ietf.org https://www.ietf.org/mailman/listinfo/its
> >
>





<= /div>--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Profe= ssor
Department of Software
Sungkyunkwan University
Office: +82-31= -299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skk= u.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-je= ong.php

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its





--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assist= ant Professor
Department of Software
Sungkyunkwan University
Offic= e: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.e= du
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong= .php




--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant ProfessorDepartment of Software
Sungkyunkwan University
Office: +82-31-299-4= 957
Email: j= aehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu<= br>Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
--001a11440486460775052fbd22d8-- From nobody Wed Apr 6 11:24:22 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4D612D645 for ; Wed, 6 Apr 2016 11:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c03xDAaewc0Z for ; Wed, 6 Apr 2016 11:24:19 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C26112D129 for ; Wed, 6 Apr 2016 11:24:19 -0700 (PDT) Received: from [31.133.180.15] (dhcp-b40f.meeting.ietf.org [31.133.180.15]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u36IOEoR032485 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Apr 2016 11:24:16 -0700 To: Russ Housley , Erik Nordmark References: <56F08D7C.4080208@acm.org> From: Erik Nordmark Message-ID: <5705544E.6090005@sonic.net> Date: Wed, 6 Apr 2016 15:24:14 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVZM2egmF/pZ7myU3NhE5AKqxTHVrF/5coQtQeXsb2q8MthVYmHNhH/dcYMPLj2oXiY52Jp0f55D9qi9NLO8RO0H X-Sonic-ID: C;zltyxCT85RGdHMgVZbXa/Q== M;8qs0xST85RGdHMgVZbXa/Q== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: its@ietf.org Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:24:20 -0000 On 3/25/16 2:04 PM, Russ Housley wrote: > Interesting thought. As I understand the MAC address management, the MAC address is being changed every 5 minutes. Isnt there a IPv6 address construction that api;d let us construct a link-local address from that short-lived MAC address? Russ, We could use the EUI-64 derived approach (although the term EUI-64 might be misplaced here if the mac addresses end up being local MAC addresses). However, when using local MAC addresses there is some increased probability of MAC address collisions. I don't know if we need to check for duplicate addresses in the neighborhood. If we do it adds some delay to the IPv6 address acquisition; 1 second with currently standardized Duplicate Address Detection. Erik From nobody Wed Apr 6 11:53:43 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD48612D1F0 for ; Wed, 6 Apr 2016 11:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vG4OGqGi65la for ; Wed, 6 Apr 2016 11:53:41 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3997E12D0E1 for ; Wed, 6 Apr 2016 11:53:41 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 1104AF2403D for ; Wed, 6 Apr 2016 14:53:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id fbS5uagzt-dq for ; Wed, 6 Apr 2016 14:39:07 -0400 (EDT) Received: from dhcp-b4d9.meeting.ietf.org (dhcp-b4d9.meeting.ietf.org [31.133.180.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 24A05F2401F for ; Wed, 6 Apr 2016 14:53:39 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 6 Apr 2016 14:53:36 -0400 To: its@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [its] IETF 93 Plenary Presentations X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:53:42 -0000 At the mic in the ITS BoF today, Erik Nordmark mentioned the = presentations that were given in the IETF 93 Technical Plenary. It was = two presentations. Here are links for the slides: = https://www.ietf.org/proceedings/93/slides/slides-93-iab-techplenary-3.pdf= = https://www.ietf.org/proceedings/93/slides/slides-93-iab-techplenary-4.pdf= Enjoy, Russ From nobody Wed Apr 6 12:04:10 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0F212D753 for ; Wed, 6 Apr 2016 12:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH0_JwDDCUb4 for ; Wed, 6 Apr 2016 12:04:07 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4953B12D739 for ; Wed, 6 Apr 2016 12:04:07 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 3F1E9F2402E; Wed, 6 Apr 2016 15:04:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id QPFH5SDCn2r4; Wed, 6 Apr 2016 14:49:33 -0400 (EDT) Received: from dhcp-b4d9.meeting.ietf.org (dhcp-b4d9.meeting.ietf.org [31.133.180.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 19F86F2401F; Wed, 6 Apr 2016 15:04:05 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <5705544E.6090005@sonic.net> Date: Wed, 6 Apr 2016 15:04:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <025EC2EB-84F3-4B1E-A5D3-7871760AF47E@vigilsec.com> References: <56F08D7C.4080208@acm.org> <5705544E.6090005@sonic.net> To: Erik Nordmark X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: its@ietf.org Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:04:09 -0000 >> Interesting thought. As I understand the MAC address management, the = MAC address is being changed every 5 minutes. Isn=92t there a IPv6 = address construction that api;d let us construct a link-local address = from that short-lived MAC address? >=20 > We could use the EUI-64 derived approach (although the term EUI-64 = might be misplaced here if the mac addresses end up being local MAC = addresses). >=20 > However, when using local MAC addresses there is some increased = probability of MAC address collisions. I don't know if we need to check = for duplicate addresses in the neighborhood. If we do it adds some delay = to the IPv6 address acquisition; 1 second with currently standardized = Duplicate Address Detection. The time that a vehicle is in radio range of a Roadside Unit (RSU) could = easily be less than a second, so an approach that avoids duplicate = address detection is needed. Further, a vehicle could come in range = that has picked the same local MAC address and then be out of range = again in 1 second.=20 Russ= From nobody Wed Apr 6 12:54:50 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677C912D62E for ; Wed, 6 Apr 2016 12:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvcNDykwbH4P for ; Wed, 6 Apr 2016 12:54:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26CB212D561 for ; Wed, 6 Apr 2016 12:54:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D5CCF2002A for ; Wed, 6 Apr 2016 15:58:16 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D67906375A for ; Wed, 6 Apr 2016 15:54:43 -0400 (EDT) From: Michael Richardson To: its@ietf.org In-Reply-To: <025EC2EB-84F3-4B1E-A5D3-7871760AF47E@vigilsec.com> References: <56F08D7C.4080208@acm.org> <5705544E.6090005@sonic.net> <025EC2EB-84F3-4B1E-A5D3-7871760AF47E@vigilsec.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:54:49 -0000 --=-=-= Content-Type: text/plain I think that I am starting to agree that v2v and v2i communications ought to be done at link-layer, and perhaps without useful source addresses. This would be for objects that have a signature in them. I think that JOSE (or maybe COSE) is the right way to pass things around. I think that changing MAC addresses regularly is probably silly: it won't contribute to privacy at all because we will have to have higher-level identifiers that MUST be stable in order for any of things to work and be secure. Clearly all of the public vehicles and infrastructure that has some kind of privilege (i.e. ambulances, police, lamp-posts, bridge piers...) get no benefit from having MAC addresses be private; they will be saying things with clearly verifiable public keys about their location. Being pseudonymous gets them nothing in my opinion. When it comes to passing on information from vehicle to vehicle, I am thinking that the reputation of the reporting vehicle will have to be established by vehicles near them also signing the notice (with their geolocation) as they pass the info on. As such, forget about sitting on the side of the road scanning MAC addresses for location... an attacker can just collect the logs from any place, and find out where each vehicle was from their signed geolocation... Are there (traffic) advantages that I can get by taking a valid ambulance announcement from several dozen blocks away and relaying it forward in front of me? My suspicion is that many creators of these systems assume all vehicles will be trustworthy, and no systems will ever be compromised. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwVpgICLcPvd0N1lAQJDVwf9FJBwbmrDkKeuN1G0YoPh+topFZGa4OUr TGCiNUlV9DsYeshrz1Lga/9h/3itZXqzheBrqwgh6ZWIbE2ecCLCYnbKnXtxGaXA m9Q4M7XLjRwCUN4xFoJwqg2II3xpFA+m/kCqVCU8tGT20CV2Zb2fS0Z3GkcRcaUa yp7UUA7P+4Mbo+tEujCLciLY3dnAPBUkYJZ0AEMq9ubEJKaRpEtden91Fb2ukIsw p46JlooOnTWlG5UBab2E3rZPAGOtRmtSrk0VZ6sR+hWB/psFUdkEtjXIr6/Wr1kF wvz/0GrBd3AIDSD5Z60RkHBS+LcEKAa2blJcHkDg97jpNdHryqzfPQ== =K2u9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 6 14:45:37 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861A912D160 for ; Wed, 6 Apr 2016 14:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXPQxHhw6KI6 for ; Wed, 6 Apr 2016 14:45:32 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2949012D0EB for ; Wed, 6 Apr 2016 14:45:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u36LjS7e002593 for ; Wed, 6 Apr 2016 23:45:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 016A7204544 for ; Wed, 6 Apr 2016 23:46:38 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EA7C3204520 for ; Wed, 6 Apr 2016 23:46:37 +0200 (CEST) Received: from [132.166.84.226] ([132.166.84.226]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u36LjQk4013004 for ; Wed, 6 Apr 2016 23:45:27 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: <57058375.6050101@gmail.com> Date: Wed, 6 Apr 2016 18:45:25 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010509070304020702090603" Archived-At: Subject: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 21:45:35 -0000 This is a multi-part message in MIME format. --------------010509070304020702090603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit ITSers, Please see below the current charter. - the two Problem Statements drafts V2V and V2I joined, so there is less text in charter. - added an Item on "List of Research papers..." Erik: did I understand you correctly that there should be some item on discussing whether link-local addressing is sufficient, whether prefix exchange is necessary? Dino: should LISP be included in the gap analysis draft which includes C-ACC use-case? OR should we separate a dedicated I-D only with gap analysis including ND, MIP, AODVv2, LISP? Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle interface illustrated good enough by the words "moving network to nearby moving network communications"? Or is it better to say "the 1-IP-hop between nearby moving networks must be self-configured"? Nabil, Sandra: is it ok to have a working group item "List of Research Papers for IP in V2V and V2I communications"? Other comments? Alex ------------------------------------------------------------------ ITS (name to change) Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: WG forming Chairs: TBD Assigned Area Director: TBD Mailing list Address: its@ietf.org 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: Goal ---- The goal of this group is to standardize IP-based protocols for establishing direct and secure connectivity between moving networks, some of which could be fixed permanently or temporarily. Moving Network to Nearby Moving Network Communications ------------------------------------------------------ The group is concerned with all situations involving moving network to nearby moving network communications. For example: vehicle-to-vehicle communications, nomadic user wearing a PAN and communicating to a homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a train, or train-to-intersection signalling. Example from the automobile communications space ------------------------------------------------ Automobiles and vehicles of all types are increasingly connected to the Internet, either as vehicle-to-vehicle, vehicle-to-infra or vehicle-to-Internet. Entertainment apps enhancing comfort, reliable data exchanges for road safety, and automated driving are features coming in automobiles to hit the roads from now to year 2020. Highlighting increased safety as an immediate result of hyper-connectivity applied to vehicles, public authorities worldwide are increasingly mandating secure communication technology requirements in vehicles. Emergency apps for new instrumented ambulances carry many benefits both to the users and to society in general. Why IP? ------- Today, there are several deployed Vehicle-to-Internet technologies, including car tethering through driver's cellular smartphone. However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are still being developed. To improve on a situation of link-specific data exchanges, and enable independent application sets to share the same links, IP data exchanges are needed. Enabling IP communication between vehicles (V2V), and between vehicles and the immediate infrastructure (V2I), will provide (0) ability to reach the rest of the world on the Internet (1) short and deterministic delays, (2) fast forwarding through scalable paths of routers, (3) ease of reuse of existing Internet applications in a vehicular environment. Moving network to nearby moving network communications involve link layers such as: 802.11p OCB (Outside the Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light Communications), IrDA, LTE-D. Only the IP protocols are capable of running on each of these links and establish IP paths across them in an interoperable manner. Scenarios? ---------- There are a few scenarios exhibiting the need to communicate from one moving network to another nearby moving network. In the automobile space, the Cooperative Adaptive Cruise Control and Platooning features consider that vehicles close to each other exchange data describing their kinematic status. At the cross-roads, the moving network inside a vehicle exchanges data with the moving network in the red-light pole. Several public safety scenarios involve moving networks. Distinct organizations deploy different moving networks (in-vehicle, on-person) at an incident scene. These networks need to interoperate in order to more effectively understand and deal with the incident scene. In connected rail scenarios the moving network deployed in trains communicate with other moving networks at the cross-points. What kind of solutions? ----------------------- The current technical solutions considered to achieve moving network to nearby moving network communications are of two kinds: IP routing protocols for n-hop path management and 1-hop link-scoped IP protocol enhancements. The 1-hop link-scoped protocols include the protocols for route establishment involving ICMP Router Advertisements. The n-hop path management protocols include n-hop path establishment protocols (e.g. Babel, OSPF) and n-hop path search protocols (most notably AODV and derivates). In this proposed Working Group the focus is on 1-hop protocols, and leverage from other Working Groups for the n-hop situations. In some of the moving network applications the window of opportunity for exchanging data with the immediate infrastructure may be very short. For example, a car driving near a road-side unit may have only 5s to exchange with that RSU (depending on speed, RSU range and number). (ephemeral connections). What kind of requirements? -------------------------- The requirements for mechanisms for moving network to nearby moving network communications are focusing on low delays of the data paths, reduced number of messages for path establishment, application friendly, resilience to attacks, compatibility with DHCP and Mobile IP. In addition, some moving network to nearby moving network applications involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the 1-hop IP moving network to nearby moving netowrk mechanisms will need to gracefully support IP multicast. Due to the inherent characteristics of safety-related communications, all new moving network to nearby moving network mechanisms must afford authenticity and confidentiality where necessary. Dynamically establishing ephemeral communication paths between automobiles in public areas must offer privacy safeguards for the end users (passengers). Establishing 1-hop IP V2V paths must not break the existing on-board protocols and applications which communicate with the Internet, possibly via multiple radios. In a moving network deployed in an automobile, typically one exit point connects the moving network to other moving networks. However, in a more general manner (and to support reliability) any new mechanism of moving network to nearby moving network communications should support multi-homing: one router to use multiple interfaces towards outside the moving network, or multiple routers. Current version of Internet protocols ------------------------------------- The group will only work on IPv6 solutions. What SDOs may need this work? ----------------------------- The requirements and standards for moving network to nearby moving network communications, often involving IPv6, and novel V2V and V2Infra concepts, are developed mainly at ISO TC204 "Intelligent Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For Vehicle-to-Internet communications, 3GPP LTE and other cellular technologies represent the long-range connectivity method; for Vehicle-to-Vehicle communications, LTE Direct is currently specified, as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning. The IEEE developed a popular link for short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V communications. Work Items ---------- - use-cases for moving network to nearby moving network communications - Problem Statement for moving network to nearby moving network communications including V2V, V2I and DNS. - Security and Privacy Requirements for moving network to nearby moving network communications - Solutions, which might include new protocols or extensions to existing protocols. With MIB. - IPv6-over foo, where foo is pertinent for moving network to nearby moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in the V2V domain, identifying which uses IP. Timeline -------- - --------------010509070304020702090603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit ITSers,

Please see below the current charter.

- the two Problem Statements drafts V2V and V2I joined, so there is less text in charter.
- added an Item on "List of Research papers..."

Erik: did I understand you correctly that there should be some item on discussing whether link-local addressing is sufficient, whether prefix exchange is necessary?

Dino: should LISP be included in the gap analysis draft which includes C-ACC use-case?  OR should we separate a dedicated I-D only with gap analysis including ND, MIP, AODVv2, LISP?

Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle interface illustrated good enough by the words "moving network to nearby moving network communications"?  Or is it better to say "the 1-IP-hop between nearby moving networks must be self-configured"?

Nabil, Sandra: is it ok to have a working group item "List of Research Papers for IP in V2V and V2I communications"?

Other comments?

Alex

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

             ITS (name to change)
                   Charter
             April 6th, 2016
         http://ietf.org/mailman/listinfo/its


Intelligent Transportation Systems (its)
----------------------------------------
Current Status: WG forming

Chairs:
   TBD

Assigned Area Director:
   TBD

Mailing list
   Address: its@ietf.org
   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:

Goal
----
The goal of this group is to standardize IP-based protocols for
establishing direct and secure connectivity between moving networks,
some of which could be fixed permanently or temporarily.

Moving Network to Nearby Moving Network Communications
------------------------------------------------------
The group is concerned with all situations involving moving network to
nearby moving network communications.  For example: vehicle-to-vehicle
communications, nomadic user wearing a PAN and communicating to a
homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a
train, or train-to-intersection signalling.

Example from the automobile communications space
------------------------------------------------
Automobiles and vehicles of all types are increasingly connected to
the Internet, either as vehicle-to-vehicle, vehicle-to-infra or
vehicle-to-Internet.  Entertainment apps enhancing comfort, reliable
data exchanges for road safety, and automated driving are features
coming in automobiles to hit the roads from now to year 2020.
Highlighting increased safety as an immediate result of
hyper-connectivity applied to vehicles, public authorities worldwide
are increasingly mandating secure communication technology
requirements in vehicles.

Emergency apps for new instrumented ambulances carry many benefits
both to the users and to society in general.

Why IP?
-------
Today, there are several deployed Vehicle-to-Internet technologies,
including car tethering through driver's cellular smartphone.
However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communications are still being developed.  To improve on a situation
of link-specific data exchanges, and enable independent application
sets to share the same links, IP data exchanges are needed.  Enabling
IP communication between vehicles (V2V), and between vehicles and the
immediate infrastructure (V2I), will provide (0) ability to reach the
rest of the world on the Internet (1) short and deterministic delays,
(2) fast forwarding through scalable paths of routers, (3) ease of
reuse of existing Internet applications in a vehicular environment.

Moving network to nearby moving network communications involve link
layers such as: 802.11p OCB (Outside the Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light
Communications), IrDA, LTE-D.  Only the IP protocols are capable of
running on each of these links and establish IP paths across them in
an interoperable manner.

Scenarios?
----------
There are a few scenarios exhibiting the need to communicate from one
moving network to another nearby moving network.

In the automobile space, the Cooperative Adaptive Cruise Control and
Platooning features consider that vehicles close to each other
exchange data describing their kinematic status.  At the cross-roads,
the moving network inside a vehicle exchanges data with the moving
network in the red-light pole.

Several public safety scenarios involve moving networks.  Distinct
organizations deploy different moving networks (in-vehicle, on-person)
at an incident scene.  These networks need to interoperate in order to
more effectively understand and deal with the incident scene.

In connected rail scenarios the moving network deployed in trains
communicate with other moving networks at the cross-points.

What kind of solutions?
-----------------------
The current technical solutions considered to achieve moving network
to nearby moving network communications are of two kinds: IP routing
protocols for n-hop path management and 1-hop link-scoped IP protocol
enhancements.  The 1-hop link-scoped protocols include the protocols
for route establishment involving ICMP Router Advertisements.  The
n-hop path management protocols include n-hop path establishment
protocols (e.g. Babel, OSPF) and n-hop path search protocols (most
notably AODV and derivates).

In this proposed Working Group the focus is on 1-hop protocols, and
leverage from other Working Groups for the n-hop situations.

In some of the moving network applications the window of opportunity
for exchanging data with the immediate infrastructure may be very
short.  For example, a car driving near a road-side unit may have only
5s to exchange with that RSU (depending on speed, RSU range and
number). (ephemeral connections).

What kind of requirements?
--------------------------
The requirements for mechanisms for moving network to nearby moving
network communications are focusing on low delays of the data paths,
reduced number of messages for path establishment, application
friendly, resilience to attacks, compatibility with DHCP and Mobile
IP.

In addition, some moving network to nearby moving network applications
involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP moving network to nearby moving netowrk mechanisms will need
to gracefully support IP multicast.

Due to the inherent characteristics of safety-related communications,
all new moving network to nearby moving network mechanisms must afford
authenticity and confidentiality where necessary.  Dynamically
establishing ephemeral communication paths between automobiles in
public areas must offer privacy safeguards for the end users
(passengers).

Establishing 1-hop IP V2V paths must not break the existing on-board
protocols and applications which communicate with the Internet,
possibly via multiple radios.

In a moving network deployed in an automobile, typically one exit
point connects the moving network to other moving networks.  However,
in a more general manner (and to support reliability) any new
mechanism of moving network to nearby moving network communications
should support multi-homing: one router to use multiple interfaces
towards outside the moving network, or multiple routers.

Current version of Internet protocols
-------------------------------------
The group will only work on IPv6 solutions.

What SDOs may need this work?
-----------------------------
The requirements and standards for moving network to nearby moving
network communications, often involving IPv6, and novel V2V and
V2Infra concepts, are developed mainly at ISO TC204 "Intelligent
Transport Systems", 3GPP, ETSI, NHTSA and IEEE.  For
Vehicle-to-Internet communications, 3GPP LTE and other cellular
technologies represent the long-range connectivity method; for
Vehicle-to-Vehicle communications, LTE Direct is currently specified,
as well as OCB mode of IEEE 802.11.  Several use-cases exhibit a need
for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive
Cruise Control and Platooning.  The IEEE developed a popular link for
short-range communications - IEEE 802.11p "WAVE".  The NHTSA wrote a
set of requirements for V2V communications.

Work Items
----------
- use-cases for moving network to nearby moving network communications
- Problem Statement for moving network to nearby moving network communications
  including V2V, V2I and DNS.
- Security and Privacy Requirements for moving network to
  nearby moving network communications
- Solutions, which might include new protocols or extensions to
  existing protocols.  With MIB.
- IPv6-over foo, where foo is pertinent for moving network to nearby
  moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)
- List of Research Papers in the V2V domain, identifying which uses IP.

Timeline
--------
-

 --------------010509070304020702090603-- From nobody Wed Apr 6 15:13:04 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0D912D1E0 for ; Wed, 6 Apr 2016 15:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8eGssoXC-WC for ; Wed, 6 Apr 2016 15:13:01 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E74B12D613 for ; Wed, 6 Apr 2016 15:13:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u36MCx7Q006611; Thu, 7 Apr 2016 00:12:59 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 619CC204550; Thu, 7 Apr 2016 00:14:08 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 532F4204544; Thu, 7 Apr 2016 00:14:08 +0200 (CEST) Received: from [132.166.84.226] ([132.166.84.226]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u36MCvv5029759; Thu, 7 Apr 2016 00:12:58 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: <570589E8.8080000@gmail.com> Date: Wed, 6 Apr 2016 19:12:56 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010307040702070709090609" Archived-At: Cc: Michael Richardson Subject: [its] trust goals between moving networks untenable? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 22:13:03 -0000 This is a multi-part message in MIME format. --------------010307040702070709090609 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit ITSers, On the jabber, someone said: > mic: This goals in this charter are too ambitious. The trust > problem between moving networks is untenable today. If we can assume > that there are useful certificates, then there is almost no technical > work to do. I think it's Michael Richardson? If one thinks the goals around trust problem between moving networks are untenable today then I beg to differ. I can tell for example that some SDO works on it. Otherwise, technically speaking, I think that certificates could be used somehow without a CA permanently reachable. E.g. when within LTE reach then verify with CA, otherwise just V2V informal proof with a number of pre-stored certificates. Then, there may exist other means in cars (not typical elsewhere) to ensure identity. For example many cars are equipped with cameras and image recognition software. That's not as widespread in smartphones as it is in cars. These cameras tell the numbers in license plates in front and behind. The license plates are mandated by gov't . Some databases of license plates are public. That should give enough reassurance about identity. So one can come up easily with an authorization mechanism like AAA that is keyed by a license plate number, just like with a NAI (MAC address, user@domain,). Maybe the license plate recognition is of privacy concern? what is needed is that what the computer thinks is the car in front is what the driver sees as the car in front. That can be achieved by some form of human interaction with the dashboard. That human pressing a button is like when one checks a box to get access to a public hotspot. It's identification. This is to say that once IP is there, many things can be tried to do trust between moving networks. But if not, then not. Alex --------------010307040702070709090609 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit ITSers,

On the jabber, someone said:
 <mcr> mic: This goals in this charter are too ambitious.  The trust problem between moving networks is untenable today.  If we can assume that there are useful certificates, then there is almost no technical work to do.

I think it's Michael Richardson?

If one thinks the goals around trust problem between moving networks are untenable today then I beg to differ.

I can tell for example that some SDO works on it.

Otherwise, technically speaking, I think that certificates could be used somehow without a CA permanently reachable.  E.g. when within LTE reach then verify with CA, otherwise just V2V informal proof with a number of pre-stored certificates.

Then, there may exist other means in cars (not typical elsewhere) to ensure identity.  For example many cars are equipped with cameras and image recognition software.  That's not as widespread in smartphones as it is in cars.  These cameras tell the numbers in license plates in front and behind.  The license plates are mandated by gov't .  Some databases of license plates are public.  That should give enough reassurance about identity.

So one can come up easily with an authorization mechanism like AAA that is keyed by a license plate number, just like with a NAI (MAC address, user@domain,).

Maybe the license plate recognition is of privacy concern? what is needed is that what the computer thinks is the car in front is what the driver sees as the car in front.  That can be achieved by some form of human interaction with the dashboard.  That human pressing a button is like when one checks a box to get access to a public hotspot.  It's identification.

This is to say that once IP is there, many things can be tried to do trust between moving networks.  But if not, then not.

Alex
 --------------010307040702070709090609-- From nobody Wed Apr 6 15:20:17 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A332D12D0A3 for ; Wed, 6 Apr 2016 15:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hl3uR0PtC2QM for ; Wed, 6 Apr 2016 15:20:08 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D9312D1CB for ; Wed, 6 Apr 2016 15:20:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u36MK6c0021187; Thu, 7 Apr 2016 00:20:06 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C4EEF201D02; Thu, 7 Apr 2016 00:21:15 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AD3F5200F02; Thu, 7 Apr 2016 00:21:15 +0200 (CEST) Received: from [132.166.84.226] ([132.166.84.226]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u36MK40Z031006; Thu, 7 Apr 2016 00:20:05 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: <57058B94.1050906@gmail.com> Date: Wed, 6 Apr 2016 19:20:04 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020709000905040006000908" Archived-At: Cc: Thierry Ernst Subject: [its] Message from ISO TC204 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 22:20:15 -0000 This is a multi-part message in MIME format. --------------020709000905040006000908 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit ITSers, There was not enough time to present a particularly important message from ISO TC204: Slide 13 of "ISO TC204 needs" presentation: https://datatracker.ietf.org/meeting/95/materials.html/#its "Direct communication between ITS stations (adhoc) – Generically applicable IETF standard is sought on this otherwise ISO will develop its own" Yours, Alex --------------020709000905040006000908 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit ITSers,

There was not enough time to present a particularly important message from ISO TC204:

Slide 13 of "ISO TC204 needs" presentation:
https://datatracker.ietf.org/meeting/95/materials.html/#its

"Direct communication between ITS stations (adhoc)
– Generically applicable IETF standard is sought on this
  otherwise ISO will develop its own"

Yours,

Alex
 --------------020709000905040006000908-- From nobody Wed Apr 6 15:46:50 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196CF12D134 for ; Wed, 6 Apr 2016 15:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4iZQSa07sGO for ; Wed, 6 Apr 2016 15:46:47 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C89612D0A3 for ; Wed, 6 Apr 2016 15:46:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u36Mki4K010714 for ; Thu, 7 Apr 2016 00:46:44 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7A5C5204588 for ; Thu, 7 Apr 2016 00:47:53 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6E73120447D for ; Thu, 7 Apr 2016 00:47:53 +0200 (CEST) Received: from [132.166.84.226] ([132.166.84.226]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u36MkgJY005873 for ; Thu, 7 Apr 2016 00:46:43 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: <570591D1.4070904@gmail.com> Date: Wed, 6 Apr 2016 19:46:41 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080109050206050602080903" Archived-At: Subject: [its] Raw meeting minutes X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 22:46:49 -0000 This is a multi-part message in MIME format. --------------080109050206050602080903 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Raw meeting minutes, thanks to minute takers for efforts despite echo-ey PA system. Alex ------------------------------------------------------------------ Minutes for [its] • Introduction: – Administrative - BOF Chairs - 5 min – ITS Goals and Success Criteria - BOF Chairs - 10 min • Problem Space: – Tutorial of IP in vehicular communications - Alex Petrescu - 20 min Randel Gelland: Since there are so many MAC & PHY, they use their own messaging -- so could use IP. But vehicals are using different PHY & MAC, so they can't communicate Alex: But some of the radios are actually compatible Bob Hinden: On "Topology" slide -- this is very simplified. There will be many cars, with very dynamic interconnection Alex: Yes. Gives more examples to support contention Dapeng Liu: Once connectivity is established, IP will enable better communication. Pat Thaler: Even for compatible PHY, MACs may be different, so can't just day "use IP" Erik Nordmark: Have people considered what the IP addressing will look like? In the car, the addressing is stable, but not outside the car. How does one car know the address in the other car? Alex: Yes, people are working on this. IETF can help. Carlos: Are people working on the addressing sheme. Dino: We have an IP mobility problem Dirk Kircher: Broadcast. Semantic layer. Alex: There may be multiple hops beween cars, and multiple hops in a car. May need IPv4 broadcast, or IPv6 broadcast Dino: Even without the mobility problem, we still would have physical layer incompatible problems. But that is exactly what IP solves. – ITS use-cases C-ACC and Platooning - Alex Petrescu - 10 min draft-petrescu-its-cacc-sdo-04 Lou Berger: Hackable. What's the security model? Alex: Do not have slides about this. Eric Rescolo: Why make any representation about exceeding speedlimit. Alex: It's just an example Eric Rescolo: What if the police ask this question? Sandra: there is a lot of work being done on security = Safety part Eric Burdick: There are a lot of privacy issues. There is work about jamming. It's not just Mobile IP. Erik Nordmark: There was an IETF plenary that is relevant to security. = Police can probaly go get the data Eric Rescolo: Lots of work to be done -- prevent querying in the car. – ITS V2V problem statement - Dapeng Liu - 5 min draft-petrescu-its-problem-00 Randel Gelland: How do they know when they need to discover the other vehicles' address? Dirk Kircher: Sub-Problem(1) needs to be characterized correctly. What is a realistic use case: Answer: C-ACC ...: do you have data? Alex: How much data do you want? Randel Gellens: This shows how IP is useful, but it's not why IP is needed? So it is needed to exhibit the need, not just the use case. Erik Nordmark: how identities (or even temporary identities) established? Hannes Tshofenig: Is there a need for another layer for identity? – ITS V2I problem statement - Jaehoon Paul Jeong - 5 min draft-jeong-its-v2i-problem-statement-00 Charlie: What does it mean to "directly" connect to the RSO's network Jaehoon: Exchange prefixes Woman Dino: a lost packet could be a catastrophe, amidst a lot of connection. Need to avoid chit-chat. Should avoid multiple solutions. If security requires Diffie-Hellman, may not get to finally say "BRAKE" Dino: May not be able to go get a certificate. <....?>: May not have time to Dirk Kircher: Question about use case... Alex: Some operators already provide connection between RSUs, and thus can provide handovers • Discussion - 10 min Aaron Falk: Good to have the discussion. Useful confusion [??} Dirk Kircher: Use cases need discussion, as well as network drivers. Carlos: Are you talking about requirements? Dirk: Network requirements... Erik Nordmark: Don't really grasp exactly why IP is needed for single hop. Will this use the same Internet? What about the timing requirements? Stan Ratliff: V2V could be mobile ad hoc network? Russ: Not if it's just one hop. <...> : Want to know what cars are closing in. Could want to send message just backwards. Dino: What if you *don't* have IP? A lot of vehicles already have IP, so it is already there. IP could simplify the automobile and the communications. We will want to write applications. Will need to have compatible format. We will want open standards. Spencer Dawkins: Was waiting for a transport question. Applications might be close to each other? About updating the car. Hannes: Applications might be running on many different computers and media, but still need to communicate. Pat Thaler: Updating the car is a different sort of thing than V2I. We will have updates at the service station, so you're not moving. Three concerns: security problem. Time constraints. Spencer: Need to understand what the volume of data would be. Dirk: Is it, or is it not, TCP? There are a couple of protocols in use today. Eric Burdick: Should assume that all protocols are broken. The control mechanisms could collapse with the number of cars. – What documents are needed to advance this work? http://itu.int/go/ITScomms is complete list of ITU work items Dino: Why include trains but not planes? Alex: O.K. Erik Burdick: What about when get onto the ocean? Dirk: Some of the use cases are very dissimilar. Need to pick one problem. Aaron from Jabber: Can assume use of certificates. Dino: Need to look at the requirements and see if there are solutions, even though there are a lot of work items. Erik Nordmark: Can we figure out what is needed for the immediate term? Randall Gellens: What about coordination with other SDOs? For instance regarding IPv6-over-foo. Alex: With a working group we can have a channel by which to do the coordination Randall: We have that with ISO, 3GPP, etc. Closing remarks: We will publish the charter on the working group. In about a month we will see if we have a rigorous charter. --------------080109050206050602080903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Raw meeting minutes, thanks to minute takers for efforts despite echo-ey PA system.

Alex

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

Minutes for [its]

• Introduction:


– Administrative - BOF Chairs - 5 min


– ITS Goals and Success Criteria - BOF Chairs - 10 min


• Problem Space:


– Tutorial of IP in vehicular communications - Alex Petrescu - 20 min
Randel Gelland: Since there are so many MAC & PHY, they use their own
    messaging -- so could use IP.  But vehicals are using different PHY
    & MAC, so they can't communicate
Alex: But some of the radios are actually compatible

Bob Hinden: On "Topology" slide -- this is very simplified.  There will be
    many cars, with very dynamic interconnection
Alex: Yes.  Gives more examples to support contention

Dapeng Liu: Once connectivity is established,
            IP will enable better communication.

Pat Thaler: Even for compatible PHY, MACs may be different, so can't just day
    "use IP"

Erik Nordmark: Have people considered what the IP addressing will look like?
    In the car, the addressing is stable, but not outside the car.  How
    does one car know the address in the other car?
Alex: Yes, people are working on this.  IETF can help.

Carlos: Are people working on the addressing sheme.

Dino: We have an IP mobility problem

Dirk Kircher: Broadcast.  Semantic layer.
Alex: There may be multiple hops beween cars, and multiple hops in a car.
    May need IPv4 broadcast, or IPv6 broadcast

Dino: Even without the mobility problem, we still would have physical layer
    incompatible problems.  But that is exactly what IP solves.

– ITS use-cases C-ACC and Platooning - Alex Petrescu - 10 min
draft-petrescu-its-cacc-sdo-04

<while presenting Platooning scalability slide>
Lou Berger: Hackable.  What's the security model?
Alex: Do not have slides about this.
Eric Rescolo: Why make any representation about exceeding speedlimit.
Alex: It's just an example
Eric Rescolo: What if the police ask this question?
<comment from floor - add speed parameter>

Sandra: there is a lot of work being done on security
    = Safety part

Eric Burdick: There are a lot of privacy issues.  There is work about jamming.
    It's not just Mobile IP.

Erik Nordmark: There was an IETF plenary that is relevant to security.
    = Police can probaly go get the data

Eric Rescolo: Lots of work to be done -- prevent querying in the car.


– ITS V2V problem statement - Dapeng Liu - 5 min
draft-petrescu-its-problem-00

Randel Gelland: How do they know when they need to discover the other vehicles'
    address?
Dirk Kircher: Sub-Problem(1) needs to be characterized correctly.  What is a
    realistic use case:  Answer: C-ACC

...: do you have data?
Alex: How much data do you want?

Randel Gellens: This shows how IP is useful, but it's not why IP is needed?
    So it is needed to exhibit the need, not just the use case.

Erik Nordmark: how identities (or even temporary identities) established?

Hannes Tshofenig: Is there a need for another layer for identity?


– ITS V2I problem statement - Jaehoon Paul Jeong - 5 min
draft-jeong-its-v2i-problem-statement-00

Charlie: What does it mean to "directly" connect to the RSO's network
Jaehoon: Exchange prefixes

Woman <did not understand, sorry>

Dino: a lost packet could be a catastrophe, amidst a lot of connection.
    Need to avoid chit-chat.  Should avoid multiple solutions.
    If security requires Diffie-Hellman, may not get to finally say "BRAKE"
Dino: May not be able to go get a certificate.

<....?>: May not have time to

Dirk Kircher: Question about use case...

Alex: Some operators already provide connection between RSUs, and thus
    can provide handovers

• Discussion - 10 min

Aaron Falk: Good to have the discussion.  Useful confusion [??}
Dirk Kircher: Use cases need discussion, as well as network drivers.
Carlos: Are you talking about requirements?
Dirk: Network requirements...
Erik Nordmark: Don't really grasp exactly why IP is needed for single hop.
    Will this use the same Internet?  What about the timing requirements?
Stan Ratliff: V2V could be mobile ad hoc network?
Russ: Not if it's just one hop.
<...> : Want to know what cars are closing in.  Could want to send message
    just backwards.
Dino: What if you *don't* have IP?  A lot of vehicles already have IP, so it
    is already there.  IP could simplify the automobile and the
    communications.  We will want to write applications.  Will need to have
    compatible format.  We will want open standards.
Spencer Dawkins: Was waiting for a transport question.  Applications might be
    close to each other?  About updating the car.
Hannes: Applications might be running on many different computers and media,
    but still need to communicate.
Pat Thaler: Updating the car is a different sort of thing than V2I.  We will
    have updates at the service station, so you're not moving.
    Three concerns: security problem. Time constraints.
Spencer: Need to understand what the volume of data would be.
Dirk: Is it, or is it not, TCP?  There are a couple of protocols in use today.
Eric Burdick: Should assume that all protocols are broken.
    The control mechanisms could collapse with the number of cars.

– What documents are needed to advance this work?
http://itu.int/go/ITScomms is complete list of ITU work items

Dino: Why include trains but not planes?
Alex: O.K.
Erik Burdick: What about when get onto the ocean?
Dirk: Some of the use cases are very dissimilar.  Need to pick one problem.
Aaron from Jabber: Can assume use of certificates.
Dino: Need to look at the requirements and see if there are solutions,
    even though there are a lot of work items.
Erik Nordmark: Can we figure out what is needed for the immediate term?
Randall Gellens: What about coordination with other SDOs?  For instance
    regarding IPv6-over-foo.
Alex: With a working group we can have a channel by which to do the coordination
Randall: We have that with ISO, 3GPP, etc.

Closing remarks:
We will publish the charter on the working group.  In about a month we
will see if we have a rigorous charter.
 --------------080109050206050602080903-- From nobody Wed Apr 6 15:57:48 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C07B12D635 for ; Wed, 6 Apr 2016 15:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JrdwhGdMJtN for ; Wed, 6 Apr 2016 15:57:43 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C92712D6D0 for ; Wed, 6 Apr 2016 15:57:43 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id f105so25337885qge.2 for ; Wed, 06 Apr 2016 15:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=28FtOkf6MLlptQ2Z2sV4bhflDjcAjVXn/Uehn6Qtfxo=; b=ncWPDt8wcJoM44L/agSXFiLAEGLgKM3Dog9xNQl3tVLen3E1xaTF1yazh2j8w4den1 bmhrMR6/tb0R8gboa55hRo7slDXKE6niBeibaDdcgEqZcL3iMPptzgg+oRSUs2lZUvye BDMxWVTuN0KYcbOE8IiOD/mHCSTkR6ZFbI9baiGHtV52rQDVzcoYLHVDp23XA0MKeMQ5 b/224tD6ZcWQ4zHyjrYKwNwvpmVIsj6ufkPP3v2+6WSrFIKbifIUGoR3R90RsR1hTXVb wdiJti8Lj1t8iqwWBNrVrT+Lf+7gqTjfZ9iqR9il2LVUzD4m6iRHS3mHJL3tpgaWuwMP q3Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=28FtOkf6MLlptQ2Z2sV4bhflDjcAjVXn/Uehn6Qtfxo=; b=O2Mg/FTMsMdK9X0i5lUaNs3WJr1/zYvwJTHhL+nBWd/9RnWYeMryQ35EchlqZeaiEj OpmYC/4DzEO7ZvcQ151mYH/EqFQFxhLBMNkE+K30eZ3tpxAjDps7aHeJtIW1hTsjt/ZD A8kDZQ+4+f6H1wzjwoOfgRGFLX12suKzYwHj9H8gvoOXA3E6SbXwuZbK2uaC8LkeVQCp hBdWil+91ZZ7ciYTEbi3Du3ZkT2Ac6n4IKySD+ZN/Fd6g34SXRlCjZWXNJy7vV3p0kL7 xHcMOx0G00aysrqTz3zMd7J1tOsnmPy8ivgvyAznqICJT99F2JFRIJRC9Xe0KiX1iwWi W98w== X-Gm-Message-State: AD7BkJI6w7wpvjgPVS4T6K/gHNGG8pyEQ2ZkArCcvFgnNrvgb/9u2Qb2t097w8Fus1sf0A== X-Received: by 10.140.145.83 with SMTP id 80mr29110997qhr.95.1459983462163; Wed, 06 Apr 2016 15:57:42 -0700 (PDT) Received: from [172.17.74.180] (200-127-148-163.net.prima.net.ar. [200.127.148.163]) by smtp.gmail.com with ESMTPSA id p129sm2195276qhp.44.2016.04.06.15.57.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 15:57:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: <57058375.6050101@gmail.com> Date: Wed, 6 Apr 2016 15:57:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6B2D2039-34AD-41BA-9B9D-61164C9043CB@gmail.com> References: <57058375.6050101@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 22:57:46 -0000 > On Apr 6, 2016, at 2:45 PM, Alexandre Petrescu = wrote: >=20 > ITSers, >=20 > Please see below the current charter. >=20 > - the two Problem Statements drafts V2V and V2I joined, so there is = less text in charter. > - added an Item on "List of Research papers..." >=20 > Erik: did I understand you correctly that there should be some item on = discussing whether link-local addressing is sufficient, whether prefix = exchange is necessary? >=20 > Dino: should LISP be included in the gap analysis draft which includes = C-ACC use-case? OR should we separate a dedicated I-D only with gap = analysis including ND, MIP, AODVv2, LISP? LISP is an architecture that can be used for IP (EID) mobility. So I = would say yes. Dino >=20 > Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle = interface illustrated good enough by the words "moving network to nearby = moving network communications"? Or is it better to say "the 1-IP-hop = between nearby moving networks must be self-configured"? >=20 > Nabil, Sandra: is it ok to have a working group item "List of Research = Papers for IP in V2V and V2I communications"? >=20 > Other comments? >=20 > Alex >=20 > ------------------------------------------------------------------ >=20 > ITS (name to change) > Charter > April 6th, 2016 > http://ietf.org/mailman/listinfo/its >=20 >=20 > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming >=20 > Chairs: > TBD >=20 > Assigned Area Director: > TBD >=20 > Mailing list > Address: its@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/its > Archive: > http://www.ietf.org/mail-archive/web/its/current/maillist.html >=20 > Additional web page > TBD >=20 > Charter: >=20 > Goal > ---- > The goal of this group is to standardize IP-based protocols for > establishing direct and secure connectivity between moving networks, > some of which could be fixed permanently or temporarily. >=20 > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving network to > nearby moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > train, or train-to-intersection signalling. >=20 > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to > the Internet, either as vehicle-to-vehicle, vehicle-to-infra or > vehicle-to-Internet. Entertainment apps enhancing comfort, reliable > data exchanges for road safety, and automated driving are features > coming in automobiles to hit the roads from now to year 2020. > Highlighting increased safety as an immediate result of > hyper-connectivity applied to vehicles, public authorities worldwide > are increasingly mandating secure communication technology > requirements in vehicles. >=20 > Emergency apps for new instrumented ambulances carry many benefits > both to the users and to society in general. >=20 > Why IP? > ------- > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. > However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure > communications are still being developed. To improve on a situation > of link-specific data exchanges, and enable independent application > sets to share the same links, IP data exchanges are needed. Enabling > IP communication between vehicles (V2V), and between vehicles and the > immediate infrastructure (V2I), will provide (0) ability to reach the > rest of the world on the Internet (1) short and deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) ease of > reuse of existing Internet applications in a vehicular environment. >=20 > Moving network to nearby moving network communications involve link > layers such as: 802.11p OCB (Outside the Context of a Basic Service > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light > Communications), IrDA, LTE-D. Only the IP protocols are capable of > running on each of these links and establish IP paths across them in > an interoperable manner. >=20 > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate from one > moving network to another nearby moving network. >=20 > In the automobile space, the Cooperative Adaptive Cruise Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the cross-roads, > the moving network inside a vehicle exchanges data with the moving > network in the red-light pole. >=20 > Several public safety scenarios involve moving networks. Distinct > organizations deploy different moving networks (in-vehicle, on-person) > at an incident scene. These networks need to interoperate in order to > more effectively understand and deal with the incident scene. >=20 > In connected rail scenarios the moving network deployed in trains > communicate with other moving networks at the cross-points. >=20 > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol > enhancements. The 1-hop link-scoped protocols include the protocols > for route establishment involving ICMP Router Advertisements. The > n-hop path management protocols include n-hop path establishment > protocols (e.g. Babel, OSPF) and n-hop path search protocols (most > notably AODV and derivates). >=20 > In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations. >=20 > In some of the moving network applications the window of opportunity > for exchanging data with the immediate infrastructure may be very > short. For example, a car driving near a road-side unit may have only > 5s to exchange with that RSU (depending on speed, RSU range and > number). (ephemeral connections). >=20 > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to nearby moving > network communications are focusing on low delays of the data paths, > reduced number of messages for path establishment, application > friendly, resilience to attacks, compatibility with DHCP and Mobile > IP. >=20 > In addition, some moving network to nearby moving network applications > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the > 1-hop IP moving network to nearby moving netowrk mechanisms will need > to gracefully support IP multicast. >=20 > Due to the inherent characteristics of safety-related communications, > all new moving network to nearby moving network mechanisms must afford > authenticity and confidentiality where necessary. Dynamically > establishing ephemeral communication paths between automobiles in > public areas must offer privacy safeguards for the end users > (passengers). >=20 > Establishing 1-hop IP V2V paths must not break the existing on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. >=20 > In a moving network deployed in an automobile, typically one exit > point connects the moving network to other moving networks. However, > in a more general manner (and to support reliability) any new > mechanism of moving network to nearby moving network communications > should support multi-homing: one router to use multiple interfaces > towards outside the moving network, or multiple routers. >=20 > Current version of Internet protocols > ------------------------------------- > The group will only work on IPv6 solutions. >=20 > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to nearby moving > network communications, often involving IPv6, and novel V2V and > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For > Vehicle-to-Internet communications, 3GPP LTE and other cellular > technologies represent the long-range connectivity method; for > Vehicle-to-Vehicle communications, LTE Direct is currently specified, > as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need > for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive > Cruise Control and Platooning. The IEEE developed a popular link for > short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a > set of requirements for V2V communications. >=20 > Work Items > ---------- > - use-cases for moving network to nearby moving network communications > - Problem Statement for moving network to nearby moving network = communications > including V2V, V2I and DNS. > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Solutions, which might include new protocols or extensions to > existing protocols. With MIB. > - IPv6-over foo, where foo is pertinent for moving network to nearby > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, = 802.11ad) > - List of Research Papers in the V2V domain, identifying which uses = IP. >=20 > Timeline > -------- > - >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Wed Apr 6 16:11:09 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E92A12D65F for ; Wed, 6 Apr 2016 16:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MV_KwT1lM3CT for ; Wed, 6 Apr 2016 16:11:04 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id DD7E912D5D9 for ; Wed, 6 Apr 2016 16:11:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,448,1454972400"; d="scan'208,217";a="3595642" Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236]) by drago2i.eurecom.fr with ESMTP; 07 Apr 2016 01:11:01 +0200 Received: from xerus29 (LFbn-1-6946-250.w90-116.abo.wanadoo.fr [90.116.128.250]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtps.eurecom.fr (Postfix) with ESMTPSA id 70EB01CA; Thu, 7 Apr 2016 01:11:01 +0200 (CEST) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , References: <57058375.6050101@gmail.com> In-Reply-To: <57058375.6050101@gmail.com> Date: Thu, 7 Apr 2016 01:11:01 +0200 Organization: EURECOM Message-ID: <009301d19059$96917820$c3b46860$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0094_01D1906A.5A217410" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt54qCPzaRhlgKe35lrbFRjfOAYaBE12hg Content-Language: en-us Archived-At: Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 23:11:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0094_01D1906A.5A217410 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear ITSers, Dear Alex, =20 Here are some comments on the updated charter: 1) Can we keep a reference to IEEE 802.11p, considering it does not = exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB = mode (and 10Mhz @5.9Ghz) of course.=20 =20 2) Should we really keep C-ACC (or Platooning) in the charter = explicitly as use case, considering it is a seriously controversial = aspect with some SDOs (ex. In Automotive SDOs)? In the ISO presentation, = Thierry mentions traffic efficiency/infotainment applications, such as = in-signage applications... a. We might have to aim at less controversial use cases to attract = automotive industries =20 3) One potential WI I could think of (rather a basic one): = definition of a vehicular wireless =E2=80=98link=E2=80=99 in an = automotive context a. To me, this is a fundamental brick in the larger IETF WG ITS = house.. =20 4) I would suggest to be more explicit in the foreseen challenges = of this WG, instead of mentioning general use case (which end up be = controversial) a. Example: maintaining IPv6 connectivity in fast and asymmetric = wireless links; also under quickly changing topologies (actually = suggested by Dick Roy on the chat room) b. Example: IPv6 addressing in link-local scope.. c. Example: guaranteeing privacy in IPv6 moving networks etc.. =20 5) Before listing academic papers referring to IPv6 in vehicles, I = would suggest to first try to list commercial products/solutions that = are in vehicles and are using IPv6, possibly suffering from a silo = limitations (ex. restricted to a single technology, single use = case=E2=80=A6) a. I think we need to get to products first, before academic = visions =20 My two cents.. =20 Best Regards, =20 J=C3=A9r=C3=B4me =20 =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Wednesday 06 April 2016 23:45 To: its@ietf.org Subject: [its] charter ITS =20 ITSers, Please see below the current charter. - the two Problem Statements drafts V2V and V2I joined, so there is less = text in charter. - added an Item on "List of Research papers..." Erik: did I understand you correctly that there should be some item on = discussing whether link-local addressing is sufficient, whether prefix = exchange is necessary? Dino: should LISP be included in the gap analysis draft which includes = C-ACC use-case? OR should we separate a dedicated I-D only with gap = analysis including ND, MIP, AODVv2, LISP? Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle = interface illustrated good enough by the words "moving network to nearby = moving network communications"? Or is it better to say "the 1-IP-hop = between nearby moving networks must be self-configured"? Nabil, Sandra: is it ok to have a working group item "List of Research = Papers for IP in V2V and V2I communications"? Other comments? Alex ------------------------------------------------------------------ ITS (name to change) Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: WG forming Chairs: TBD Assigned Area Director: TBD Mailing list Address: its@ietf.org 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: Goal ---- The goal of this group is to standardize IP-based protocols for establishing direct and secure connectivity between moving networks, some of which could be fixed permanently or temporarily. Moving Network to Nearby Moving Network Communications ------------------------------------------------------ The group is concerned with all situations involving moving network to nearby moving network communications. For example: vehicle-to-vehicle communications, nomadic user wearing a PAN and communicating to a homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a train, or train-to-intersection signalling. Example from the automobile communications space ------------------------------------------------ Automobiles and vehicles of all types are increasingly connected to the Internet, either as vehicle-to-vehicle, vehicle-to-infra or vehicle-to-Internet. Entertainment apps enhancing comfort, reliable data exchanges for road safety, and automated driving are features coming in automobiles to hit the roads from now to year 2020. Highlighting increased safety as an immediate result of hyper-connectivity applied to vehicles, public authorities worldwide are increasingly mandating secure communication technology requirements in vehicles. Emergency apps for new instrumented ambulances carry many benefits both to the users and to society in general. Why IP? ------- Today, there are several deployed Vehicle-to-Internet technologies, including car tethering through driver's cellular smartphone. However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are still being developed. To improve on a situation of link-specific data exchanges, and enable independent application sets to share the same links, IP data exchanges are needed. Enabling IP communication between vehicles (V2V), and between vehicles and the immediate infrastructure (V2I), will provide (0) ability to reach the rest of the world on the Internet (1) short and deterministic delays, (2) fast forwarding through scalable paths of routers, (3) ease of reuse of existing Internet applications in a vehicular environment. Moving network to nearby moving network communications involve link layers such as: 802.11p OCB (Outside the Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light Communications), IrDA, LTE-D. Only the IP protocols are capable of running on each of these links and establish IP paths across them in an interoperable manner. Scenarios? ---------- There are a few scenarios exhibiting the need to communicate from one moving network to another nearby moving network. In the automobile space, the Cooperative Adaptive Cruise Control and Platooning features consider that vehicles close to each other exchange data describing their kinematic status. At the cross-roads, the moving network inside a vehicle exchanges data with the moving network in the red-light pole. Several public safety scenarios involve moving networks. Distinct organizations deploy different moving networks (in-vehicle, on-person) at an incident scene. These networks need to interoperate in order to more effectively understand and deal with the incident scene. In connected rail scenarios the moving network deployed in trains communicate with other moving networks at the cross-points. What kind of solutions? ----------------------- The current technical solutions considered to achieve moving network to nearby moving network communications are of two kinds: IP routing protocols for n-hop path management and 1-hop link-scoped IP protocol enhancements. The 1-hop link-scoped protocols include the protocols for route establishment involving ICMP Router Advertisements. The n-hop path management protocols include n-hop path establishment protocols (e.g. Babel, OSPF) and n-hop path search protocols (most notably AODV and derivates). In this proposed Working Group the focus is on 1-hop protocols, and leverage from other Working Groups for the n-hop situations. In some of the moving network applications the window of opportunity for exchanging data with the immediate infrastructure may be very short. For example, a car driving near a road-side unit may have only 5s to exchange with that RSU (depending on speed, RSU range and number). (ephemeral connections). What kind of requirements? -------------------------- The requirements for mechanisms for moving network to nearby moving network communications are focusing on low delays of the data paths, reduced number of messages for path establishment, application friendly, resilience to attacks, compatibility with DHCP and Mobile IP. In addition, some moving network to nearby moving network applications involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the 1-hop IP moving network to nearby moving netowrk mechanisms will need to gracefully support IP multicast. Due to the inherent characteristics of safety-related communications, all new moving network to nearby moving network mechanisms must afford authenticity and confidentiality where necessary. Dynamically establishing ephemeral communication paths between automobiles in public areas must offer privacy safeguards for the end users (passengers). Establishing 1-hop IP V2V paths must not break the existing on-board protocols and applications which communicate with the Internet, possibly via multiple radios. In a moving network deployed in an automobile, typically one exit point connects the moving network to other moving networks. However, in a more general manner (and to support reliability) any new mechanism of moving network to nearby moving network communications should support multi-homing: one router to use multiple interfaces towards outside the moving network, or multiple routers. Current version of Internet protocols ------------------------------------- The group will only work on IPv6 solutions. What SDOs may need this work? ----------------------------- The requirements and standards for moving network to nearby moving network communications, often involving IPv6, and novel V2V and V2Infra concepts, are developed mainly at ISO TC204 "Intelligent Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For Vehicle-to-Internet communications, 3GPP LTE and other cellular technologies represent the long-range connectivity method; for Vehicle-to-Vehicle communications, LTE Direct is currently specified, as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning. The IEEE developed a popular link for short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V communications. Work Items ---------- - use-cases for moving network to nearby moving network communications - Problem Statement for moving network to nearby moving network = communications including V2V, V2I and DNS. - Security and Privacy Requirements for moving network to nearby moving network communications - Solutions, which might include new protocols or extensions to existing protocols. With MIB. - IPv6-over foo, where foo is pertinent for moving network to nearby moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in the V2V domain, identifying which uses IP. Timeline -------- - ------=_NextPart_000_0094_01D1906A.5A217410 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear ITSers, =C2=A0Dear Alex,

 

Here are some comments on the updated = charter:

1)      = Can we keep a reference to IEEE 802.11p, considering it does not = exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB = mode (and 10Mhz @5.9Ghz) of course.

 

2)      = Should we really keep C-ACC (or Platooning) in the charter explicitly = as use case, considering it is a seriously controversial aspect with = some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry = mentions traffic efficiency/infotainment applications, such as = in-signage applications...

a.       = We might have to aim at less controversial use cases to attract = automotive industries

 

3)      = One potential WI I could think of (rather a basic one): definition = of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive = context

a.       = To me, this is=C2=A0 a fundamental brick in the larger IETF WG ITS = house..

 

4)      = I would suggest to be more explicit in the foreseen challenges of = this WG, instead of mentioning general use case (which end up be = controversial)

a.       = Example: maintaining IPv6 connectivity in fast and asymmetric = wireless links; also under quickly changing topologies (actually = suggested by Dick Roy on the chat room)

b.      = Example: IPv6 addressing in link-local = scope..

c.       = Example: guaranteeing privacy in IPv6 moving networks = etc..

 

5)      = Before listing academic papers referring to IPv6 in vehicles, I would = suggest to first try to list commercial products/solutions that are in = vehicles and are using IPv6, possibly suffering from a silo limitations = (ex. restricted to a single technology, single use = case=E2=80=A6)

a.       = I think we need to get to products first, before academic = visions

 

My two cents..

 

Best Regards,

 

J=C3=A9r=C3=B4me

 

 

 

From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre = Petrescu
Sent: Wednesday 06 April 2016 23:45
To: = its@ietf.org
Subject: [its] charter = ITS

 

ITSers,

Please see below the current charter.

- the = two Problem Statements drafts V2V and V2I joined, so there is less text = in charter.
- added an Item on "List of Research = papers..."

Erik: did I understand you correctly that there = should be some item on discussing whether link-local addressing is = sufficient, whether prefix exchange is necessary?

Dino: should = LISP be included in the gap analysis draft which includes C-ACC = use-case?  OR should we separate a dedicated I-D only with gap = analysis including ND, MIP, AODVv2, LISP?

Person from mediatek: = is the 'zeroconf' need in the vehicle-to-vehicle interface illustrated = good enough by the words "moving network to nearby moving network = communications"?  Or is it better to say "the 1-IP-hop = between nearby moving networks must be = self-configured"?

Nabil, Sandra: is it ok to have a working = group item "List of Research Papers for IP in V2V and V2I = communications"?

Other = comments?

Alex

--------------------------------------------= ----------------------

       &= nbsp;     ITS (name to = change)
          &n= bsp;        = Charter
          &n= bsp;  April 6th, = 2016
         http://ietf.org/mailman/lis= tinfo/its


Intelligent Transportation Systems = (its)
----------------------------------------
Current Status: WG = forming

Chairs:
   TBD

Assigned Area = Director:
   TBD

Mailing list
   = Address: its@ietf.org
   To = Subscribe: https://www.ietf.org/m= ailman/listinfo/its
   Archive:
   h= ttp://www.ietf.org/mail-archive/web/its/current/maillist.html

= Additional web page
   = TBD

Charter:

Goal
----
The goal of this group is to = standardize IP-based protocols for
establishing direct and secure = connectivity between moving networks,
some of which could be fixed = permanently or temporarily.

Moving Network to Nearby Moving = Network = Communications
------------------------------------------------------<= br>The group is concerned with all situations involving moving network = to
nearby moving network communications.  For example: = vehicle-to-vehicle
communications, nomadic user wearing a PAN and = communicating to a
homenet, vehicle-to-infrastructure communications, = wagon-to-wagon in a
train, or train-to-intersection = signalling.

Example from the automobile communications = space
------------------------------------------------
Automobiles = and vehicles of all types are increasingly connected to
the Internet, = either as vehicle-to-vehicle, vehicle-to-infra = or
vehicle-to-Internet.  Entertainment apps enhancing comfort, = reliable
data exchanges for road safety, and automated driving are = features
coming in automobiles to hit the roads from now to year = 2020.
Highlighting increased safety as an immediate result = of
hyper-connectivity applied to vehicles, public authorities = worldwide
are increasingly mandating secure communication = technology
requirements in vehicles.

Emergency apps for new = instrumented ambulances carry many benefits
both to the users and to = society in general.

Why IP?
-------
Today, there are = several deployed Vehicle-to-Internet technologies,
including car = tethering through driver's cellular smartphone.
However, = Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communications are = still being developed.  To improve on a situation
of = link-specific data exchanges, and enable independent application
sets = to share the same links, IP data exchanges are needed.  = Enabling
IP communication between vehicles (V2V), and between = vehicles and the
immediate infrastructure (V2I), will provide (0) = ability to reach the
rest of the world on the Internet (1) short and = deterministic delays,
(2) fast forwarding through scalable paths of = routers, (3) ease of
reuse of existing Internet applications in a = vehicular environment.

Moving network to nearby moving network = communications involve link
layers such as: 802.11p OCB (Outside the = Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC = (Visible Light
Communications), IrDA, LTE-D.  Only the IP = protocols are capable of
running on each of these links and establish = IP paths across them in
an interoperable = manner.

Scenarios?
----------
There are a few scenarios = exhibiting the need to communicate from one
moving network to another = nearby moving network.

In the automobile space, the Cooperative = Adaptive Cruise Control and
Platooning features consider that = vehicles close to each other
exchange data describing their kinematic = status.  At the cross-roads,
the moving network inside a vehicle = exchanges data with the moving
network in the red-light = pole.

Several public safety scenarios involve moving = networks.  Distinct
organizations deploy different moving = networks (in-vehicle, on-person)
at an incident scene.  These = networks need to interoperate in order to
more effectively understand = and deal with the incident scene.

In connected rail scenarios the = moving network deployed in trains
communicate with other moving = networks at the cross-points.

What kind of = solutions?
-----------------------
The current technical solutions = considered to achieve moving network
to nearby moving network = communications are of two kinds: IP routing
protocols for n-hop path = management and 1-hop link-scoped IP protocol
enhancements.  The = 1-hop link-scoped protocols include the protocols
for route = establishment involving ICMP Router Advertisements.  The
n-hop = path management protocols include n-hop path establishment
protocols = (e.g. Babel, OSPF) and n-hop path search protocols (most
notably AODV = and derivates).

In this proposed Working Group the focus is on = 1-hop protocols, and
leverage from other Working Groups for the n-hop = situations.

In some of the moving network applications the window = of opportunity
for exchanging data with the immediate infrastructure = may be very
short.  For example, a car driving near a road-side = unit may have only
5s to exchange with that RSU (depending on speed, = RSU range and
number). (ephemeral connections).

What kind of = requirements?
--------------------------
The requirements for = mechanisms for moving network to nearby moving
network communications = are focusing on low delays of the data paths,
reduced number of = messages for path establishment, application
friendly, resilience to = attacks, compatibility with DHCP and Mobile
IP.

In addition, = some moving network to nearby moving network applications
involve IP = multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP = moving network to nearby moving netowrk mechanisms will need
to = gracefully support IP multicast.

Due to the inherent = characteristics of safety-related communications,
all new moving = network to nearby moving network mechanisms must afford
authenticity = and confidentiality where necessary.  Dynamically
establishing = ephemeral communication paths between automobiles in
public areas = must offer privacy safeguards for the end = users
(passengers).

Establishing 1-hop IP V2V paths must not = break the existing on-board
protocols and applications which = communicate with the Internet,
possibly via multiple = radios.

In a moving network deployed in an automobile, typically = one exit
point connects the moving network to other moving = networks.  However,
in a more general manner (and to support = reliability) any new
mechanism of moving network to nearby moving = network communications
should support multi-homing: one router to use = multiple interfaces
towards outside the moving network, or multiple = routers.

Current version of Internet = protocols
-------------------------------------
The group will = only work on IPv6 solutions.

What SDOs may need this = work?
-----------------------------
The requirements and standards = for moving network to nearby moving
network communications, often = involving IPv6, and novel V2V and
V2Infra concepts, are developed = mainly at ISO TC204 "Intelligent
Transport Systems", 3GPP, = ETSI, NHTSA and IEEE.  For
Vehicle-to-Internet communications, = 3GPP LTE and other cellular
technologies represent the long-range = connectivity method; for
Vehicle-to-Vehicle communications, LTE = Direct is currently specified,
as well as OCB mode of IEEE = 802.11.  Several use-cases exhibit a need
for IPv6 data = exchanges between vehicles: ETSI's Cooperative Adaptive
Cruise = Control and Platooning.  The IEEE developed a popular link = for
short-range communications - IEEE 802.11p "WAVE".  = The NHTSA wrote a
set of requirements for V2V = communications.

Work Items
----------
- use-cases for = moving network to nearby moving network communications
- Problem = Statement for moving network to nearby moving network = communications
  including V2V, V2I and DNS.
- Security and = Privacy Requirements for moving network to
  nearby moving = network communications
- Solutions, which might include new protocols = or extensions to
  existing protocols.  With MIB.
- = IPv6-over foo, where foo is pertinent for moving network to = nearby
  moving network communications (e.g. 802.11 OCB, VLC, = LTE-D, 802.11ad)
- List of Research Papers in the V2V domain, = identifying which uses = IP.

Timeline
--------
-

------=_NextPart_000_0094_01D1906A.5A217410-- From nobody Wed Apr 6 16:11:44 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F2012D76A for ; Wed, 6 Apr 2016 16:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jm5PKkaXbfTf for ; Wed, 6 Apr 2016 16:11:40 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5765A12D160 for ; Wed, 6 Apr 2016 16:11:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u36NBcrM006497; Thu, 7 Apr 2016 01:11:38 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5F945204552; Thu, 7 Apr 2016 01:12:47 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 53EC8204534; Thu, 7 Apr 2016 01:12:47 +0200 (CEST) Received: from [132.166.84.226] ([132.166.84.226]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u36NBYmu024651; Thu, 7 Apr 2016 01:11:35 +0200 To: Dino Farinacci References: <57058375.6050101@gmail.com> <6B2D2039-34AD-41BA-9B9D-61164C9043CB@gmail.com> From: Alexandre Petrescu Message-ID: <570597A5.9050902@gmail.com> Date: Wed, 6 Apr 2016 20:11:33 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <6B2D2039-34AD-41BA-9B9D-61164C9043CB@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 23:11:43 -0000 Le 06/04/2016 19:57, Dino Farinacci a crit : > >> On Apr 6, 2016, at 2:45 PM, Alexandre Petrescu wrote: >> >> ITSers, >> >> Please see below the current charter. >> >> - the two Problem Statements drafts V2V and V2I joined, so there is less text in charter. >> - added an Item on "List of Research papers..." >> >> Erik: did I understand you correctly that there should be some item on discussing whether link-local addressing is sufficient, whether prefix exchange is necessary? >> >> Dino: should LISP be included in the gap analysis draft which includes C-ACC use-case? OR should we separate a dedicated I-D only with gap analysis including ND, MIP, AODVv2, LISP? > > LISP is an architecture that can be used for IP (EID) mobility. So I would say yes. 'Yes' means that you would prefer one I-D which is dedicated to gap analysis? (and that includes considerations of IP (EID)? This gap analysis draft would not describe C-ACC/Platooning use-case. It would just do gap analysis. Alex > > Dino > >> >> Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle interface illustrated good enough by the words "moving network to nearby moving network communications"? Or is it better to say "the 1-IP-hop between nearby moving networks must be self-configured"? >> >> Nabil, Sandra: is it ok to have a working group item "List of Research Papers for IP in V2V and V2I communications"? >> >> Other comments? >> >> Alex >> >> ------------------------------------------------------------------ >> >> ITS (name to change) >> Charter >> April 6th, 2016 >> http://ietf.org/mailman/listinfo/its >> >> >> Intelligent Transportation Systems (its) >> ---------------------------------------- >> Current Status: WG forming >> >> Chairs: >> TBD >> >> Assigned Area Director: >> TBD >> >> Mailing list >> Address: its@ietf.org >> 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: >> >> Goal >> ---- >> The goal of this group is to standardize IP-based protocols for >> establishing direct and secure connectivity between moving networks, >> some of which could be fixed permanently or temporarily. >> >> Moving Network to Nearby Moving Network Communications >> ------------------------------------------------------ >> The group is concerned with all situations involving moving network to >> nearby moving network communications. For example: vehicle-to-vehicle >> communications, nomadic user wearing a PAN and communicating to a >> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a >> train, or train-to-intersection signalling. >> >> Example from the automobile communications space >> ------------------------------------------------ >> Automobiles and vehicles of all types are increasingly connected to >> the Internet, either as vehicle-to-vehicle, vehicle-to-infra or >> vehicle-to-Internet. Entertainment apps enhancing comfort, reliable >> data exchanges for road safety, and automated driving are features >> coming in automobiles to hit the roads from now to year 2020. >> Highlighting increased safety as an immediate result of >> hyper-connectivity applied to vehicles, public authorities worldwide >> are increasingly mandating secure communication technology >> requirements in vehicles. >> >> Emergency apps for new instrumented ambulances carry many benefits >> both to the users and to society in general. >> >> Why IP? >> ------- >> Today, there are several deployed Vehicle-to-Internet technologies, >> including car tethering through driver's cellular smartphone. >> However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure >> communications are still being developed. To improve on a situation >> of link-specific data exchanges, and enable independent application >> sets to share the same links, IP data exchanges are needed. Enabling >> IP communication between vehicles (V2V), and between vehicles and the >> immediate infrastructure (V2I), will provide (0) ability to reach the >> rest of the world on the Internet (1) short and deterministic delays, >> (2) fast forwarding through scalable paths of routers, (3) ease of >> reuse of existing Internet applications in a vehicular environment. >> >> Moving network to nearby moving network communications involve link >> layers such as: 802.11p OCB (Outside the Context of a Basic Service >> Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light >> Communications), IrDA, LTE-D. Only the IP protocols are capable of >> running on each of these links and establish IP paths across them in >> an interoperable manner. >> >> Scenarios? >> ---------- >> There are a few scenarios exhibiting the need to communicate from one >> moving network to another nearby moving network. >> >> In the automobile space, the Cooperative Adaptive Cruise Control and >> Platooning features consider that vehicles close to each other >> exchange data describing their kinematic status. At the cross-roads, >> the moving network inside a vehicle exchanges data with the moving >> network in the red-light pole. >> >> Several public safety scenarios involve moving networks. Distinct >> organizations deploy different moving networks (in-vehicle, on-person) >> at an incident scene. These networks need to interoperate in order to >> more effectively understand and deal with the incident scene. >> >> In connected rail scenarios the moving network deployed in trains >> communicate with other moving networks at the cross-points. >> >> What kind of solutions? >> ----------------------- >> The current technical solutions considered to achieve moving network >> to nearby moving network communications are of two kinds: IP routing >> protocols for n-hop path management and 1-hop link-scoped IP protocol >> enhancements. The 1-hop link-scoped protocols include the protocols >> for route establishment involving ICMP Router Advertisements. The >> n-hop path management protocols include n-hop path establishment >> protocols (e.g. Babel, OSPF) and n-hop path search protocols (most >> notably AODV and derivates). >> >> In this proposed Working Group the focus is on 1-hop protocols, and >> leverage from other Working Groups for the n-hop situations. >> >> In some of the moving network applications the window of opportunity >> for exchanging data with the immediate infrastructure may be very >> short. For example, a car driving near a road-side unit may have only >> 5s to exchange with that RSU (depending on speed, RSU range and >> number). (ephemeral connections). >> >> What kind of requirements? >> -------------------------- >> The requirements for mechanisms for moving network to nearby moving >> network communications are focusing on low delays of the data paths, >> reduced number of messages for path establishment, application >> friendly, resilience to attacks, compatibility with DHCP and Mobile >> IP. >> >> In addition, some moving network to nearby moving network applications >> involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the >> 1-hop IP moving network to nearby moving netowrk mechanisms will need >> to gracefully support IP multicast. >> >> Due to the inherent characteristics of safety-related communications, >> all new moving network to nearby moving network mechanisms must afford >> authenticity and confidentiality where necessary. Dynamically >> establishing ephemeral communication paths between automobiles in >> public areas must offer privacy safeguards for the end users >> (passengers). >> >> Establishing 1-hop IP V2V paths must not break the existing on-board >> protocols and applications which communicate with the Internet, >> possibly via multiple radios. >> >> In a moving network deployed in an automobile, typically one exit >> point connects the moving network to other moving networks. However, >> in a more general manner (and to support reliability) any new >> mechanism of moving network to nearby moving network communications >> should support multi-homing: one router to use multiple interfaces >> towards outside the moving network, or multiple routers. >> >> Current version of Internet protocols >> ------------------------------------- >> The group will only work on IPv6 solutions. >> >> What SDOs may need this work? >> ----------------------------- >> The requirements and standards for moving network to nearby moving >> network communications, often involving IPv6, and novel V2V and >> V2Infra concepts, are developed mainly at ISO TC204 "Intelligent >> Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For >> Vehicle-to-Internet communications, 3GPP LTE and other cellular >> technologies represent the long-range connectivity method; for >> Vehicle-to-Vehicle communications, LTE Direct is currently specified, >> as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need >> for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive >> Cruise Control and Platooning. The IEEE developed a popular link for >> short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a >> set of requirements for V2V communications. >> >> Work Items >> ---------- >> - use-cases for moving network to nearby moving network communications >> - Problem Statement for moving network to nearby moving network communications >> including V2V, V2I and DNS. >> - Security and Privacy Requirements for moving network to >> nearby moving network communications >> - Solutions, which might include new protocols or extensions to >> existing protocols. With MIB. >> - IPv6-over foo, where foo is pertinent for moving network to nearby >> moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) >> - List of Research Papers in the V2V domain, identifying which uses IP. >> >> Timeline >> -------- >> - >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > From nobody Wed Apr 6 16:21:56 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD9112D74C for ; Wed, 6 Apr 2016 16:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHPODOsqWNk3 for ; Wed, 6 Apr 2016 16:21:53 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606D412D778 for ; Wed, 6 Apr 2016 16:21:53 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id o6so24164287qkc.2 for ; Wed, 06 Apr 2016 16:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HOsZyDWKLEmoAmE+gJs7jiK90ZPmmjrJypJ9FYSOO90=; b=w22eiCBmWN2gET2XpFECkIPO8hGwlCKbWQDTb8PnZmwkDxiOpQSyASsvMZl2NDeCGg UcoYiG+011HO/DsLEhr2sXf6JoIVY7f6VyxoHNvWDXeeJQz8cWf7nXcR33eSDK1pb/9Z i2Q9OIUc+5LAOrDxcnV//NEYwjmbYUzS6/XCUBkE7GFwOeh4rqQe9jC31oYa9jkbPFbX h1uB5s8qyP922FBBPZrTgrqX/aPb3zXoIQKcFBKyrjl9KQT4Hzdfxdfr9nygG4WoeOHX LNUAJBKg5REmqsMYOtHz/B6YnxTBXqU9FmnkGFADctQ7d1F0zySsLnzSdfe7wqa+L99v nQ5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HOsZyDWKLEmoAmE+gJs7jiK90ZPmmjrJypJ9FYSOO90=; b=miEJxvb2S4lnafZobOkMsMj2BQISv+nthfeTzaB7ajpQkxs1w45TCrdoAu2KTxv3Az LfxEg6NMd6TzEmD111QMnV5WGRuRSIudGKN69ZFv8RoRBUv+1Dcyc9dnsqK+zJANzgaP tryVDYVoXhVagH/NxGCj/my3h/wZ4m09ipoOy+mNFNqPbpYk6mc9Uo++7GNV1b1AY4hg PQR7Uj5W45xnu7tvPZtt4CQIDuHqvyshH67FrLuIAaWBcfEZ8pvoDagPVgyg8Tg6zPbV zLJqJbdlfqfQH9vPyPjtKoFHZgnBp7597m5Vt3a4VdiOlS2GHcsnMoivYgYyeO24MBFm rU3A== X-Gm-Message-State: AD7BkJL4DfsiSjDi3SpC8gzk2jekf+cCpxzE7zxm1U5LJ92We+BftsgC5pZeBRzOkOgHjw== X-Received: by 10.55.77.216 with SMTP id a207mr50332005qkb.80.1459984912542; Wed, 06 Apr 2016 16:21:52 -0700 (PDT) Received: from [172.17.74.180] (200-127-148-163.net.prima.net.ar. [200.127.148.163]) by smtp.gmail.com with ESMTPSA id x189sm2237102qhb.43.2016.04.06.16.21.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 16:21:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: <570597A5.9050902@gmail.com> Date: Wed, 6 Apr 2016 16:21:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57058375.6050101@gmail.com> <6B2D2039-34AD-41BA-9B9D-61164C9043CB@gmail.com> <570597A5.9050902@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 23:21:55 -0000 > 'Yes' means that you would prefer one I-D which is dedicated to gap = analysis? (and that includes considerations of IP (EID)? We know how to do the v2i piece with LISP. Yes, with one static EID per = vehicle. We have some production deployments that use the same solution = in the data center and other sectors. > This gap analysis draft would not describe C-ACC/Platooning use-case. = It would just do gap analysis. For the v2v case, LISP isn=92t appropriate because it would need to = depend on infrastructure and that signalling would kill the responsive = the v2v needs for motion critical actions. Dino From nobody Wed Apr 6 16:44:53 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91C312D12C for ; Wed, 6 Apr 2016 16:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKrUAn3uxL0O for ; Wed, 6 Apr 2016 16:44:30 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF9112D7DD for ; Wed, 6 Apr 2016 16:44:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u36NiMSS018254; Thu, 7 Apr 2016 01:44:22 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B019A204544; Thu, 7 Apr 2016 01:45:31 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9B0CA204534; Thu, 7 Apr 2016 01:45:31 +0200 (CEST) Received: from [132.166.84.226] ([132.166.84.226]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u36NiK1E013260; Thu, 7 Apr 2016 01:44:21 +0200 To: Dino Farinacci References: <57058375.6050101@gmail.com> <6B2D2039-34AD-41BA-9B9D-61164C9043CB@gmail.com> <570597A5.9050902@gmail.com> From: Alexandre Petrescu Message-ID: <57059F53.5030106@gmail.com> Date: Wed, 6 Apr 2016 20:44:19 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 23:44:41 -0000 Le 06/04/2016 20:21, Dino Farinacci a crit : >> 'Yes' means that you would prefer one I-D which is dedicated to gap >> analysis? (and that includes considerations of IP (EID)? > > We know how to do the v2i piece with LISP. Yes, with one static EID > per vehicle. We have some production deployments that use the same > solution in the data center and other sectors. Any new solution designed in this group must not alter what you know to do v2i with LISP. For example, if there is prefix exchange between vehicle and an RSU that must not break LISP from doing v2i (vehicle to Internet) through that same RSU. There is a similar problem in Mobile IP. If so, then this should be described so in the gap analysis or in a requirements draft. Which one would you prefer? (RSU: Road Side Unit: a set of computers linked by Ethernet and situated in a box along the road, to control traffic lights and other embedded sensors, and also do 802.11p to the vehicle; an RSU is connected to the Internet by either ADSL or its own cellular link). >> This gap analysis draft would not describe C-ACC/Platooning >> use-case. It would just do gap analysis. > > For the v2v case, LISP isnt appropriate because it would need to > depend on infrastructure and that signalling would kill the > responsive the v2v needs for motion critical actions. That sounds like text to be put in a gap analysis draft. So I think what I propose is to have a separate gap analysis draft, and a separate requirements draft. Is this ok with you? Alex > > Dino > > From nobody Wed Apr 6 16:54:17 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD8F12D15B for ; Wed, 6 Apr 2016 16:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah-I_hV0So9n for ; Wed, 6 Apr 2016 16:54:13 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8082D12D161 for ; Wed, 6 Apr 2016 16:54:12 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id f198so3482202wme.0 for ; Wed, 06 Apr 2016 16:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=0LAgw0HPZjZMzA7hRIheLWS2HX6HDXjBKcSFe8gfay4=; b=SBprqMxlASES3IkFMvb0KUK1kp/a411YOyj/TABIhZKnwNZH7o1iLJTda93OQJL5rI 2yc47PkO4E9rsiGBwGrqYhSO4XCpNsSVT0/0jptIJ6kS7+1nU2E/3Pda7ufznIka2ei/ PyUM6MVk7CDirTjdtDVhx2yjeXMFisPWV4bh/LfomzsszJ29ErR9L0jgdZJL5RtV7j9h ex96ockBwgDodXF3T7eq6r6JEAz9iedoQYWjVCI8lq520zmwvjKH/hkoszLja6YQRZ1N qH60BxlFtvex83qTXNZLaUyp7P1pP0dTs1ghbcagt71Gtovh9w+Le5Z7mHWBmhuYMB7M qqUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=0LAgw0HPZjZMzA7hRIheLWS2HX6HDXjBKcSFe8gfay4=; b=LZkk6VO3G7Pn3TWLJIng3OuYpd4Mrz8qDkhkswIb+10Tm8+sUIN2OJdH28TQM97571 CHJJtDmWnbdX/fSaTrmGAnzwV0kErgh2MdU0w1xWp/AVmdseJ+AxBZ/tUE0Muj/bx7mL 7mSjtIvwDznmC8uu6EobzK3uT4+kUatfTuCvAGfotU+iFnrWaFKubYxLQzZ8pyDZKeJ3 bBh9fQTxElwnHfH+QTwwS7SWd71ofOZN+cQmwD34CQApr7aEwIn5UPwnBbVNdpdl3aOi CquygQSx9sJL0lR4j5TLvV6ACE4Y1egoPVCxAzRwZLy3wUZZo3E1sc89qzabcMxBcvl+ +zgA== X-Gm-Message-State: AD7BkJIats1rYXRjt8Hdf3JurrEEx0hxc4IhWaVHNvtZiMVMTt+F8Zn7+9awxnTUp3vrCnKYBYpasSL9f0xTZA== MIME-Version: 1.0 X-Received: by 10.194.84.66 with SMTP id w2mr93523wjy.6.1459986850943; Wed, 06 Apr 2016 16:54:10 -0700 (PDT) Received: by 10.28.224.137 with HTTP; Wed, 6 Apr 2016 16:54:10 -0700 (PDT) In-Reply-To: <57058375.6050101@gmail.com> References: <57058375.6050101@gmail.com> Date: Wed, 6 Apr 2016 20:54:10 -0300 Message-ID: From: Nabil Benamar To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=047d7bb04faaa09979052fd9add5 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 23:54:16 -0000 --047d7bb04faaa09979052fd9add5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alex, Yes, I agree that listing the research papers related to V2I and V2V is a working item. Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Wed, Apr 6, 2016 at 6:45 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > ITSers, > > Please see below the current charter. > > - the two Problem Statements drafts V2V and V2I joined, so there is less > text in charter. > - added an Item on "List of Research papers..." > > Erik: did I understand you correctly that there should be some item on > discussing whether link-local addressing is sufficient, whether prefix > exchange is necessary? > > Dino: should LISP be included in the gap analysis draft which includes > C-ACC use-case? OR should we separate a dedicated I-D only with gap > analysis including ND, MIP, AODVv2, LISP? > > Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle > interface illustrated good enough by the words "moving network to nearby > moving network communications"? Or is it better to say "the 1-IP-hop > between nearby moving networks must be self-configured"? > > Nabil, Sandra: is it ok to have a working group item "List of Research > Papers for IP in V2V and V2I communications"? > > Other comments? > > Alex > > ------------------------------------------------------------------ > > ITS (name to change) > Charter > April 6th, 2016 > http://ietf.org/mailman/listinfo/its > > > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming > > Chairs: > TBD > > Assigned Area Director: > TBD > > Mailing list > Address: its@ietf.org > 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: > > Goal > ---- > The goal of this group is to standardize IP-based protocols for > establishing direct and secure connectivity between moving networks, > some of which could be fixed permanently or temporarily. > > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving network to > nearby moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > train, or train-to-intersection signalling. > > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to > the Internet, either as vehicle-to-vehicle, vehicle-to-infra or > vehicle-to-Internet. Entertainment apps enhancing comfort, reliable > data exchanges for road safety, and automated driving are features > coming in automobiles to hit the roads from now to year 2020. > Highlighting increased safety as an immediate result of > hyper-connectivity applied to vehicles, public authorities worldwide > are increasingly mandating secure communication technology > requirements in vehicles. > > Emergency apps for new instrumented ambulances carry many benefits > both to the users and to society in general. > > Why IP? > ------- > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. > However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure > communications are still being developed. To improve on a situation > of link-specific data exchanges, and enable independent application > sets to share the same links, IP data exchanges are needed. Enabling > IP communication between vehicles (V2V), and between vehicles and the > immediate infrastructure (V2I), will provide (0) ability to reach the > rest of the world on the Internet (1) short and deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) ease of > reuse of existing Internet applications in a vehicular environment. > > Moving network to nearby moving network communications involve link > layers such as: 802.11p OCB (Outside the Context of a Basic Service > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light > Communications), IrDA, LTE-D. Only the IP protocols are capable of > running on each of these links and establish IP paths across them in > an interoperable manner. > > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate from one > moving network to another nearby moving network. > > In the automobile space, the Cooperative Adaptive Cruise Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the cross-roads, > the moving network inside a vehicle exchanges data with the moving > network in the red-light pole. > > Several public safety scenarios involve moving networks. Distinct > organizations deploy different moving networks (in-vehicle, on-person) > at an incident scene. These networks need to interoperate in order to > more effectively understand and deal with the incident scene. > > In connected rail scenarios the moving network deployed in trains > communicate with other moving networks at the cross-points. > > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol > enhancements. The 1-hop link-scoped protocols include the protocols > for route establishment involving ICMP Router Advertisements. The > n-hop path management protocols include n-hop path establishment > protocols (e.g. Babel, OSPF) and n-hop path search protocols (most > notably AODV and derivates). > > In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations. > > In some of the moving network applications the window of opportunity > for exchanging data with the immediate infrastructure may be very > short. For example, a car driving near a road-side unit may have only > 5s to exchange with that RSU (depending on speed, RSU range and > number). (ephemeral connections). > > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to nearby moving > network communications are focusing on low delays of the data paths, > reduced number of messages for path establishment, application > friendly, resilience to attacks, compatibility with DHCP and Mobile > IP. > > In addition, some moving network to nearby moving network applications > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the > 1-hop IP moving network to nearby moving netowrk mechanisms will need > to gracefully support IP multicast. > > Due to the inherent characteristics of safety-related communications, > all new moving network to nearby moving network mechanisms must afford > authenticity and confidentiality where necessary. Dynamically > establishing ephemeral communication paths between automobiles in > public areas must offer privacy safeguards for the end users > (passengers). > > Establishing 1-hop IP V2V paths must not break the existing on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. > > In a moving network deployed in an automobile, typically one exit > point connects the moving network to other moving networks. However, > in a more general manner (and to support reliability) any new > mechanism of moving network to nearby moving network communications > should support multi-homing: one router to use multiple interfaces > towards outside the moving network, or multiple routers. > > Current version of Internet protocols > ------------------------------------- > The group will only work on IPv6 solutions. > > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to nearby moving > network communications, often involving IPv6, and novel V2V and > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For > Vehicle-to-Internet communications, 3GPP LTE and other cellular > technologies represent the long-range connectivity method; for > Vehicle-to-Vehicle communications, LTE Direct is currently specified, > as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need > for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive > Cruise Control and Platooning. The IEEE developed a popular link for > short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a > set of requirements for V2V communications. > > Work Items > ---------- > - use-cases for moving network to nearby moving network communications > - Problem Statement for moving network to nearby moving network > communications > including V2V, V2I and DNS. > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Solutions, which might include new protocols or extensions to > existing protocols. With MIB. > - IPv6-over foo, where foo is pertinent for moving network to nearby > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) > - List of Research Papers in the V2V domain, identifying which uses IP. > > Timeline > -------- > - > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --047d7bb04faaa09979052fd9add5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alex,

Yes, I agree that listing the rese= arch papers related to V2I and V2V is a working item.=C2=A0

= Best regards
Nabil Benamar
-------------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9= =D9=85=D8=B1=D9=88


On Wed, Apr 6, 2016 at 6:45 PM, Alexandre Pe= trescu <alexandre.petrescu@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> =20 =20 =20
ITSers,

Please see below the current charter.

- the two Problem Statements drafts V2V and V2I joined, so there is less text in charter.
- added an Item on "List of Research papers..."

Erik: did I understand you correctly that there should be some item on discussing whether link-local addressing is sufficient, whether prefix exchange is necessary?

Dino: should LISP be included in the gap analysis draft which includes C-ACC use-case?=C2=A0 OR should we separate a dedicated I-D only with gap analysis including ND, MIP, AODVv2, LISP?

Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle interface illustrated good enough by the words "moving network to nearby moving network communications"?= =C2=A0 Or is it better to say "the 1-IP-hop between nearby moving networks mu= st be self-configured"?

Nabil, Sandra: is it ok to have a working group item "List of Research Papers for IP in V2V and V2I communications"?

Other comments?

Alex

------------------------------------------------------------------
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ITS (name to change)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Charter
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 April 6th, 2016
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://ietf.org/mailman/list= info/its


Intelligent Transportation Systems (its)
----------------------------------------
Current Status: WG forming

Chairs:
=C2=A0=C2=A0 TBD

Assigned Area Director:
=C2=A0=C2=A0 TBD

Mailing list
=C2=A0=C2=A0 Address: its@ietf.org
=C2=A0=C2=A0 To Subscribe: https://www.ietf.org/mailman/listinfo/its=
=C2=A0=C2=A0 Archive:
=C2=A0=C2=A0 http://www.ietf.org/mail-archive/web/i= ts/current/maillist.html

Additional web page
=C2=A0=C2=A0 TBD

Charter:

Goal
----
The goal of this group is to standardize IP-based protocols for
establishing direct and secure connectivity between moving networks,
some of which could be fixed permanently or temporarily.

Moving Network to Nearby Moving Network Communications
------------------------------------------------------
The group is concerned with all situations involving moving network to
nearby moving network communications.=C2=A0 For example: vehicle-to-vehicle
communications, nomadic user wearing a PAN and communicating to a
homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a
train, or train-to-intersection signalling.

Example from the automobile communications space
------------------------------------------------
Automobiles and vehicles of all types are increasingly connected to
the Internet, either as vehicle-to-vehicle, vehicle-to-infra or
vehicle-to-Internet.=C2=A0 Entertainment apps enhancing comfort, reliable
data exchanges for road safety, and automated driving are features coming in automobiles to hit the roads from now to year 2020.
Highlighting increased safety as an immediate result of
hyper-connectivity applied to vehicles, public authorities worldwide
are increasingly mandating secure communication technology
requirements in vehicles.

Emergency apps for new instrumented ambulances carry many benefits both to the users and to society in general.

Why IP?
-------
Today, there are several deployed Vehicle-to-Internet technologies,
including car tethering through driver's cellular smartphone.
However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communications are still being developed.=C2=A0 To improve on a situation
of link-specific data exchanges, and enable independent application
sets to share the same links, IP data exchanges are needed.=C2=A0 Enabling
IP communication between vehicles (V2V), and between vehicles and the
immediate infrastructure (V2I), will provide (0) ability to reach the
rest of the world on the Internet (1) short and deterministic delays,
(2) fast forwarding through scalable paths of routers, (3) ease of reuse of existing Internet applications in a vehicular environment.

Moving network to nearby moving network communications involve link
layers such as: 802.11p OCB (Outside the Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light
Communications), IrDA, LTE-D.=C2=A0 Only the IP protocols are capable of
running on each of these links and establish IP paths across them in
an interoperable manner.

Scenarios?
----------
There are a few scenarios exhibiting the need to communicate from one
moving network to another nearby moving network.

In the automobile space, the Cooperative Adaptive Cruise Control and
Platooning features consider that vehicles close to each other
exchange data describing their kinematic status.=C2=A0 At the cross-roads,
the moving network inside a vehicle exchanges data with the moving network in the red-light pole.

Several public safety scenarios involve moving networks.=C2=A0 Distin= ct
organizations deploy different moving networks (in-vehicle, on-person)
at an incident scene.=C2=A0 These networks need to interoperate in order to
more effectively understand and deal with the incident scene.

In connected rail scenarios the moving network deployed in trains
communicate with other moving networks at the cross-points.

What kind of solutions?
-----------------------
The current technical solutions considered to achieve moving network
to nearby moving network communications are of two kinds: IP routing
protocols for n-hop path management and 1-hop link-scoped IP protocol
enhancements.=C2=A0 The 1-hop link-scoped protocols include the protocols
for route establishment involving ICMP Router Advertisements.=C2=A0 T= he
n-hop path management protocols include n-hop path establishment
protocols (e.g. Babel, OSPF) and n-hop path search protocols (most notably AODV and derivates).

In this proposed Working Group the focus is on 1-hop protocols, and
leverage from other Working Groups for the n-hop situations.

In some of the moving network applications the window of opportunity
for exchanging data with the immediate infrastructure may be very
short.=C2=A0 For example, a car driving near a road-side unit may hav= e only
5s to exchange with that RSU (depending on speed, RSU range and
number). (ephemeral connections).

What kind of requirements?
--------------------------
The requirements for mechanisms for moving network to nearby moving
network communications are focusing on low delays of the data paths,
reduced number of messages for path establishment, application
friendly, resilience to attacks, compatibility with DHCP and Mobile
IP.

In addition, some moving network to nearby moving network applications
involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP moving network to nearby moving netowrk mechanisms will need
to gracefully support IP multicast.

Due to the inherent characteristics of safety-related communications,
all new moving network to nearby moving network mechanisms must afford
authenticity and confidentiality where necessary.=C2=A0 Dynamically establishing ephemeral communication paths between automobiles in
public areas must offer privacy safeguards for the end users
(passengers).

Establishing 1-hop IP V2V paths must not break the existing on-board
protocols and applications which communicate with the Internet,
possibly via multiple radios.

In a moving network deployed in an automobile, typically one exit
point connects the moving network to other moving networks.=C2=A0 However,
in a more general manner (and to support reliability) any new
mechanism of moving network to nearby moving network communications
should support multi-homing: one router to use multiple interfaces towards outside the moving network, or multiple routers.

Current version of Internet protocols
-------------------------------------
The group will only work on IPv6 solutions.

What SDOs may need this work?
-----------------------------
The requirements and standards for moving network to nearby moving network communications, often involving IPv6, and novel V2V and
V2Infra concepts, are developed mainly at ISO TC204 "Intelligent=
Transport Systems", 3GPP, ETSI, NHTSA and IEEE.=C2=A0 For
Vehicle-to-Internet communications, 3GPP LTE and other cellular
technologies represent the long-range connectivity method; for
Vehicle-to-Vehicle communications, LTE Direct is currently specified,
as well as OCB mode of IEEE 802.11.=C2=A0 Several use-cases exhibit a need
for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive
Cruise Control and Platooning.=C2=A0 The IEEE developed a popular lin= k for
short-range communications - IEEE 802.11p "WAVE".=C2=A0 The= NHTSA wrote a
set of requirements for V2V communications.

Work Items
----------
- use-cases for moving network to nearby moving network communications
- Problem Statement for moving network to nearby moving network communications
=C2=A0 including V2V, V2I and DNS.
- Security and Privacy Requirements for moving network to
=C2=A0 nearby moving network communications
- Solutions, which might include new protocols or extensions to
=C2=A0 existing protocols.=C2=A0 With MIB.
- IPv6-over foo, where foo is pertinent for moving network to nearby
=C2=A0 moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)
- List of Research Papers in the V2V domain, identifying which uses IP.

Timeline
--------
-

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its


--047d7bb04faaa09979052fd9add5-- From nobody Wed Apr 6 17:57:28 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF1112D7DB for ; Wed, 6 Apr 2016 17:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utea-tuvn2rf for ; Wed, 6 Apr 2016 17:57:25 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3AC12D180 for ; Wed, 6 Apr 2016 17:57:24 -0700 (PDT) Received: by mail-lb0-x22c.google.com with SMTP id u8so40214206lbk.0 for ; Wed, 06 Apr 2016 17:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ZqMWgjj63kBaoOKqtPZvglRGK5IVycHQgNBauIay4go=; b=IHSrtykxTOHh1VwykuJjZgI/p3Kc5gYtlgC8wK1/R7XOb+ZE02vkcArJ0u3/JiJCFh HjBYWAsFuTlXYohbayLoUT9mM7RoYkpoHwvoeW4sCyEZJ806VUELl6avIJdnqyX4HJzI 2NRYalxZnpNaLEhj5J5Vono59FagI9e2ZyICap1tKHr5iOA35RoecxJ9k7cw9oc8huh8 eFfOmkFjQA40OGqrP5DW+VjmwutZQevnpfBiZoSmCoZBYPMOPc1s+JKq/C6SZXA0PYzY UQx6PAgmT1KbhNaUXAL5/+Cat/PtmwMglr6qr73il3QcmN9YUyEnEkzV1LgDNbOv4zjJ 8jVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ZqMWgjj63kBaoOKqtPZvglRGK5IVycHQgNBauIay4go=; b=GbARMuCc3lo3VW8uKGifpyoKFb5qp0WLIrYxgGEdbXFIyFv2uQVYTnKPt60SBiDpIQ 2CnYK/upVRf5ejxq+ZG5xIRnL7LVJ4LEGU97/ImIPumI8Jqhc2ulVNsd3+JhfFxCYOzC cme4FqhGHhVvwUlOH1yAy8c/RlzuHPMUhTTHl5YktxvJqHYgaMwkps/+4QSP+AASxiB0 WiAcllPIOUdkGFhLgLg6VHJBBc/iqRXZZf28f7saY9YPkQobXNjxsbeJibaaBxGo3dWU /Wfr7yqe4JZOOrJPz9RikJjd/UjzZFr2Ua1y9uQycG9tt7PyDdt/3ff1yFVk29vuIU7z qcdg== X-Gm-Message-State: AD7BkJLeZgVZE4PvKmdVMGAPFRhM/Uo47nqNN99380i6yfuXY+O4zgS/wS/4CweGqdAC9W4SE/V1IfUo7DjASw== MIME-Version: 1.0 X-Received: by 10.112.170.201 with SMTP id ao9mr90869lbc.38.1459990642700; Wed, 06 Apr 2016 17:57:22 -0700 (PDT) Received: by 10.112.167.105 with HTTP; Wed, 6 Apr 2016 17:57:22 -0700 (PDT) In-Reply-To: <570591D1.4070904@gmail.com> References: <570591D1.4070904@gmail.com> Date: Wed, 6 Apr 2016 21:57:22 -0300 Message-ID: From: Michelle Wetterwald To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a11c36bdca236f7052fda8fdd Archived-At: Cc: "its@ietf.org" Subject: Re: [its] Raw meeting minutes X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 00:57:27 -0000 --001a11c36bdca236f7052fda8fdd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alex, all, Thank you for these minutes I would like to rephrase here the two comments that I made during the meeting to the V2I problem statement draft and could not be captured in the minutes: - in the V2I case, the performance of the system and the coverage time vs. vehicle speed should be taken into account. At the contrary of the V2V C-ACC case you described where both cars are moving in the same direction, which ensures some time to exchange prefixes, names, etc., in the V2I case, the coverage time with one RSU may be short. Thus this signalling should have a really low latency. - Secondly, the potential congestion of the system when hundreds of cars would be located in the same area and establishing or using V2I communications should also be taken into account as an issue. Switching part of the traffic to a more available channel, as was proposed, may not always be possible. Reducing the size of the packet, however, by using header compression technique as in 6lo, may offer a potential improvement. Best regards, Michelle Wetterwald ---- Senior expert in networking and telecommunications 2016-04-06 19:46 GMT-03:00 Alexandre Petrescu : > Raw meeting minutes, thanks to minute takers for efforts despite echo-ey > PA system. > > Alex > > ------------------------------------------------------------------ > > Minutes for [its] > > =E2=80=A2 Introduction: > > > =E2=80=93 Administrative - BOF Chairs - 5 min > > > =E2=80=93 ITS Goals and Success Criteria - BOF Chairs - 10 min > > > =E2=80=A2 Problem Space: > > > =E2=80=93 Tutorial of IP in vehicular communications - Alex Petrescu - 20= min > Randel Gelland: Since there are so many MAC & PHY, they use their own > messaging -- so could use IP. But vehicals are using different PHY > & MAC, so they can't communicate > Alex: But some of the radios are actually compatible > > Bob Hinden: On "Topology" slide -- this is very simplified. There will b= e > many cars, with very dynamic interconnection > Alex: Yes. Gives more examples to support contention > > Dapeng Liu: Once connectivity is established, > IP will enable better communication. > > Pat Thaler: Even for compatible PHY, MACs may be different, so can't just > day > "use IP" > > Erik Nordmark: Have people considered what the IP addressing will look > like? > In the car, the addressing is stable, but not outside the car. How > does one car know the address in the other car? > Alex: Yes, people are working on this. IETF can help. > > Carlos: Are people working on the addressing sheme. > > Dino: We have an IP mobility problem > > Dirk Kircher: Broadcast. Semantic layer. > Alex: There may be multiple hops beween cars, and multiple hops in a car. > May need IPv4 broadcast, or IPv6 broadcast > > Dino: Even without the mobility problem, we still would have physical lay= er > incompatible problems. But that is exactly what IP solves. > > =E2=80=93 ITS use-cases C-ACC and Platooning - Alex Petrescu - 10 min > draft-petrescu-its-cacc-sdo-04 > > > Lou Berger: Hackable. What's the security model? > Alex: Do not have slides about this. > Eric Rescolo: Why make any representation about exceeding speedlimit. > Alex: It's just an example > Eric Rescolo: What if the police ask this question? > > > Sandra: there is a lot of work being done on security > =3D Safety part > > Eric Burdick: There are a lot of privacy issues. There is work about > jamming. > It's not just Mobile IP. > > Erik Nordmark: There was an IETF plenary that is relevant to security. > =3D Police can probaly go get the data > > Eric Rescolo: Lots of work to be done -- prevent querying in the car. > > > =E2=80=93 ITS V2V problem statement - Dapeng Liu - 5 min > draft-petrescu-its-problem-00 > > Randel Gelland: How do they know when they need to discover the other > vehicles' > address? > Dirk Kircher: Sub-Problem(1) needs to be characterized correctly. What i= s > a > realistic use case: Answer: C-ACC > > ...: do you have data? > Alex: How much data do you want? > > Randel Gellens: This shows how IP is useful, but it's not why IP is neede= d? > So it is needed to exhibit the need, not just the use case. > > Erik Nordmark: how identities (or even temporary identities) established? > > Hannes Tshofenig: Is there a need for another layer for identity? > > > =E2=80=93 ITS V2I problem statement - Jaehoon Paul Jeong - 5 min > draft-jeong-its-v2i-problem-statement-00 > > Charlie: What does it mean to "directly" connect to the RSO's network > Jaehoon: Exchange prefixes > > Woman > > Dino: a lost packet could be a catastrophe, amidst a lot of connection. > Need to avoid chit-chat. Should avoid multiple solutions. > If security requires Diffie-Hellman, may not get to finally say "BRAK= E" > Dino: May not be able to go get a certificate. > > <....?>: May not have time to > > Dirk Kircher: Question about use case... > > Alex: Some operators already provide connection between RSUs, and thus > can provide handovers > > =E2=80=A2 Discussion - 10 min > > Aaron Falk: Good to have the discussion. Useful confusion [??} > Dirk Kircher: Use cases need discussion, as well as network drivers. > Carlos: Are you talking about requirements? > Dirk: Network requirements... > Erik Nordmark: Don't really grasp exactly why IP is needed for single hop= . > Will this use the same Internet? What about the timing requirements? > Stan Ratliff: V2V could be mobile ad hoc network? > Russ: Not if it's just one hop. > <...> : Want to know what cars are closing in. Could want to send messag= e > just backwards. > Dino: What if you *don't* have IP? A lot of vehicles already have IP, so > it > is already there. IP could simplify the automobile and the > communications. We will want to write applications. Will need to ha= ve > compatible format. We will want open standards. > Spencer Dawkins: Was waiting for a transport question. Applications migh= t > be > close to each other? About updating the car. > Hannes: Applications might be running on many different computers and > media, > but still need to communicate. > Pat Thaler: Updating the car is a different sort of thing than V2I. We > will > have updates at the service station, so you're not moving. > Three concerns: security problem. Time constraints. > Spencer: Need to understand what the volume of data would be. > Dirk: Is it, or is it not, TCP? There are a couple of protocols in use > today. > Eric Burdick: Should assume that all protocols are broken. > The control mechanisms could collapse with the number of cars. > > =E2=80=93 What documents are needed to advance this work? > http://itu.int/go/ITScomms is complete list of ITU work items > > Dino: Why include trains but not planes? > Alex: O.K. > Erik Burdick: What about when get onto the ocean? > Dirk: Some of the use cases are very dissimilar. Need to pick one proble= m. > Aaron from Jabber: Can assume use of certificates. > Dino: Need to look at the requirements and see if there are solutions, > even though there are a lot of work items. > Erik Nordmark: Can we figure out what is needed for the immediate term? > Randall Gellens: What about coordination with other SDOs? For instance > regarding IPv6-over-foo. > Alex: With a working group we can have a channel by which to do the > coordination > Randall: We have that with ISO, 3GPP, etc. > > Closing remarks: > We will publish the charter on the working group. In about a month we > will see if we have a rigorous charter. > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --=20 Michelle Wetterwald michelle.wetterwald@gmail.com --001a11c36bdca236f7052fda8fdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alex, all,

Thank you for = these minutes

I would like to reph= rase here the two=20 comments that=C2=A0I made=C2=A0 during the meeting to the V2I problem state= ment draft and could not be=20 captured in the minutes:
- in=C2=A0the V2I=C2=A0case, the performa= nce of the system and the coverage time vs. vehicle speed should be taken into=20 account. At the contrary of the V2V C-ACC case you described where both=20 cars are moving in the same direction, which ensures some time to=20 exchange prefixes, names, etc., in the V2I case, the coverage time with one= RSU may=20 be short.=C2=A0Thus this signalling should have a really low latency.
- Secondly, the potential congestion of the system when hundreds of cars woul= d be located in the same area and establishing or using V2I communications should also=20 be taken into account as an issue. Switching part of the traffic to a more = available=20 channel, as was proposed, may not always be possible. Reducing the size=20 of the packet, however, by using header=C2=A0compression technique as in 6l= o, may=20 offer a potential improvement.

Best regards,
Michelle Wetterwald
----
Senior expert in networking and teleco= mmunications

2016-04-06 19:46 GMT-03:00 Alexandre Petrescu &= lt;alexan= dre.petrescu@gmail.com>:
=20 =20 =20
Raw meeting minutes, thanks to minute takers for efforts despite echo-ey PA system.

Alex

------------------------------------------------------------------
Minutes for [its]

=E2=80=A2 Introduction:


=E2=80=93 Administrative - BOF Chairs - 5 min


=E2=80=93 ITS Goals and Success Criteria - BOF Chairs - 10 min


=E2=80=A2 Problem Space:


=E2=80=93 Tutorial of IP in vehicular communications - Alex Petrescu = - 20 min
Randel Gelland: Since there are so many MAC & PHY, they use their own
=C2=A0=C2=A0=C2=A0 messaging -- so could use IP.=C2=A0 But vehicals a= re using different PHY
=C2=A0=C2=A0=C2=A0 & MAC, so they can't communicate
Alex: But some of the radios are actually compatible

Bob Hinden: On "Topology" slide -- this is very simplified.= =C2=A0 There will be
=C2=A0=C2=A0=C2=A0 many cars, with very dynamic interconnection
Alex: Yes.=C2=A0 Gives more examples to support contention

Dapeng Liu: Once connectivity is established,
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 IP will enab= le better communication.

Pat Thaler: Even for compatible PHY, MACs may be different, so can't just day
=C2=A0=C2=A0=C2=A0 "use IP"

Erik Nordmark: Have people considered what the IP addressing will look like?
=C2=A0=C2=A0=C2=A0 In the car, the addressing is stable, but not outs= ide the car.=C2=A0 How
=C2=A0=C2=A0=C2=A0 does one car know the address in the other car? Alex: Yes, people are working on this.=C2=A0 IETF can help.

Carlos: Are people working on the addressing sheme.

Dino: We have an IP mobility problem

Dirk Kircher: Broadcast.=C2=A0 Semantic layer.
Alex: There may be multiple hops beween cars, and multiple hops in a car.
=C2=A0=C2=A0=C2=A0 May need IPv4 broadcast, or IPv6 broadcast

Dino: Even without the mobility problem, we still would have physical layer
=C2=A0=C2=A0=C2=A0 incompatible problems.=C2=A0 But that is exactly w= hat IP solves.

=E2=80=93 ITS use-cases C-ACC and Platooning - Alex Petrescu - 10 min=
draft-petrescu-its-cacc-sdo-04

<while presenting Platooning scalability slide>
Lou Berger: Hackable.=C2=A0 What's the security model?
Alex: Do not have slides about this.
Eric Rescolo: Why make any representation about exceeding speedlimit.
Alex: It's just an example
Eric Rescolo: What if the police ask this question?
<comment from floor - add speed parameter>

Sandra: there is a lot of work being done on security
=C2=A0=C2=A0=C2=A0 =3D Safety part

Eric Burdick: There are a lot of privacy issues.=C2=A0 There is work about jamming.
=C2=A0=C2=A0=C2=A0 It's not just Mobile IP.

Erik Nordmark: There was an IETF plenary that is relevant to security.
=C2=A0=C2=A0=C2=A0 =3D Police can probaly go get the data

Eric Rescolo: Lots of work to be done -- prevent querying in the car.


=E2=80=93 ITS V2V problem statement - Dapeng Liu - 5 min
draft-petrescu-its-problem-00

Randel Gelland: How do they know when they need to discover the other vehicles'
=C2=A0=C2=A0=C2=A0 address?
Dirk Kircher: Sub-Problem(1) needs to be characterized correctly.=C2= =A0 What is a
=C2=A0=C2=A0=C2=A0 realistic use case:=C2=A0 Answer: C-ACC

...: do you have data?
Alex: How much data do you want?

Randel Gellens: This shows how IP is useful, but it's not why IP is needed?
=C2=A0=C2=A0=C2=A0 So it is needed to exhibit the need, not just the = use case.

Erik Nordmark: how identities (or even temporary identities) established?

Hannes Tshofenig: Is there a need for another layer for identity?


=E2=80=93 ITS V2I problem statement - Jaehoon Paul Jeong - 5 min
draft-jeong-its-v2i-problem-statement-00

Charlie: What does it mean to "directly" connect to the RSO= 's network
Jaehoon: Exchange prefixes

Woman <did not understand, sorry>

Dino: a lost packet could be a catastrophe, amidst a lot of connection.
=C2=A0=C2=A0=C2=A0 Need to avoid chit-chat.=C2=A0 Should avoid multip= le solutions.
=C2=A0=C2=A0=C2=A0 If security requires Diffie-Hellman, may not get t= o finally say "BRAKE"
Dino: May not be able to go get a certificate.

<....?>: May not have time to

Dirk Kircher: Question about use case...

Alex: Some operators already provide connection between RSUs, and thus
=C2=A0=C2=A0=C2=A0 can provide handovers

=E2=80=A2 Discussion - 10 min

Aaron Falk: Good to have the discussion.=C2=A0 Useful confusion [??}<= br> Dirk Kircher: Use cases need discussion, as well as network drivers.
Carlos: Are you talking about requirements?
Dirk: Network requirements...
Erik Nordmark: Don't really grasp exactly why IP is needed for single hop.
=C2=A0=C2=A0=C2=A0 Will this use the same Internet?=C2=A0 What about = the timing requirements?
Stan Ratliff: V2V could be mobile ad hoc network?
Russ: Not if it's just one hop.
<...> : Want to know what cars are closing in.=C2=A0 Could want to send message
=C2=A0=C2=A0=C2=A0 just backwards.
Dino: What if you *don't* have IP?=C2=A0 A lot of vehicles alread= y have IP, so it
=C2=A0=C2=A0=C2=A0 is already there.=C2=A0 IP could simplify the auto= mobile and the
=C2=A0=C2=A0=C2=A0 communications.=C2=A0 We will want to write applic= ations.=C2=A0 Will need to have
=C2=A0=C2=A0=C2=A0 compatible format.=C2=A0 We will want open standar= ds.
Spencer Dawkins: Was waiting for a transport question.=C2=A0 Applications might be
=C2=A0=C2=A0=C2=A0 close to each other?=C2=A0 About updating the car.=
Hannes: Applications might be running on many different computers and media,
=C2=A0=C2=A0=C2=A0 but still need to communicate.
Pat Thaler: Updating the car is a different sort of thing than V2I.=C2=A0 We will
=C2=A0=C2=A0=C2=A0 have updates at the service station, so you're= not moving.
=C2=A0=C2=A0=C2=A0 Three concerns: security problem. Time constraints= .
Spencer: Need to understand what the volume of data would be.
Dirk: Is it, or is it not, TCP?=C2=A0 There are a couple of protocols in use today.
Eric Burdick: Should assume that all protocols are broken.
=C2=A0=C2=A0=C2=A0 The control mechanisms could collapse with the num= ber of cars.

=E2=80=93 What documents are needed to advance this work?
http://itu.i= nt/go/ITScomms is complete list of ITU work items

Dino: Why include trains but not planes?
Alex: O.K.
Erik Burdick: What about when get onto the ocean?
Dirk: Some of the use cases are very dissimilar.=C2=A0 Need to pick o= ne problem.
Aaron from Jabber: Can assume use of certificates.
Dino: Need to look at the requirements and see if there are solutions,
=C2=A0=C2=A0=C2=A0 even though there are a lot of work items.
Erik Nordmark: Can we figure out what is needed for the immediate term?
Randall Gellens: What about coordination with other SDOs?=C2=A0 For instance
=C2=A0=C2=A0=C2=A0 regarding IPv6-over-foo.
Alex: With a working group we can have a channel by which to do the coordination
Randall: We have that with ISO, 3GPP, etc.

Closing remarks:
We will publish the charter on the working group.=C2=A0 In about a month we
will see if we have a rigorous charter.

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its




--
--001a11c36bdca236f7052fda8fdd-- From nobody Wed Apr 6 19:05:57 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9854012D181 for ; Wed, 6 Apr 2016 19:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFqJv5WSRzGp for ; Wed, 6 Apr 2016 19:05:54 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B223B12D0FC for ; Wed, 6 Apr 2016 19:05:54 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id k135so21587247qke.0 for ; Wed, 06 Apr 2016 19:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fo63TA/HCZ6kF+nch3ThV5qPLjWJAyM12GfFx666xAM=; b=JVjC2zRAgJSCbXSCXut4+ypAKchzfZJCe8hIxkpr962dIT6ZjYr7w30miwDKbM0VEH IeXy7/0rAsukZLiSawEjuTz8IpBu3BAPZpt4urECRJjMXQOEpx7abwYlb26G4MCOmBTK Ef0wNKHvPBSFTkL05Co0wg+FCRVEZk9z8jTBkZk+jdsTMKU61gC8GjExOCaCDNjkXf2c E1MUYvlF91adH4bapwxH5zK2V6I67Sfhbf+PmrbXkqgNx3Ly8AZT97MyIXsy68ryNny6 DsGFE/oTd+bmr6GsngEtbtRSI95pO3mwelOKJ7PrMfPQP2PTz95xdEEeZJRvlKObsgK4 onrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fo63TA/HCZ6kF+nch3ThV5qPLjWJAyM12GfFx666xAM=; b=Mm3Ob/GLvOf39d/AViTsjmKHnhQuQ35ZYSOLdd+nDXkBiwL2IswbcSaDxWoMOUhp78 Y2E332vj9K2TQf/A8RE36j+gZYpXypu9W/uLZlqsm8bQXhYZlV88hGtfRxJa7YPunsZI CZK5f2qKJRXML8UV3bayXx+wsjvgfszvUvyPNgwSBnayGNNTup7nQvQtjJIT7PCuseuO XLgIO1lZML5+5e0Eonumt4nwLOpHVghcAceBLdOej0OqjqgVoAeDMbeoTg3AyfNdGmCZ 9T01xf5dzYA+HZv6KQ7X/Mt5kIsEXm25EO7GHxtRjgR7KEIJBJ1S+f7mmQZlI1dHuirH Y26A== X-Gm-Message-State: AD7BkJIueSYilB1s13qnZzlRjFBI/M8BcB+1qAF0an2iZFebw+6Dl7zH2YwYe9cXVb4/RQ== X-Received: by 10.55.79.207 with SMTP id d198mr514673qkb.49.1459994753824; Wed, 06 Apr 2016 19:05:53 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:2c12:8a95:4346:e1e7? ([2001:67c:370:136:2c12:8a95:4346:e1e7]) by smtp.gmail.com with ESMTPSA id j68sm2489909qge.41.2016.04.06.19.05.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 19:05:53 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: <57059F53.5030106@gmail.com> Date: Wed, 6 Apr 2016 19:05:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <56FF3138-1F13-4B5C-BBCF-D41FE66BE3B0@gmail.com> References: <57058375.6050101@gmail.com> <6B2D2039-34AD-41BA-9B9D-61164C9043CB@gmail.com> <570597A5.9050902@gmail.com> <57059F53.5030106@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 02:05:56 -0000 > Any new solution designed in this group must not alter what you know = to do v2i with LISP. For example, if there is prefix exchange between = vehicle and an RSU that must not break LISP from doing v2i (vehicle to = Internet) through that same RSU. There is a similar problem in Mobile = IP. LISP doens=92t have a prefix exchange. The vehicle would be assigned a = static IPv6 EID address. There won=92t be any broad changes to the LISP = protocol to support this because we support such use-cases already.=20 That is, an EID can move around when another device is the RLOC. So the = RSU is the RLOC and encap/decaps packets to and from the EID (the car) = that roams. The EIDs that come in range of the RSU are registered = dynamically to the mapping system. We do this for LISP-MN when LISP runs in a smartphone. And we do this = when VM roams from one type-of-rack switch to another in the data = center. In the former case, the EID and RLOC in are in the same node. In = the latter case, the EID and RLOC are in separate nodes. So we (the LISP WG) can present the solution and the ITS group can = decide what the gaps are. > If so, then this should be described so in the gap analysis or in a = requirements draft. Which one would you prefer? >=20 > (RSU: Road Side Unit: a set of computers linked by Ethernet and = situated in a box along the road, to control traffic lights and other = embedded sensors, and also do 802.11p to the vehicle; an RSU is = connected to the Internet by either ADSL or its own cellular link). And as I mentioned in the BOF. We solved this with planes. Where the = EIDs were end-systems on the plane that had session continuity = requirements. When the planes flew over routers on the ground, the = routers were the RLOCs for the EIDs on the plane. Very much like cars = driving by RSUs. If you think it would be useful, we could even demonstrate this for the = ITS group. Dino From nobody Thu Apr 7 06:58:24 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA0912D72E for ; Thu, 7 Apr 2016 06:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vspqflI0kSFJ for ; Thu, 7 Apr 2016 06:58:21 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D16312D6FA for ; Thu, 7 Apr 2016 06:58:20 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id c6so63505633qga.1 for ; Thu, 07 Apr 2016 06:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d2VgYk1Xn8qZpoNqicu8D2qI73cL0fPGqA3FJoA7JFs=; b=T2D22ZBC3L59r4lZxcjaW1PSpQ9hyyfqPa45gUhMgu2bzZjETohDWL9iygxUqWKDuQ NboJL7Da5i/2EkVQXJnKzp+nlFXzuNnODTGDaMTjA41WYtvH5aYGzVQLI/lEQAa/fMqP mq8O7caoyuWTVLCiZCKyXwQVEyqolnki38ppQD7DgtLy2uVo+76zqHIiswam2K9fHNmi 50tL7FkJCQJZS4cfx42Ks8xW13QGEBYCuoXaUUipg0sm/e0laP5t7yifc4jnvjTuIntK hN0KuXf4vuzXsksO9+vUxYrfUCrI4UQC2cNbCA6lfnV1aeAMiKhDJ2+OCLopmexfp6kJ 0+Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d2VgYk1Xn8qZpoNqicu8D2qI73cL0fPGqA3FJoA7JFs=; b=O0iiDop9eN6gZPn7hMP+oEPlH7mRFIMb0ryfM67ANddCHaT+nS4UlG0timyevh0LNs aXkONPOOinRPckBOIfFG5taayqLYdWQMTQRlvySGBs+7ao/TWp4ej7BTuyjXAJm8G1Np VhjxFR/obvp5+iyqnuARkQyZ2WIGXRwbP6fdANvFX2MTrC0ZqiRIjw1pzrWojIqSIWZf YRQ6dsKlvCOescDZk1o7bsWl6+wt5bbm7GZBHX84+xGVaBQcnrd94OVgqQqjOxg+AIQp NG+ESU+l+kFRaqz3QsKmZVr9EArRJU1OGa9y4GKQJ/m3c8iFh5hRUZGxLjVU5KPEW25R /6ug== X-Gm-Message-State: AD7BkJLoMlYrjCHaOFs8FuwkuVkhh+hNlmLl+81PXS5kf7vvi0I6a97Mo/NrRGjkhW7zOw== X-Received: by 10.140.239.66 with SMTP id k63mr4094720qhc.11.1460037499589; Thu, 07 Apr 2016 06:58:19 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:6ca8:4dd2:248f:8dc8? ([2001:67c:370:176:6ca8:4dd2:248f:8dc8]) by smtp.gmail.com with ESMTPSA id z62sm3456864qka.26.2016.04.07.06.58.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 06:58:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: Date: Thu, 7 Apr 2016 06:58:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57058375.6050101@gmail.com> <6B2D2039-34AD-41BA-9B9D-61164C9043CB@gmail.com> <570597A5.9050902@gmail.com> To: dickroy@alum.mit.edu X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Alexandre Petrescu , its@ietf.org Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 13:58:23 -0000 > I get the feeling that people are thinking ITS needs from the IETF a = global > IP solution to ALL it services and applications. Let me assure you = nothing Richard, I think it how much control each individual auto-maker will = want. If security and control of the multitude of computer systems is = important and if they feel a proprietary way is the only way to achieve = it, then the market will decide that. I think the big question and what remains to be seen is if the = auto-makers will want to interoperate with each other and at what layer = of a communication stack. But as I mentiond at the mic, if a car wants to talk to the Internet, = they have to use IP based protocols. There should be no argument there. = As for mobility, if RF cells are enmourous, then IP addresses in the = cars don=E2=80=99t need to change. We find this with our smartphones = today. If RF cells are small or supported by different service providers = with different addressing, then we need IP mobility. This is why provider-assigned (PA) addresses have so many disadvantages = when you want to address something independent on how they are = connected. You know, those cars are going to be connected via their = smartphone hotspots too. So we can be assured that multi-home to the car = across service providers is going to happen. And the next question is, is there a session continuity requirement = across these connections. > could be further from the truth. The discussions today's on use cases = were > interesting, however when it focused on V2V safety apps, they were = somewhat > off track. We, the ITS community, are not looking for IPv6 solutions = to all Yes, I believe I agree. > our issues and challenges, just those for which IP is well-suited. = ITS > communications is in the 21rst century (the ITS station!) and = flexibility is > the key! IP will be used when appropriate, and not, when not. Right, if IP is going to make the solution more complex, or is simply = not needed, or gets in the way, it should NOT be used. Dino >=20 > Cheers, >=20 > RR >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Wednesday, April 06, 2016 4:22 PM >> To: Alexandre Petrescu >> Cc: its@ietf.org >> Subject: Re: [its] charter ITS >>=20 >>> 'Yes' means that you would prefer one I-D which is dedicated to gap >> analysis? (and that includes considerations of IP (EID)? >>=20 >> We know how to do the v2i piece with LISP. Yes, with one static EID = per >> vehicle. We have some production deployments that use the same = solution in >> the data center and other sectors. >>=20 >>> This gap analysis draft would not describe C-ACC/Platooning = use-case. It >> would just do gap analysis. >>=20 >> For the v2v case, LISP isn't appropriate because it would need to = depend >> on infrastructure and that signalling would kill the responsive the = v2v >> needs for motion critical actions. >>=20 >> Dino >>=20 >=20 >=20 From nobody Thu Apr 7 18:03:21 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5622412D16C for ; Thu, 7 Apr 2016 18:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2Ljkw5VsoT9 for ; Thu, 7 Apr 2016 18:03:18 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB1012D0B7 for ; Thu, 7 Apr 2016 18:03:17 -0700 (PDT) Received: from yanzhiwei (unknown [218.241.111.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMU1VAwdXx6VTCQ--.50715S2; Fri, 08 Apr 2016 09:03:17 +0800 (CST) Date: Fri, 8 Apr 2016 09:03:14 +0800 From: "Z.W. Yan" To: "its" Message-ID: <201604080903146552249@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon077302732180_=====" X-CM-TRANSID: AQAAf0ApMU1VAwdXx6VTCQ--.50715S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUU5p7k0a2IF6F4UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26r4j 6ryUM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAFwI0_Gr 1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvE ncxIr21lYx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4 IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_KwCF04k20xvY0x0EwIxG rwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4 vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij6r126r13MIIF0xvE2Ix0 cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8V AvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7Cj xVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU81v3UUUUUU== X-CM-SenderInfo: x1dqqupqqluhdfq/ Archived-At: Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 01:03:20 -0000 This is a multi-part message in MIME format. --=====003_Dragon077302732180_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, All, About the charter, I think we should also consider and describe the NEMO and nested-NEMO scenarios and protocols. Otherwise, it just falls back to the application of plain MIP/PMIP no matter in the V2V case or V2I case. BR, Zhiwei Yan 2016-04-08 Z.W. Yan --=====003_Dragon077302732180_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Hi, All,
About the charter, I think we should also consider and describe the NEMO and nested-NEMO scenarios and protocols.
Otherwise, it just falls back to the application of plain MIP/PMIP no matter in the V2V case or V2I case. 
BR,
Zhiwei Yan
 
2016-04-08
Z.W. Yan
--=====003_Dragon077302732180_=====-- From nobody Thu Apr 7 21:14:23 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11DB12D576 for ; Thu, 7 Apr 2016 21:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbMQGoWLxRgX for ; Thu, 7 Apr 2016 21:14:19 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B32312D1D2 for ; Thu, 7 Apr 2016 21:14:19 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id t10so121904803ywa.0 for ; Thu, 07 Apr 2016 21:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M6QTSzdNIE9V4Pki+OYlDUk54Tooi/BUljeLeWSxdFE=; b=BSRt6TYcni98oEOEWdwOxm+l/Ntl59rz6R3AOnt+1EE9Mp0SgnroFkdEiZtR/C9dsQ HHhosKFSzavFDk61eBOX6zRGFqpiL+b3pVHEv43GYReZ5LedjOpclFABC1I/qeOFg3CE PKtXfbkC05Ll4o3EmzzCYx5VqPDBF0jvhXGuYXriJ7m4W9MSYaZenYm13v3IPk5AEzPy K6t1EdcmR0rpwJqDiOg6rCLqj1+tktTG7giOWB4/6c5VVa1pKClmhZNaduv8I5XSJkvT zoYD2w76aVH/w5JM/7/jEkJfR/mJ98xR+UKQ/j1d+36YkRUoUc+KgyOhxTAzG/ePaMWl CeqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M6QTSzdNIE9V4Pki+OYlDUk54Tooi/BUljeLeWSxdFE=; b=BM++k+tf9jhQol69ZuZdGuK2Yc+1A+p6DS2DvZ5KMIYEUK1I62wS0E0U/TKY5sGv1z R2JFVMBWLDkZdc+b1nQtAYrvluEaPTKER9H8VPdOk4iV3ZKcIxmJhwlgkHAqTZAdEZWV vkwJV2ACVJLotARBcJTjrCZKx8ZbI6Lsq6tRg5REOwVrzi8/hUu2FTYi60cZL8ShufRt 0qVnJAkudolWWFwpR5uN5x8oWyNjiTQpOVjs07Bm+zpUCqK18mw3xtXx+3NJBbnW2IFF uOqAJ4KHego6R3BcDHoVFrtdXbsGS8CDSlz8MIj4Dtx5vokfu6j+30fhTW6cscjqvqtt vLQw== X-Gm-Message-State: AD7BkJJghar/Q/EIEiBh/Ifleb9zReqIr47bfbBP4u8fpUl8LitxrH1A+NuTUVXAz232p4tT2ySxpTmpKcQBkA== X-Received: by 10.37.20.195 with SMTP id 186mr3905008ybu.60.1460088858398; Thu, 07 Apr 2016 21:14:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.4.22 with HTTP; Thu, 7 Apr 2016 21:13:49 -0700 (PDT) In-Reply-To: <57058375.6050101@gmail.com> References: <57058375.6050101@gmail.com> From: "Mr. Jaehoon Paul Jeong" Date: Fri, 8 Apr 2016 01:13:49 -0300 Message-ID: To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a113e7988bed96c052ff16d81 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 04:14:22 -0000 --001a113e7988bed96c052ff16d81 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi ITSers, For a proposed charter item of "List of Research Papers in the V2V domain, identifying which uses IP", I agree that this item should be included into our ITS charter. Nabil Benamar, Sandra C=C3=A9spedes, and I agreed on the drafting for this = item into an I-D. Thanks. -- Paul =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php On Wed, Apr 6, 2016 at 6:45 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > ITSers, > > Please see below the current charter. > > - the two Problem Statements drafts V2V and V2I joined, so there is less > text in charter. > - added an Item on "List of Research papers..." > > Erik: did I understand you correctly that there should be some item on > discussing whether link-local addressing is sufficient, whether prefix > exchange is necessary? > > Dino: should LISP be included in the gap analysis draft which includes > C-ACC use-case? OR should we separate a dedicated I-D only with gap > analysis including ND, MIP, AODVv2, LISP? > > Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle > interface illustrated good enough by the words "moving network to nearby > moving network communications"? Or is it better to say "the 1-IP-hop > between nearby moving networks must be self-configured"? > > Nabil, Sandra: is it ok to have a working group item "List of Research > Papers for IP in V2V and V2I communications"? > > Other comments? > > Alex > > ------------------------------------------------------------------ > > ITS (name to change) > Charter > April 6th, 2016 > http://ietf.org/mailman/listinfo/its > > > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming > > Chairs: > TBD > > Assigned Area Director: > TBD > > Mailing list > Address: its@ietf.org > 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: > > Goal > ---- > The goal of this group is to standardize IP-based protocols for > establishing direct and secure connectivity between moving networks, > some of which could be fixed permanently or temporarily. > > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving network to > nearby moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > train, or train-to-intersection signalling. > > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to > the Internet, either as vehicle-to-vehicle, vehicle-to-infra or > vehicle-to-Internet. Entertainment apps enhancing comfort, reliable > data exchanges for road safety, and automated driving are features > coming in automobiles to hit the roads from now to year 2020. > Highlighting increased safety as an immediate result of > hyper-connectivity applied to vehicles, public authorities worldwide > are increasingly mandating secure communication technology > requirements in vehicles. > > Emergency apps for new instrumented ambulances carry many benefits > both to the users and to society in general. > > Why IP? > ------- > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. > However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure > communications are still being developed. To improve on a situation > of link-specific data exchanges, and enable independent application > sets to share the same links, IP data exchanges are needed. Enabling > IP communication between vehicles (V2V), and between vehicles and the > immediate infrastructure (V2I), will provide (0) ability to reach the > rest of the world on the Internet (1) short and deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) ease of > reuse of existing Internet applications in a vehicular environment. > > Moving network to nearby moving network communications involve link > layers such as: 802.11p OCB (Outside the Context of a Basic Service > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light > Communications), IrDA, LTE-D. Only the IP protocols are capable of > running on each of these links and establish IP paths across them in > an interoperable manner. > > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate from one > moving network to another nearby moving network. > > In the automobile space, the Cooperative Adaptive Cruise Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the cross-roads, > the moving network inside a vehicle exchanges data with the moving > network in the red-light pole. > > Several public safety scenarios involve moving networks. Distinct > organizations deploy different moving networks (in-vehicle, on-person) > at an incident scene. These networks need to interoperate in order to > more effectively understand and deal with the incident scene. > > In connected rail scenarios the moving network deployed in trains > communicate with other moving networks at the cross-points. > > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol > enhancements. The 1-hop link-scoped protocols include the protocols > for route establishment involving ICMP Router Advertisements. The > n-hop path management protocols include n-hop path establishment > protocols (e.g. Babel, OSPF) and n-hop path search protocols (most > notably AODV and derivates). > > In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations. > > In some of the moving network applications the window of opportunity > for exchanging data with the immediate infrastructure may be very > short. For example, a car driving near a road-side unit may have only > 5s to exchange with that RSU (depending on speed, RSU range and > number). (ephemeral connections). > > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to nearby moving > network communications are focusing on low delays of the data paths, > reduced number of messages for path establishment, application > friendly, resilience to attacks, compatibility with DHCP and Mobile > IP. > > In addition, some moving network to nearby moving network applications > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the > 1-hop IP moving network to nearby moving netowrk mechanisms will need > to gracefully support IP multicast. > > Due to the inherent characteristics of safety-related communications, > all new moving network to nearby moving network mechanisms must afford > authenticity and confidentiality where necessary. Dynamically > establishing ephemeral communication paths between automobiles in > public areas must offer privacy safeguards for the end users > (passengers). > > Establishing 1-hop IP V2V paths must not break the existing on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. > > In a moving network deployed in an automobile, typically one exit > point connects the moving network to other moving networks. However, > in a more general manner (and to support reliability) any new > mechanism of moving network to nearby moving network communications > should support multi-homing: one router to use multiple interfaces > towards outside the moving network, or multiple routers. > > Current version of Internet protocols > ------------------------------------- > The group will only work on IPv6 solutions. > > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to nearby moving > network communications, often involving IPv6, and novel V2V and > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For > Vehicle-to-Internet communications, 3GPP LTE and other cellular > technologies represent the long-range connectivity method; for > Vehicle-to-Vehicle communications, LTE Direct is currently specified, > as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need > for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive > Cruise Control and Platooning. The IEEE developed a popular link for > short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a > set of requirements for V2V communications. > > Work Items > ---------- > - use-cases for moving network to nearby moving network communications > - Problem Statement for moving network to nearby moving network > communications > including V2V, V2I and DNS. > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Solutions, which might include new protocols or extensions to > existing protocols. With MIB. > - IPv6-over foo, where foo is pertinent for moving network to nearby > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) > - List of Research Papers in the V2V domain, identifying which uses IP. > > Timeline > -------- > - > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --001a113e7988bed96c052ff16d81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi ITSers,
For a proposed charter item of "List o= f Research Papers in the V2V domain, identifying which uses IP",=C2=A0=
I agree that this item should be included into our ITS charter.<= /div>

Nabil Benamar, Sandra C=C3=A9spedes, and I agreed = on the drafting for this item into an I-D.

Thanks.=

--
Paul
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr= . Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Softw= are
Sungkyunkwan University
Office: +82-31-299-4957
Email:=C2=A0jaehoon.paul@gmai= l.com,=C2=A0pauljeong@skku.edu
Personal Homepage:=C2=A0<= a href=3D"http://cpslab.skku.edu/people-jaehoon-jeong.php" target=3D"_blank= ">http://iotlab.skku.edu/people-jaehoon-jeong.php

On Wed, A= pr 6, 2016 at 6:45 PM, Alexandre Petrescu <alexandre.petrescu@g= mail.com> wrote:
=20 =20 =20
ITSers,

Please see below the current charter.

- the two Problem Statements drafts V2V and V2I joined, so there is less text in charter.
- added an Item on "List of Research papers..."

Erik: did I understand you correctly that there should be some item on discussing whether link-local addressing is sufficient, whether prefix exchange is necessary?

Dino: should LISP be included in the gap analysis draft which includes C-ACC use-case?=C2=A0 OR should we separate a dedicated I-D only with gap analysis including ND, MIP, AODVv2, LISP?

Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle interface illustrated good enough by the words "moving network to nearby moving network communications"?= =C2=A0 Or is it better to say "the 1-IP-hop between nearby moving networks mu= st be self-configured"?

Nabil, Sandra: is it ok to have a working group item "List of Research Papers for IP in V2V and V2I communications"?

Other comments?

Alex

------------------------------------------------------------------
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ITS (name to change)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Charter
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 April 6th, 2016
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://ietf.org/mailman/list= info/its


Intelligent Transportation Systems (its)
----------------------------------------
Current Status: WG forming

Chairs:
=C2=A0=C2=A0 TBD

Assigned Area Director:
=C2=A0=C2=A0 TBD

Mailing list
=C2=A0=C2=A0 Address: its@ietf.org
=C2=A0=C2=A0 To Subscribe: https://www.ietf.org/mailman/listinfo/its=
=C2=A0=C2=A0 Archive:
=C2=A0=C2=A0 http://www.ietf.org/mail-archive/web/i= ts/current/maillist.html

Additional web page
=C2=A0=C2=A0 TBD

Charter:

Goal
----
The goal of this group is to standardize IP-based protocols for
establishing direct and secure connectivity between moving networks,
some of which could be fixed permanently or temporarily.

Moving Network to Nearby Moving Network Communications
------------------------------------------------------
The group is concerned with all situations involving moving network to
nearby moving network communications.=C2=A0 For example: vehicle-to-vehicle
communications, nomadic user wearing a PAN and communicating to a
homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a
train, or train-to-intersection signalling.

Example from the automobile communications space
------------------------------------------------
Automobiles and vehicles of all types are increasingly connected to
the Internet, either as vehicle-to-vehicle, vehicle-to-infra or
vehicle-to-Internet.=C2=A0 Entertainment apps enhancing comfort, reliable
data exchanges for road safety, and automated driving are features coming in automobiles to hit the roads from now to year 2020.
Highlighting increased safety as an immediate result of
hyper-connectivity applied to vehicles, public authorities worldwide
are increasingly mandating secure communication technology
requirements in vehicles.

Emergency apps for new instrumented ambulances carry many benefits both to the users and to society in general.

Why IP?
-------
Today, there are several deployed Vehicle-to-Internet technologies,
including car tethering through driver's cellular smartphone.
However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communications are still being developed.=C2=A0 To improve on a situation
of link-specific data exchanges, and enable independent application
sets to share the same links, IP data exchanges are needed.=C2=A0 Enabling
IP communication between vehicles (V2V), and between vehicles and the
immediate infrastructure (V2I), will provide (0) ability to reach the
rest of the world on the Internet (1) short and deterministic delays,
(2) fast forwarding through scalable paths of routers, (3) ease of reuse of existing Internet applications in a vehicular environment.

Moving network to nearby moving network communications involve link
layers such as: 802.11p OCB (Outside the Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light
Communications), IrDA, LTE-D.=C2=A0 Only the IP protocols are capable of
running on each of these links and establish IP paths across them in
an interoperable manner.

Scenarios?
----------
There are a few scenarios exhibiting the need to communicate from one
moving network to another nearby moving network.

In the automobile space, the Cooperative Adaptive Cruise Control and
Platooning features consider that vehicles close to each other
exchange data describing their kinematic status.=C2=A0 At the cross-roads,
the moving network inside a vehicle exchanges data with the moving network in the red-light pole.

Several public safety scenarios involve moving networks.=C2=A0 Distin= ct
organizations deploy different moving networks (in-vehicle, on-person)
at an incident scene.=C2=A0 These networks need to interoperate in order to
more effectively understand and deal with the incident scene.

In connected rail scenarios the moving network deployed in trains
communicate with other moving networks at the cross-points.

What kind of solutions?
-----------------------
The current technical solutions considered to achieve moving network
to nearby moving network communications are of two kinds: IP routing
protocols for n-hop path management and 1-hop link-scoped IP protocol
enhancements.=C2=A0 The 1-hop link-scoped protocols include the protocols
for route establishment involving ICMP Router Advertisements.=C2=A0 T= he
n-hop path management protocols include n-hop path establishment
protocols (e.g. Babel, OSPF) and n-hop path search protocols (most notably AODV and derivates).

In this proposed Working Group the focus is on 1-hop protocols, and
leverage from other Working Groups for the n-hop situations.

In some of the moving network applications the window of opportunity
for exchanging data with the immediate infrastructure may be very
short.=C2=A0 For example, a car driving near a road-side unit may hav= e only
5s to exchange with that RSU (depending on speed, RSU range and
number). (ephemeral connections).

What kind of requirements?
--------------------------
The requirements for mechanisms for moving network to nearby moving
network communications are focusing on low delays of the data paths,
reduced number of messages for path establishment, application
friendly, resilience to attacks, compatibility with DHCP and Mobile
IP.

In addition, some moving network to nearby moving network applications
involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP moving network to nearby moving netowrk mechanisms will need
to gracefully support IP multicast.

Due to the inherent characteristics of safety-related communications,
all new moving network to nearby moving network mechanisms must afford
authenticity and confidentiality where necessary.=C2=A0 Dynamically establishing ephemeral communication paths between automobiles in
public areas must offer privacy safeguards for the end users
(passengers).

Establishing 1-hop IP V2V paths must not break the existing on-board
protocols and applications which communicate with the Internet,
possibly via multiple radios.

In a moving network deployed in an automobile, typically one exit
point connects the moving network to other moving networks.=C2=A0 However,
in a more general manner (and to support reliability) any new
mechanism of moving network to nearby moving network communications
should support multi-homing: one router to use multiple interfaces towards outside the moving network, or multiple routers.

Current version of Internet protocols
-------------------------------------
The group will only work on IPv6 solutions.

What SDOs may need this work?
-----------------------------
The requirements and standards for moving network to nearby moving network communications, often involving IPv6, and novel V2V and
V2Infra concepts, are developed mainly at ISO TC204 "Intelligent=
Transport Systems", 3GPP, ETSI, NHTSA and IEEE.=C2=A0 For
Vehicle-to-Internet communications, 3GPP LTE and other cellular
technologies represent the long-range connectivity method; for
Vehicle-to-Vehicle communications, LTE Direct is currently specified,
as well as OCB mode of IEEE 802.11.=C2=A0 Several use-cases exhibit a need
for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive
Cruise Control and Platooning.=C2=A0 The IEEE developed a popular lin= k for
short-range communications - IEEE 802.11p "WAVE".=C2=A0 The= NHTSA wrote a
set of requirements for V2V communications.

Work Items
----------
- use-cases for moving network to nearby moving network communications
- Problem Statement for moving network to nearby moving network communications
=C2=A0 including V2V, V2I and DNS.
- Security and Privacy Requirements for moving network to
=C2=A0 nearby moving network communications
- Solutions, which might include new protocols or extensions to
=C2=A0 existing protocols.=C2=A0 With MIB.
- IPv6-over foo, where foo is pertinent for moving network to nearby
=C2=A0 moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)
- List of Research Papers in the V2V domain, identifying which uses IP.

Timeline
--------
-

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its


--001a113e7988bed96c052ff16d81-- From nobody Fri Apr 8 02:22:45 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1138012D72A for ; Fri, 8 Apr 2016 02:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AU_f3eF3r-_8 for ; Fri, 8 Apr 2016 02:22:40 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 73F3D12D0C1 for ; Fri, 8 Apr 2016 02:22:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 73DE03EF5; Fri, 8 Apr 2016 11:22:37 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Jf1PzibRGmJu; Fri, 8 Apr 2016 11:22:37 +0200 (CEST) Received: from [192.168.1.33] (113.Red-88-17-65.dynamicIP.rima-tde.net [88.17.65.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: josesanta) by xenon24.um.es (Postfix) with ESMTPSA id EC5FF3EE7; Fri, 8 Apr 2016 11:22:22 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7FD5F5BE-6F96-4726-8A5B-C0DF96779863" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: =?utf-8?Q?Jos=C3=A9_Santa_Lozano?= In-Reply-To: Date: Fri, 8 Apr 2016 11:22:02 +0200 Message-Id: References: <57058375.6050101@gmail.com> To: "Mr. Jaehoon Paul Jeong" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Alexandre Petrescu , "its@ietf.org" Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 09:22:44 -0000 --Apple-Mail=_7FD5F5BE-6F96-4726-8A5B-C0DF96779863 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, =46rom my group we could also contribute, in general, with information = about papers in the area using IP(v6) in both V2V and V2I. Regards, --=20 Jos=C3=A9 Santa Lozano Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones Facultad de Inform=C3=A1tica Universidad de Murcia 30100 Murcia, Spain Telf: +34-868-888771 / +34-868-884455 Fax: +34-868-884151 Web: http://ants.inf.um.es/~josesanta > El 8 abr 2016, a las 6:13, Mr. Jaehoon Paul Jeong = escribi=C3=B3: >=20 > Hi ITSers, > For a proposed charter item of "List of Research Papers in the V2V = domain, identifying which uses IP",=20 > I agree that this item should be included into our ITS charter. >=20 > Nabil Benamar, Sandra C=C3=A9spedes, and I agreed on the drafting for = this item into an I-D. >=20 > Thanks. >=20 > -- > Paul > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com , = pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php = >=20 > On Wed, Apr 6, 2016 at 6:45 PM, Alexandre Petrescu = > = wrote: > ITSers, >=20 > Please see below the current charter. >=20 > - the two Problem Statements drafts V2V and V2I joined, so there is = less text in charter. > - added an Item on "List of Research papers..." >=20 > Erik: did I understand you correctly that there should be some item on = discussing whether link-local addressing is sufficient, whether prefix = exchange is necessary? >=20 > Dino: should LISP be included in the gap analysis draft which includes = C-ACC use-case? OR should we separate a dedicated I-D only with gap = analysis including ND, MIP, AODVv2, LISP? >=20 > Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle = interface illustrated good enough by the words "moving network to nearby = moving network communications"? Or is it better to say "the 1-IP-hop = between nearby moving networks must be self-configured"? >=20 > Nabil, Sandra: is it ok to have a working group item "List of Research = Papers for IP in V2V and V2I communications"? >=20 > Other comments? >=20 > Alex >=20 > ------------------------------------------------------------------ >=20 > ITS (name to change) > Charter > April 6th, 2016 > http://ietf.org/mailman/listinfo/its = >=20 >=20 > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming >=20 > Chairs: > TBD >=20 > Assigned Area Director: > TBD >=20 > Mailing list > Address: its@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/its = > Archive: > http://www.ietf.org/mail-archive/web/its/current/maillist.html = >=20 > Additional web page > TBD >=20 > Charter: >=20 > Goal > ---- > The goal of this group is to standardize IP-based protocols for > establishing direct and secure connectivity between moving networks, > some of which could be fixed permanently or temporarily. >=20 > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving network to > nearby moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > train, or train-to-intersection signalling. >=20 > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to > the Internet, either as vehicle-to-vehicle, vehicle-to-infra or > vehicle-to-Internet. Entertainment apps enhancing comfort, reliable > data exchanges for road safety, and automated driving are features > coming in automobiles to hit the roads from now to year 2020. > Highlighting increased safety as an immediate result of > hyper-connectivity applied to vehicles, public authorities worldwide > are increasingly mandating secure communication technology > requirements in vehicles. >=20 > Emergency apps for new instrumented ambulances carry many benefits > both to the users and to society in general. >=20 > Why IP? > ------- > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. > However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure > communications are still being developed. To improve on a situation > of link-specific data exchanges, and enable independent application > sets to share the same links, IP data exchanges are needed. Enabling > IP communication between vehicles (V2V), and between vehicles and the > immediate infrastructure (V2I), will provide (0) ability to reach the > rest of the world on the Internet (1) short and deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) ease of > reuse of existing Internet applications in a vehicular environment. >=20 > Moving network to nearby moving network communications involve link > layers such as: 802.11p OCB (Outside the Context of a Basic Service > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light > Communications), IrDA, LTE-D. Only the IP protocols are capable of > running on each of these links and establish IP paths across them in > an interoperable manner. >=20 > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate from one > moving network to another nearby moving network. >=20 > In the automobile space, the Cooperative Adaptive Cruise Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the cross-roads, > the moving network inside a vehicle exchanges data with the moving > network in the red-light pole. >=20 > Several public safety scenarios involve moving networks. Distinct > organizations deploy different moving networks (in-vehicle, on-person) > at an incident scene. These networks need to interoperate in order to > more effectively understand and deal with the incident scene. >=20 > In connected rail scenarios the moving network deployed in trains > communicate with other moving networks at the cross-points. >=20 > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol > enhancements. The 1-hop link-scoped protocols include the protocols > for route establishment involving ICMP Router Advertisements. The > n-hop path management protocols include n-hop path establishment > protocols (e.g. Babel, OSPF) and n-hop path search protocols (most > notably AODV and derivates). >=20 > In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations. >=20 > In some of the moving network applications the window of opportunity > for exchanging data with the immediate infrastructure may be very > short. For example, a car driving near a road-side unit may have only > 5s to exchange with that RSU (depending on speed, RSU range and > number). (ephemeral connections). >=20 > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to nearby moving > network communications are focusing on low delays of the data paths, > reduced number of messages for path establishment, application > friendly, resilience to attacks, compatibility with DHCP and Mobile > IP. >=20 > In addition, some moving network to nearby moving network applications > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the > 1-hop IP moving network to nearby moving netowrk mechanisms will need > to gracefully support IP multicast. >=20 > Due to the inherent characteristics of safety-related communications, > all new moving network to nearby moving network mechanisms must afford > authenticity and confidentiality where necessary. Dynamically > establishing ephemeral communication paths between automobiles in > public areas must offer privacy safeguards for the end users > (passengers). >=20 > Establishing 1-hop IP V2V paths must not break the existing on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. >=20 > In a moving network deployed in an automobile, typically one exit > point connects the moving network to other moving networks. However, > in a more general manner (and to support reliability) any new > mechanism of moving network to nearby moving network communications > should support multi-homing: one router to use multiple interfaces > towards outside the moving network, or multiple routers. >=20 > Current version of Internet protocols > ------------------------------------- > The group will only work on IPv6 solutions. >=20 > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to nearby moving > network communications, often involving IPv6, and novel V2V and > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For > Vehicle-to-Internet communications, 3GPP LTE and other cellular > technologies represent the long-range connectivity method; for > Vehicle-to-Vehicle communications, LTE Direct is currently specified, > as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need > for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive > Cruise Control and Platooning. The IEEE developed a popular link for > short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a > set of requirements for V2V communications. >=20 > Work Items > ---------- > - use-cases for moving network to nearby moving network communications > - Problem Statement for moving network to nearby moving network = communications > including V2V, V2I and DNS. > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Solutions, which might include new protocols or extensions to > existing protocols. With MIB. > - IPv6-over foo, where foo is pertinent for moving network to nearby > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, = 802.11ad) > - List of Research Papers in the V2V domain, identifying which uses = IP. >=20 > Timeline > -------- > - >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its = >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_7FD5F5BE-6F96-4726-8A5B-C0DF96779863 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear all,

=46rom my group we could also contribute, in general, with = information about papers in the area using IP(v6) in both V2V and = V2I.

Regards,

-- 
Jos=C3=A9= Santa Lozano
Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones
Facultad de Inform=C3=A1tica
Universidad de Murcia
30100 Murcia, Spain
Telf: +34-868-888771 = / +34-868-884455
Fax: +34-868-884151
Web: http://ants.inf.um.es/~josesanta



El 8 abr 2016, a las 6:13, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> escribi=C3=B3:

Hi ITSers,
For a proposed charter item of = "List of Research Papers in the V2V domain, identifying which uses = IP", 
I agree that this item should be = included into our ITS charter.

Nabil Benamar, Sandra C=C3=A9spedes, = and I agreed on the drafting for this item into an I-D.

Thanks.

--
Paul
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: = +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
=

On Wed, Apr 6, 2016 at 6:45 PM, Alexandre Petrescu = <alexandre.petrescu@gmail.com> wrote:
=20 =20 =20
ITSers,

Please see below the current charter.

- the two Problem Statements drafts V2V and V2I joined, so there is less text in charter.
- added an Item on "List of Research papers..."

Erik: did I understand you correctly that there should be some item on discussing whether link-local addressing is sufficient, whether prefix exchange is necessary?

Dino: should LISP be included in the gap analysis draft which includes C-ACC use-case?  OR should we separate a dedicated = I-D only with gap analysis including ND, MIP, AODVv2, LISP?

Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle interface illustrated good enough by the words "moving network to nearby moving network communications"?  Or = is it better to say "the 1-IP-hop between nearby moving networks must be self-configured"?

Nabil, Sandra: is it ok to have a working group item "List of Research Papers for IP in V2V and V2I communications"?

Other comments?

Alex

= ------------------------------------------------------------------

=              = ITS (name to change)
=             &n= bsp;      Charter
=              = April 6th, 2016
         http://ietf.org/mailman/listinfo/its


Intelligent Transportation Systems (its)
----------------------------------------
Current Status: WG forming

Chairs:
   TBD

Assigned Area Director:
   TBD

Mailing list
   Address: its@ietf.org
   To Subscribe: https://www.ietf.org/mailman/listinfo/its
   Archive:
   http://www.ietf.org/mail-archive/web/its/current/maillist.html<= /a>

Additional web page
   TBD

Charter:

Goal
----
The goal of this group is to standardize IP-based protocols for
establishing direct and secure connectivity between moving networks,
some of which could be fixed permanently or temporarily.

Moving Network to Nearby Moving Network Communications
------------------------------------------------------
The group is concerned with all situations involving moving network to
nearby moving network communications.  For example: vehicle-to-vehicle
communications, nomadic user wearing a PAN and communicating to = a
homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a
train, or train-to-intersection signalling.

Example from the automobile communications space
------------------------------------------------
Automobiles and vehicles of all types are increasingly connected to
the Internet, either as vehicle-to-vehicle, vehicle-to-infra or
vehicle-to-Internet.  Entertainment apps enhancing comfort, reliable
data exchanges for road safety, and automated driving are = features
coming in automobiles to hit the roads from now to year 2020.
Highlighting increased safety as an immediate result of
hyper-connectivity applied to vehicles, public authorities worldwide
are increasingly mandating secure communication technology
requirements in vehicles.

Emergency apps for new instrumented ambulances carry many = benefits
both to the users and to society in general.

Why IP?
-------
Today, there are several deployed Vehicle-to-Internet technologies,
including car tethering through driver's cellular smartphone.
However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communications are still being developed.  To improve on a situation
of link-specific data exchanges, and enable independent application
sets to share the same links, IP data exchanges are needed.  Enabling
IP communication between vehicles (V2V), and between vehicles and the
immediate infrastructure (V2I), will provide (0) ability to reach the
rest of the world on the Internet (1) short and deterministic delays,
(2) fast forwarding through scalable paths of routers, (3) ease = of
reuse of existing Internet applications in a vehicular environment.

Moving network to nearby moving network communications involve link
layers such as: 802.11p OCB (Outside the Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light
Communications), IrDA, LTE-D.  Only the IP protocols are = capable of
running on each of these links and establish IP paths across them in
an interoperable manner.

Scenarios?
----------
There are a few scenarios exhibiting the need to communicate from one
moving network to another nearby moving network.

In the automobile space, the Cooperative Adaptive Cruise Control and
Platooning features consider that vehicles close to each other
exchange data describing their kinematic status.  At the cross-roads,
the moving network inside a vehicle exchanges data with the = moving
network in the red-light pole.

Several public safety scenarios involve moving networks.  = Distinct
organizations deploy different moving networks (in-vehicle, on-person)
at an incident scene.  These networks need to interoperate in order to
more effectively understand and deal with the incident scene.

In connected rail scenarios the moving network deployed in = trains
communicate with other moving networks at the cross-points.

What kind of solutions?
-----------------------
The current technical solutions considered to achieve moving network
to nearby moving network communications are of two kinds: IP routing
protocols for n-hop path management and 1-hop link-scoped IP protocol
enhancements.  The 1-hop link-scoped protocols include the protocols
for route establishment involving ICMP Router = Advertisements.  The
n-hop path management protocols include n-hop path = establishment
protocols (e.g. Babel, OSPF) and n-hop path search protocols = (most
notably AODV and derivates).

In this proposed Working Group the focus is on 1-hop protocols, and
leverage from other Working Groups for the n-hop situations.

In some of the moving network applications the window of opportunity
for exchanging data with the immediate infrastructure may be = very
short.  For example, a car driving near a road-side unit may = have only
5s to exchange with that RSU (depending on speed, RSU range and
number). (ephemeral connections).

What kind of requirements?
--------------------------
The requirements for mechanisms for moving network to nearby moving
network communications are focusing on low delays of the data paths,
reduced number of messages for path establishment, application
friendly, resilience to attacks, compatibility with DHCP and Mobile
IP.

In addition, some moving network to nearby moving network applications
involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP moving network to nearby moving netowrk mechanisms will need
to gracefully support IP multicast.

Due to the inherent characteristics of safety-related communications,
all new moving network to nearby moving network mechanisms must afford
authenticity and confidentiality where necessary.  = Dynamically
establishing ephemeral communication paths between automobiles = in
public areas must offer privacy safeguards for the end users
(passengers).

Establishing 1-hop IP V2V paths must not break the existing on-board
protocols and applications which communicate with the Internet,
possibly via multiple radios.

In a moving network deployed in an automobile, typically one = exit
point connects the moving network to other moving networks.  However,
in a more general manner (and to support reliability) any new
mechanism of moving network to nearby moving network communications
should support multi-homing: one router to use multiple = interfaces
towards outside the moving network, or multiple routers.

Current version of Internet protocols
-------------------------------------
The group will only work on IPv6 solutions.

What SDOs may need this work?
-----------------------------
The requirements and standards for moving network to nearby = moving
network communications, often involving IPv6, and novel V2V and
V2Infra concepts, are developed mainly at ISO TC204 = "Intelligent
Transport Systems", 3GPP, ETSI, NHTSA and IEEE.  For
Vehicle-to-Internet communications, 3GPP LTE and other cellular
technologies represent the long-range connectivity method; for
Vehicle-to-Vehicle communications, LTE Direct is currently specified,
as well as OCB mode of IEEE 802.11.  Several use-cases = exhibit a need
for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive
Cruise Control and Platooning.  The IEEE developed a popular = link for
short-range communications - IEEE 802.11p "WAVE".  The NHTSA = wrote a
set of requirements for V2V communications.

Work Items
----------
- use-cases for moving network to nearby moving network communications
- Problem Statement for moving network to nearby moving network communications
  including V2V, V2I and DNS.
- Security and Privacy Requirements for moving network to
  nearby moving network communications
- Solutions, which might include new protocols or extensions to
  existing protocols.  With MIB.
- IPv6-over foo, where foo is pertinent for moving network to nearby
  moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)
- List of Research Papers in the V2V domain, identifying which uses IP.

Timeline
--------
-

_______________________________________________
its mailing list
its@ietf.org
= https://www.ietf.org/mailman/listinfo/its


_______________________________________________
its = mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

= --Apple-Mail=_7FD5F5BE-6F96-4726-8A5B-C0DF96779863-- From nobody Fri Apr 8 05:59:40 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EEA12D694 for ; Fri, 8 Apr 2016 05:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti0J4wZ4WxJH for ; Fri, 8 Apr 2016 05:59:36 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52ACB12D7E0 for ; Fri, 8 Apr 2016 05:59:36 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id i84so127117010ywc.2 for ; Fri, 08 Apr 2016 05:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VmznTnzTFneNezF6BQ06R22ip96LqjH0hicHFkGK9oA=; b=iGJaRxyH7Abtr7Wz75LCCAh4gKeCqpQIfEfYC0WbjTs1jlXd/7PA4F3cuCjavEOl4j uqA3022rn0mhSej81ldan+Zlm4e39OvXQeK8rI8/zOwIcrFKxKIgHeI0RJkwHP6hwUAM 2fM3Gt5IPjTeKMlXIQ3cSje0rkODU3Hsa4UmAl9emqkaBmxIdMvXi6E0xplOr6rBEq7Y B3hNE2Zo+3rXjXkjGpqFELyiUu6Sz6YL+2bjXUKxvVejrEwg+FWT7I+f9q6r1bzzM+V5 ODHTuZvLTHpTKpnQ2AE+wd3V/Cy2gnhveLEJ2bDNitRfm6BDIHSqPTw/AkdD3ffeck83 Y3pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VmznTnzTFneNezF6BQ06R22ip96LqjH0hicHFkGK9oA=; b=GJf9sLhlFqHngChlRlI55LMVAr0eEChOwHLxX4u4fQAMWs22wd638P9vj6ozzmZW0y zdBV1H8Cpa1bHI4KVwr2ASGI6RQ4DI2pW25Ue62m4t/C8XIy5VPxw2nG5TtucSW6z4Jy ZFgMogLzaCsPVynkImqnzlUtkpAt9Gc7uzCC3YBx2tZEnqYvO4JMCoQ5Kgq9PTVjAHOw tuHYfpDxil7ppNEUgES8296ncwjFJspbQQ4jek1JV1+NzimspVgLdmwfjfwCD23xlLQN x0A0WXdP1tZ4ZR0oA9xIRAbgkLPH9+mMNHsVHXPHrH+EiRwmYbbCqq0D+pLBclqm9q8E H/uQ== X-Gm-Message-State: AD7BkJLhlwi/EOTHq0xIsfEvjlSa+TypOxLnyL4aOLK17vGWo85O1IzLpwYz/tdb6vD81v7r+d3YJqUTRuhlWQ== X-Received: by 10.129.88.195 with SMTP id m186mr4471188ywb.342.1460120375508; Fri, 08 Apr 2016 05:59:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.4.22 with HTTP; Fri, 8 Apr 2016 05:59:06 -0700 (PDT) In-Reply-To: References: <57058375.6050101@gmail.com> From: "Mr. Jaehoon Paul Jeong" Date: Fri, 8 Apr 2016 09:59:06 -0300 Message-ID: To: =?UTF-8?Q?Jos=C3=A9_Santa_Lozano?= Content-Type: multipart/alternative; boundary=001a11492e364fc2c2052ff8c46a Archived-At: Cc: Alexandre Petrescu , its@ietf.org Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:59:39 -0000 --001a11492e364fc2c2052ff8c46a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jos=C3=A9, Sure, you are welcome to the contribution for a list of papers for IP-based V2V and V2I. Thanks. -- Paul 2016. 4. 8. =EC=98=A4=EC=A0=84 6:22=EC=97=90 "Jos=C3=A9 Santa Lozano" =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > Dear all, > > From my group we could also contribute, in general, with information abou= t > papers in the area using IP(v6) in both V2V and V2I. > > Regards, > > -- > Jos=C3=A9 Santa Lozano > Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones > Facultad de Inform=C3=A1tica > Universidad de Murcia > 30100 Murcia, Spain > Telf: +34-868-888771 / +34-868-884455 > Fax: +34-868-884151 > Web: http://ants.inf.um.es/~josesanta > > > > El 8 abr 2016, a las 6:13, Mr. Jaehoon Paul Jeong > escribi=C3=B3: > > Hi ITSers, > For a proposed charter item of "List of Research Papers in the V2V domain= , > identifying which uses IP", > I agree that this item should be included into our ITS charter. > > Nabil Benamar, Sandra C=C3=A9spedes, and I agreed on the drafting for thi= s item > into an I-D. > > Thanks. > > -- > Paul > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > On Wed, Apr 6, 2016 at 6:45 PM, Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > >> ITSers, >> >> Please see below the current charter. >> >> - the two Problem Statements drafts V2V and V2I joined, so there is less >> text in charter. >> - added an Item on "List of Research papers..." >> >> Erik: did I understand you correctly that there should be some item on >> discussing whether link-local addressing is sufficient, whether prefix >> exchange is necessary? >> >> Dino: should LISP be included in the gap analysis draft which includes >> C-ACC use-case? OR should we separate a dedicated I-D only with gap >> analysis including ND, MIP, AODVv2, LISP? >> >> Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle >> interface illustrated good enough by the words "moving network to nearby >> moving network communications"? Or is it better to say "the 1-IP-hop >> between nearby moving networks must be self-configured"? >> >> Nabil, Sandra: is it ok to have a working group item "List of Research >> Papers for IP in V2V and V2I communications"? >> >> Other comments? >> >> Alex >> >> ------------------------------------------------------------------ >> >> ITS (name to change) >> Charter >> April 6th, 2016 >> http://ietf.org/mailman/listinfo/its >> >> >> Intelligent Transportation Systems (its) >> ---------------------------------------- >> Current Status: WG forming >> >> Chairs: >> TBD >> >> Assigned Area Director: >> TBD >> >> Mailing list >> Address: its@ietf.org >> 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: >> >> Goal >> ---- >> The goal of this group is to standardize IP-based protocols for >> establishing direct and secure connectivity between moving networks, >> some of which could be fixed permanently or temporarily. >> >> Moving Network to Nearby Moving Network Communications >> ------------------------------------------------------ >> The group is concerned with all situations involving moving network to >> nearby moving network communications. For example: vehicle-to-vehicle >> communications, nomadic user wearing a PAN and communicating to a >> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a >> train, or train-to-intersection signalling. >> >> Example from the automobile communications space >> ------------------------------------------------ >> Automobiles and vehicles of all types are increasingly connected to >> the Internet, either as vehicle-to-vehicle, vehicle-to-infra or >> vehicle-to-Internet. Entertainment apps enhancing comfort, reliable >> data exchanges for road safety, and automated driving are features >> coming in automobiles to hit the roads from now to year 2020. >> Highlighting increased safety as an immediate result of >> hyper-connectivity applied to vehicles, public authorities worldwide >> are increasingly mandating secure communication technology >> requirements in vehicles. >> >> Emergency apps for new instrumented ambulances carry many benefits >> both to the users and to society in general. >> >> Why IP? >> ------- >> Today, there are several deployed Vehicle-to-Internet technologies, >> including car tethering through driver's cellular smartphone. >> However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure >> communications are still being developed. To improve on a situation >> of link-specific data exchanges, and enable independent application >> sets to share the same links, IP data exchanges are needed. Enabling >> IP communication between vehicles (V2V), and between vehicles and the >> immediate infrastructure (V2I), will provide (0) ability to reach the >> rest of the world on the Internet (1) short and deterministic delays, >> (2) fast forwarding through scalable paths of routers, (3) ease of >> reuse of existing Internet applications in a vehicular environment. >> >> Moving network to nearby moving network communications involve link >> layers such as: 802.11p OCB (Outside the Context of a Basic Service >> Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light >> Communications), IrDA, LTE-D. Only the IP protocols are capable of >> running on each of these links and establish IP paths across them in >> an interoperable manner. >> >> Scenarios? >> ---------- >> There are a few scenarios exhibiting the need to communicate from one >> moving network to another nearby moving network. >> >> In the automobile space, the Cooperative Adaptive Cruise Control and >> Platooning features consider that vehicles close to each other >> exchange data describing their kinematic status. At the cross-roads, >> the moving network inside a vehicle exchanges data with the moving >> network in the red-light pole. >> >> Several public safety scenarios involve moving networks. Distinct >> organizations deploy different moving networks (in-vehicle, on-person) >> at an incident scene. These networks need to interoperate in order to >> more effectively understand and deal with the incident scene. >> >> In connected rail scenarios the moving network deployed in trains >> communicate with other moving networks at the cross-points. >> >> What kind of solutions? >> ----------------------- >> The current technical solutions considered to achieve moving network >> to nearby moving network communications are of two kinds: IP routing >> protocols for n-hop path management and 1-hop link-scoped IP protocol >> enhancements. The 1-hop link-scoped protocols include the protocols >> for route establishment involving ICMP Router Advertisements. The >> n-hop path management protocols include n-hop path establishment >> protocols (e.g. Babel, OSPF) and n-hop path search protocols (most >> notably AODV and derivates). >> >> In this proposed Working Group the focus is on 1-hop protocols, and >> leverage from other Working Groups for the n-hop situations. >> >> In some of the moving network applications the window of opportunity >> for exchanging data with the immediate infrastructure may be very >> short. For example, a car driving near a road-side unit may have only >> 5s to exchange with that RSU (depending on speed, RSU range and >> number). (ephemeral connections). >> >> What kind of requirements? >> -------------------------- >> The requirements for mechanisms for moving network to nearby moving >> network communications are focusing on low delays of the data paths, >> reduced number of messages for path establishment, application >> friendly, resilience to attacks, compatibility with DHCP and Mobile >> IP. >> >> In addition, some moving network to nearby moving network applications >> involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the >> 1-hop IP moving network to nearby moving netowrk mechanisms will need >> to gracefully support IP multicast. >> >> Due to the inherent characteristics of safety-related communications, >> all new moving network to nearby moving network mechanisms must afford >> authenticity and confidentiality where necessary. Dynamically >> establishing ephemeral communication paths between automobiles in >> public areas must offer privacy safeguards for the end users >> (passengers). >> >> Establishing 1-hop IP V2V paths must not break the existing on-board >> protocols and applications which communicate with the Internet, >> possibly via multiple radios. >> >> In a moving network deployed in an automobile, typically one exit >> point connects the moving network to other moving networks. However, >> in a more general manner (and to support reliability) any new >> mechanism of moving network to nearby moving network communications >> should support multi-homing: one router to use multiple interfaces >> towards outside the moving network, or multiple routers. >> >> Current version of Internet protocols >> ------------------------------------- >> The group will only work on IPv6 solutions. >> >> What SDOs may need this work? >> ----------------------------- >> The requirements and standards for moving network to nearby moving >> network communications, often involving IPv6, and novel V2V and >> V2Infra concepts, are developed mainly at ISO TC204 "Intelligent >> Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For >> Vehicle-to-Internet communications, 3GPP LTE and other cellular >> technologies represent the long-range connectivity method; for >> Vehicle-to-Vehicle communications, LTE Direct is currently specified, >> as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need >> for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive >> Cruise Control and Platooning. The IEEE developed a popular link for >> short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a >> set of requirements for V2V communications. >> >> Work Items >> ---------- >> - use-cases for moving network to nearby moving network communications >> - Problem Statement for moving network to nearby moving network >> communications >> including V2V, V2I and DNS. >> - Security and Privacy Requirements for moving network to >> nearby moving network communications >> - Solutions, which might include new protocols or extensions to >> existing protocols. With MIB. >> - IPv6-over foo, where foo is pertinent for moving network to nearby >> moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) >> - List of Research Papers in the V2V domain, identifying which uses IP. >> >> Timeline >> -------- >> - >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > --001a11492e364fc2c2052ff8c46a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi=C2=A0Jo= s=C3=A9,

Sure, you are welcom= e to the contribution for a list of papers for IP-based V2V and V2I.=

Thanks.

--

Paul


2016. 4. 8. =EC=98=A4=EC=A0=84 6:22=EC=97=90 &qu= ot;Jos=C3=A9 Santa Lozano" <josesanta@um.es>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:=
Dear all,

From my group we could also contribute, in = general, with information about papers in the area using IP(v6) in both V2V= and V2I.

Regards,

--=C2=A0
Jos=C3=A9 Santa Lozano
Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
Facultad de Inform=C3=A1tica
Universidad de Murcia
30= 100 Murcia, Spain



El 8 abr 2016, a las 6:13, Mr. Jaeh= oon Paul Jeong <jaehoon.paul@gmail.com> escribi=C3=B3:

Hi ITSers,
For a proposed charter item of "List of Research = Papers in the V2V domain, identifying which uses IP",=C2=A0
= I agree that this item should be included into our ITS charter.
<= br>
Nabil Benamar, Sandra C=C3=A9spedes, and I agreed on the draf= ting for this item into an I-D.

Thanks.
=
--
Paul
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Ass= istant Professor
Department of Software
Sungkyunkwan University
Of= fice: +82-31-299-4957
Email:=C2=A0jaehoon.paul@gmail.com,=C2=A0pauljeon= g@skku.edu
Personal Homepage:=C2=A0http://iotlab.skku.edu/people-= jaehoon-jeong.php

On Wed, Apr 6, 2016 at 6:45 PM, Alexandre= Petrescu <alexandre.petrescu@gmail.com> wrote:
=20 =20 =20
ITSers,

Please see below the current charter.

- the two Problem Statements drafts V2V and V2I joined, so there is less text in charter.
- added an Item on "List of Research papers..."

Erik: did I understand you correctly that there should be some item on discussing whether link-local addressing is sufficient, whether prefix exchange is necessary?

Dino: should LISP be included in the gap analysis draft which includes C-ACC use-case?=C2=A0 OR should we separate a dedicated I-D only with gap analysis including ND, MIP, AODVv2, LISP?

Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle interface illustrated good enough by the words "moving network to nearby moving network communications"?= =C2=A0 Or is it better to say "the 1-IP-hop between nearby moving networks mu= st be self-configured"?

Nabil, Sandra: is it ok to have a working group item "List of Research Papers for IP in V2V and V2I communications"?

Other comments?

Alex

------------------------------------------------------------------
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ITS (name to change)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Charter
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 April 6th, 2016
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://ietf.org/mailman/list= info/its


Intelligent Transportation Systems (its)
----------------------------------------
Current Status: WG forming

Chairs:
=C2=A0=C2=A0 TBD

Assigned Area Director:
=C2=A0=C2=A0 TBD

Mailing list
=C2=A0=C2=A0 Address: its@ietf.org
=C2=A0=C2=A0 To Subscribe: https://www.ietf.org/mailman/listinfo/its=
=C2=A0=C2=A0 Archive:
=C2=A0=C2=A0 http://www.ietf.org/mail-archive/web/i= ts/current/maillist.html

Additional web page
=C2=A0=C2=A0 TBD

Charter:

Goal
----
The goal of this group is to standardize IP-based protocols for
establishing direct and secure connectivity between moving networks,
some of which could be fixed permanently or temporarily.

Moving Network to Nearby Moving Network Communications
------------------------------------------------------
The group is concerned with all situations involving moving network to
nearby moving network communications.=C2=A0 For example: vehicle-to-vehicle
communications, nomadic user wearing a PAN and communicating to a
homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a
train, or train-to-intersection signalling.

Example from the automobile communications space
------------------------------------------------
Automobiles and vehicles of all types are increasingly connected to
the Internet, either as vehicle-to-vehicle, vehicle-to-infra or
vehicle-to-Internet.=C2=A0 Entertainment apps enhancing comfort, reliable
data exchanges for road safety, and automated driving are features coming in automobiles to hit the roads from now to year 2020.
Highlighting increased safety as an immediate result of
hyper-connectivity applied to vehicles, public authorities worldwide
are increasingly mandating secure communication technology
requirements in vehicles.

Emergency apps for new instrumented ambulances carry many benefits both to the users and to society in general.

Why IP?
-------
Today, there are several deployed Vehicle-to-Internet technologies,
including car tethering through driver's cellular smartphone.
However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communications are still being developed.=C2=A0 To improve on a situation
of link-specific data exchanges, and enable independent application
sets to share the same links, IP data exchanges are needed.=C2=A0 Enabling
IP communication between vehicles (V2V), and between vehicles and the
immediate infrastructure (V2I), will provide (0) ability to reach the
rest of the world on the Internet (1) short and deterministic delays,
(2) fast forwarding through scalable paths of routers, (3) ease of reuse of existing Internet applications in a vehicular environment.

Moving network to nearby moving network communications involve link
layers such as: 802.11p OCB (Outside the Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light
Communications), IrDA, LTE-D.=C2=A0 Only the IP protocols are capable of
running on each of these links and establish IP paths across them in
an interoperable manner.

Scenarios?
----------
There are a few scenarios exhibiting the need to communicate from one
moving network to another nearby moving network.

In the automobile space, the Cooperative Adaptive Cruise Control and
Platooning features consider that vehicles close to each other
exchange data describing their kinematic status.=C2=A0 At the cross-roads,
the moving network inside a vehicle exchanges data with the moving network in the red-light pole.

Several public safety scenarios involve moving networks.=C2=A0 Distin= ct
organizations deploy different moving networks (in-vehicle, on-person)
at an incident scene.=C2=A0 These networks need to interoperate in order to
more effectively understand and deal with the incident scene.

In connected rail scenarios the moving network deployed in trains
communicate with other moving networks at the cross-points.

What kind of solutions?
-----------------------
The current technical solutions considered to achieve moving network
to nearby moving network communications are of two kinds: IP routing
protocols for n-hop path management and 1-hop link-scoped IP protocol
enhancements.=C2=A0 The 1-hop link-scoped protocols include the protocols
for route establishment involving ICMP Router Advertisements.=C2=A0 T= he
n-hop path management protocols include n-hop path establishment
protocols (e.g. Babel, OSPF) and n-hop path search protocols (most notably AODV and derivates).

In this proposed Working Group the focus is on 1-hop protocols, and
leverage from other Working Groups for the n-hop situations.

In some of the moving network applications the window of opportunity
for exchanging data with the immediate infrastructure may be very
short.=C2=A0 For example, a car driving near a road-side unit may hav= e only
5s to exchange with that RSU (depending on speed, RSU range and
number). (ephemeral connections).

What kind of requirements?
--------------------------
The requirements for mechanisms for moving network to nearby moving
network communications are focusing on low delays of the data paths,
reduced number of messages for path establishment, application
friendly, resilience to attacks, compatibility with DHCP and Mobile
IP.

In addition, some moving network to nearby moving network applications
involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP moving network to nearby moving netowrk mechanisms will need
to gracefully support IP multicast.

Due to the inherent characteristics of safety-related communications,
all new moving network to nearby moving network mechanisms must afford
authenticity and confidentiality where necessary.=C2=A0 Dynamically establishing ephemeral communication paths between automobiles in
public areas must offer privacy safeguards for the end users
(passengers).

Establishing 1-hop IP V2V paths must not break the existing on-board
protocols and applications which communicate with the Internet,
possibly via multiple radios.

In a moving network deployed in an automobile, typically one exit
point connects the moving network to other moving networks.=C2=A0 However,
in a more general manner (and to support reliability) any new
mechanism of moving network to nearby moving network communications
should support multi-homing: one router to use multiple interfaces towards outside the moving network, or multiple routers.

Current version of Internet protocols
-------------------------------------
The group will only work on IPv6 solutions.

What SDOs may need this work?
-----------------------------
The requirements and standards for moving network to nearby moving network communications, often involving IPv6, and novel V2V and
V2Infra concepts, are developed mainly at ISO TC204 "Intelligent=
Transport Systems", 3GPP, ETSI, NHTSA and IEEE.=C2=A0 For
Vehicle-to-Internet communications, 3GPP LTE and other cellular
technologies represent the long-range connectivity method; for
Vehicle-to-Vehicle communications, LTE Direct is currently specified,
as well as OCB mode of IEEE 802.11.=C2=A0 Several use-cases exhibit a need
for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive
Cruise Control and Platooning.=C2=A0 The IEEE developed a popular lin= k for
short-range communications - IEEE 802.11p "WAVE".=C2=A0 The= NHTSA wrote a
set of requirements for V2V communications.

Work Items
----------
- use-cases for moving network to nearby moving network communications
- Problem Statement for moving network to nearby moving network communications
=C2=A0 including V2V, V2I and DNS.
- Security and Privacy Requirements for moving network to
=C2=A0 nearby moving network communications
- Solutions, which might include new protocols or extensions to
=C2=A0 existing protocols.=C2=A0 With MIB.
- IPv6-over foo, where foo is pertinent for moving network to nearby
=C2=A0 moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)
- List of Research Papers in the V2V domain, identifying which uses IP.

Timeline
--------
-

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its


_______________________________________________
its mailing list
its@ietf.org
https://ww= w.ietf.org/mailman/listinfo/its

<= /div>
--001a11492e364fc2c2052ff8c46a-- From nobody Fri Apr 8 06:46:09 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D138E12D0FF for ; Fri, 8 Apr 2016 06:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.333 X-Spam-Level: X-Spam-Status: No, score=-4.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yixMtdYi7Jac for ; Fri, 8 Apr 2016 06:46:05 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D5612D12D for ; Fri, 8 Apr 2016 06:46:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u38Dk2O3028626; Fri, 8 Apr 2016 15:46:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9A786204BE4; Fri, 8 Apr 2016 15:47:13 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8DEBA204B22; Fri, 8 Apr 2016 15:47:13 +0200 (CEST) Received: from [132.166.85.93] ([132.166.85.93]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u38DjxN8017137; Fri, 8 Apr 2016 15:46:00 +0200 To: Michelle Wetterwald References: <570591D1.4070904@gmail.com> From: Alexandre Petrescu Message-ID: <5707B616.4040706@gmail.com> Date: Fri, 8 Apr 2016 10:45:58 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] 6lo X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:46:08 -0000 Le 06/04/2016 21:57, Michelle Wetterwald a écrit : > Hi Alex, all, > > Thank you for these minutes > > I would like to rephrase here the two comments that I made during the > meeting to the V2I problem statement draft and could not be captured in > the minutes: > - in the V2I case, the performance of the system and the coverage time > vs. vehicle speed should be taken into account. At the contrary of the > V2V C-ACC case you described where both cars are moving in the same > direction, which ensures some time to exchange prefixes, names, etc., in > the V2I case, the coverage time with one RSU may be short. Thus this > signalling should have a really low latency. I fully agree, that's the case. Dino also said things in this direction. > - Secondly, the potential congestion of the system when hundreds of cars > would be located in the same area and establishing or using V2I > communications should also be taken into account as an issue. Switching > part of the traffic to a more available channel, as was proposed, may > not always be possible. Reducing the size of the packet, however, by > using header compression technique as in 6lo, may offer a potential > improvement. Do you think 6lo RFC techniques are compatible with using IP in moving network to nearby moving or fixed network communications? AFAIK 6lo implementations are on low-power radios (i.e. 802.15.4, bluetooth), and as such have very small coverage, with cells like 10m. Can a gar connect to it if moving at more than 10kmph? Or is it that car uses 6lo to connect to a gas station RSU while filling gas? If so it's V2I. Or is it that driver uses 6lo NFC card to open/close doors? That's _one_ fixed network (the car) and a Host (the NFC card) - it's not moving network to nearby moving or fixed network communications. If we could frame it as moving network to nearby moving or fixed network communications for V2V and/or V2I, then it's in scope. Alex > > Best regards, > Michelle Wetterwald > ---- > Senior expert in networking and telecommunications > > 2016-04-06 19:46 GMT-03:00 Alexandre Petrescu > >: > > Raw meeting minutes, thanks to minute takers for efforts despite > echo-ey PA system. > > Alex > > ------------------------------------------------------------------ > > Minutes for [its] > > • Introduction: > > > – Administrative - BOF Chairs - 5 min > > > – ITS Goals and Success Criteria - BOF Chairs - 10 min > > > • Problem Space: > > > – Tutorial of IP in vehicular communications - Alex Petrescu - 20 min > Randel Gelland: Since there are so many MAC & PHY, they use their own > messaging -- so could use IP. But vehicals are using different PHY > & MAC, so they can't communicate > Alex: But some of the radios are actually compatible > > Bob Hinden: On "Topology" slide -- this is very simplified. There > will be > many cars, with very dynamic interconnection > Alex: Yes. Gives more examples to support contention > > Dapeng Liu: Once connectivity is established, > IP will enable better communication. > > Pat Thaler: Even for compatible PHY, MACs may be different, so can't > just day > "use IP" > > Erik Nordmark: Have people considered what the IP addressing will > look like? > In the car, the addressing is stable, but not outside the car. How > does one car know the address in the other car? > Alex: Yes, people are working on this. IETF can help. > > Carlos: Are people working on the addressing sheme. > > Dino: We have an IP mobility problem > > Dirk Kircher: Broadcast. Semantic layer. > Alex: There may be multiple hops beween cars, and multiple hops in a > car. > May need IPv4 broadcast, or IPv6 broadcast > > Dino: Even without the mobility problem, we still would have > physical layer > incompatible problems. But that is exactly what IP solves. > > – ITS use-cases C-ACC and Platooning - Alex Petrescu - 10 min > draft-petrescu-its-cacc-sdo-04 > > > Lou Berger: Hackable. What's the security model? > Alex: Do not have slides about this. > Eric Rescolo: Why make any representation about exceeding speedlimit. > Alex: It's just an example > Eric Rescolo: What if the police ask this question? > > > Sandra: there is a lot of work being done on security > = Safety part > > Eric Burdick: There are a lot of privacy issues. There is work > about jamming. > It's not just Mobile IP. > > Erik Nordmark: There was an IETF plenary that is relevant to security. > = Police can probaly go get the data > > Eric Rescolo: Lots of work to be done -- prevent querying in the car. > > > – ITS V2V problem statement - Dapeng Liu - 5 min > draft-petrescu-its-problem-00 > > Randel Gelland: How do they know when they need to discover the > other vehicles' > address? > Dirk Kircher: Sub-Problem(1) needs to be characterized correctly. > What is a > realistic use case: Answer: C-ACC > > ...: do you have data? > Alex: How much data do you want? > > Randel Gellens: This shows how IP is useful, but it's not why IP is > needed? > So it is needed to exhibit the need, not just the use case. > > Erik Nordmark: how identities (or even temporary identities) > established? > > Hannes Tshofenig: Is there a need for another layer for identity? > > > – ITS V2I problem statement - Jaehoon Paul Jeong - 5 min > draft-jeong-its-v2i-problem-statement-00 > > Charlie: What does it mean to "directly" connect to the RSO's network > Jaehoon: Exchange prefixes > > Woman > > Dino: a lost packet could be a catastrophe, amidst a lot of connection. > Need to avoid chit-chat. Should avoid multiple solutions. > If security requires Diffie-Hellman, may not get to finally say > "BRAKE" > Dino: May not be able to go get a certificate. > > <....?>: May not have time to > > Dirk Kircher: Question about use case... > > Alex: Some operators already provide connection between RSUs, and thus > can provide handovers > > • Discussion - 10 min > > Aaron Falk: Good to have the discussion. Useful confusion [??} > Dirk Kircher: Use cases need discussion, as well as network drivers. > Carlos: Are you talking about requirements? > Dirk: Network requirements... > Erik Nordmark: Don't really grasp exactly why IP is needed for > single hop. > Will this use the same Internet? What about the timing > requirements? > Stan Ratliff: V2V could be mobile ad hoc network? > Russ: Not if it's just one hop. > <...> : Want to know what cars are closing in. Could want to send > message > just backwards. > Dino: What if you *don't* have IP? A lot of vehicles already have > IP, so it > is already there. IP could simplify the automobile and the > communications. We will want to write applications. Will need > to have > compatible format. We will want open standards. > Spencer Dawkins: Was waiting for a transport question. Applications > might be > close to each other? About updating the car. > Hannes: Applications might be running on many different computers > and media, > but still need to communicate. > Pat Thaler: Updating the car is a different sort of thing than V2I. > We will > have updates at the service station, so you're not moving. > Three concerns: security problem. Time constraints. > Spencer: Need to understand what the volume of data would be. > Dirk: Is it, or is it not, TCP? There are a couple of protocols in > use today. > Eric Burdick: Should assume that all protocols are broken. > The control mechanisms could collapse with the number of cars. > > – What documents are needed to advance this work? > http://itu.int/go/ITScomms is complete list of ITU work items > > Dino: Why include trains but not planes? > Alex: O.K. > Erik Burdick: What about when get onto the ocean? > Dirk: Some of the use cases are very dissimilar. Need to pick one > problem. > Aaron from Jabber: Can assume use of certificates. > Dino: Need to look at the requirements and see if there are solutions, > even though there are a lot of work items. > Erik Nordmark: Can we figure out what is needed for the immediate term? > Randall Gellens: What about coordination with other SDOs? For instance > regarding IPv6-over-foo. > Alex: With a working group we can have a channel by which to do the > coordination > Randall: We have that with ISO, 3GPP, etc. > > Closing remarks: > We will publish the charter on the working group. In about a month we > will see if we have a rigorous charter. > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > -- > Michelle Wetterwald > michelle.wetterwald@gmail.com From nobody Fri Apr 8 06:55:04 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C82D12D8D4 for ; Fri, 8 Apr 2016 06:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgehuCyLNUT4 for ; Fri, 8 Apr 2016 06:55:01 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5B312D8BE for ; Fri, 8 Apr 2016 06:55:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u38DsxiV009435; Fri, 8 Apr 2016 15:54:59 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E0D81204BBD; Fri, 8 Apr 2016 15:56:10 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D54C920196F; Fri, 8 Apr 2016 15:56:10 +0200 (CEST) Received: from [132.166.85.93] ([132.166.85.93]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u38Dsv1W019332; Fri, 8 Apr 2016 15:54:58 +0200 To: Dino Farinacci References: <57058375.6050101@gmail.com> <6B2D2039-34AD-41BA-9B9D-61164C9043CB@gmail.com> <570597A5.9050902@gmail.com> <57059F53.5030106@gmail.com> <56FF3138-1F13-4B5C-BBCF-D41FE66BE3B0@gmail.com> From: Alexandre Petrescu Message-ID: <5707B830.7090502@gmail.com> Date: Fri, 8 Apr 2016 10:54:56 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <56FF3138-1F13-4B5C-BBCF-D41FE66BE3B0@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:55:03 -0000 Le 06/04/2016 23:05, Dino Farinacci a crit : >> Any new solution designed in this group must not alter what you >> know to do v2i with LISP. For example, if there is prefix exchange >> between vehicle and an RSU that must not break LISP from doing v2i >> (vehicle to Internet) through that same RSU. There is a similar >> problem in Mobile IP. > > LISP doenst have a prefix exchange. The vehicle would be assigned a > static IPv6 EID address. There wont be any broad changes to the LISP > protocol to support this because we support such use-cases already. It is good that LISP can work ok when prefix exchanges happen near it. This kind of text can easily make part of a gap analysis draft. If a car uses LISP for its V2I, and car uses a prefix exchange to a nearby car, you may want that people in the Internet reach this latter car via former's car LISP V2I. In that case, one may want LISP to accept a prefix coming from another car, into the LISP system, maybe tag it differently. That would express that prefix exchanges can work fully independently of LISP. > That is, an EID can move around when another device is the RLOC. So > the RSU is the RLOC and encap/decaps packets to and from the EID (the > car) that roams. The EIDs that come in range of the RSU are > registered dynamically to the mapping system. > > We do this for LISP-MN when LISP runs in a smartphone. And we do this > when VM roams from one type-of-rack switch to another in the data > center. In the former case, the EID and RLOC in are in the same node. > In the latter case, the EID and RLOC are in separate nodes. > > So we (the LISP WG) can present the solution and the ITS group can > decide what the gaps are. Ok. Now the question is also whether there is someone from the LISP community intent in contributing text to a WG item in ITS, called 'gap analysis'. >> If so, then this should be described so in the gap analysis or in a >> requirements draft. Which one would you prefer? >> >> (RSU: Road Side Unit: a set of computers linked by Ethernet and >> situated in a box along the road, to control traffic lights and >> other embedded sensors, and also do 802.11p to the vehicle; an RSU >> is connected to the Internet by either ADSL or its own cellular >> link). > > And as I mentioned in the BOF. We solved this with planes. Where the > EIDs were end-systems on the plane that had session continuity > requirements. When the planes flew over routers on the ground, the > routers were the RLOCs for the EIDs on the plane. Very much like cars > driving by RSUs. > > If you think it would be useful, we could even demonstrate this for > the ITS group. Thank you for the offer! Demonstrators are always welcome. But, we are not there yet. Let's discuss charter now and in 1 month we'll see. Alex > > Dino > > From nobody Fri Apr 8 07:03:41 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C7312D900 for ; Fri, 8 Apr 2016 07:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phPOgJSamzlQ for ; Fri, 8 Apr 2016 07:03:32 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AEF212D8E8 for ; Fri, 8 Apr 2016 07:03:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u38E3Tfl029330 for ; Fri, 8 Apr 2016 16:03:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F00AE204BC3 for ; Fri, 8 Apr 2016 16:04:40 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DED87204B22 for ; Fri, 8 Apr 2016 16:04:40 +0200 (CEST) Received: from [132.166.85.93] ([132.166.85.93]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u38E3R5V030367 for ; Fri, 8 Apr 2016 16:03:28 +0200 To: its@ietf.org References: <201604080903146552249@cnnic.cn> From: Alexandre Petrescu Message-ID: <5707BA2E.2080902@gmail.com> Date: Fri, 8 Apr 2016 11:03:26 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <201604080903146552249@cnnic.cn> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:03:38 -0000 Le 07/04/2016 22:03, Z.W. Yan a crit : > Hi, All, About the charter, I think we should also consider and > describe the NEMO and nested-NEMO scenarios and protocols. > Otherwise, it just falls back to the application of plain MIP/PMIP no > matter in the V2V case or V2I case. Zhiwei Yan, I disagree with you saying it's just a plain MIP. There is currently a 'gap analysis' part, section 14.2 'Mobile IP': https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-04#page-15 For Mobile IP: - currently a car can't send a BU to another car if the HA is absent (out of LTE coverage). That's an old Route Optimization problem in MIP. Do you agree with this gap? And, to be more clear, this should _not_ lead to developping extensions of Mobile IP to solve this V2V case, because there are other bigger problems I can describe separately. One of these relates to security. Alex > > BR, Zhiwei Yan 2016-04-08 > ------------------------------------------------------------------------ > > > Z.W. Yan > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Fri Apr 8 07:06:01 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4300D12D8D4 for ; Fri, 8 Apr 2016 07:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.353 X-Spam-Level: X-Spam-Status: No, score=-4.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pp6KcKxr7cqJ for ; Fri, 8 Apr 2016 07:05:56 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3C612D829 for ; Fri, 8 Apr 2016 07:05:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u38E5rXA013939; Fri, 8 Apr 2016 16:05:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2F011204A4F; Fri, 8 Apr 2016 16:07:05 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 21915200F4A; Fri, 8 Apr 2016 16:07:05 +0200 (CEST) Received: from [132.166.85.93] ([132.166.85.93]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u38E5p2V030310; Fri, 8 Apr 2016 16:05:51 +0200 To: "Mr. Jaehoon Paul Jeong" References: <57058375.6050101@gmail.com> From: Alexandre Petrescu Message-ID: <5707BABE.7000002@gmail.com> Date: Fri, 8 Apr 2016 11:05:50 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:05:59 -0000 Paul, Thank you. I will consider a WG item in the charter containing "List of Research Papers in the V2V domain, identifying which uses IP". Please keep watching this list during the next month, as there will be some iterations of the charter text. Alex Le 08/04/2016 01:13, Mr. Jaehoon Paul Jeong a écrit : > Hi ITSers, > For a proposed charter item of "List of Research Papers in the V2V > domain, identifying which uses IP", > I agree that this item should be included into our ITS charter. > > Nabil Benamar, Sandra Céspedes, and I agreed on the drafting for this > item into an I-D. > > Thanks. > > -- > Paul > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com , > pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > On Wed, Apr 6, 2016 at 6:45 PM, Alexandre Petrescu > > wrote: > > ITSers, > > Please see below the current charter. > > - the two Problem Statements drafts V2V and V2I joined, so there is > less text in charter. > - added an Item on "List of Research papers..." > > Erik: did I understand you correctly that there should be some item > on discussing whether link-local addressing is sufficient, whether > prefix exchange is necessary? > > Dino: should LISP be included in the gap analysis draft which > includes C-ACC use-case? OR should we separate a dedicated I-D only > with gap analysis including ND, MIP, AODVv2, LISP? > > Person from mediatek: is the 'zeroconf' need in the > vehicle-to-vehicle interface illustrated good enough by the words > "moving network to nearby moving network communications"? Or is it > better to say "the 1-IP-hop between nearby moving networks must be > self-configured"? > > Nabil, Sandra: is it ok to have a working group item "List of > Research Papers for IP in V2V and V2I communications"? > > Other comments? > > Alex > > ------------------------------------------------------------------ > > ITS (name to change) > Charter > April 6th, 2016 > http://ietf.org/mailman/listinfo/its > > > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming > > Chairs: > TBD > > Assigned Area Director: > TBD > > Mailing list > Address: its@ietf.org > 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: > > Goal > ---- > The goal of this group is to standardize IP-based protocols for > establishing direct and secure connectivity between moving networks, > some of which could be fixed permanently or temporarily. > > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving network to > nearby moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > train, or train-to-intersection signalling. > > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to > the Internet, either as vehicle-to-vehicle, vehicle-to-infra or > vehicle-to-Internet. Entertainment apps enhancing comfort, reliable > data exchanges for road safety, and automated driving are features > coming in automobiles to hit the roads from now to year 2020. > Highlighting increased safety as an immediate result of > hyper-connectivity applied to vehicles, public authorities worldwide > are increasingly mandating secure communication technology > requirements in vehicles. > > Emergency apps for new instrumented ambulances carry many benefits > both to the users and to society in general. > > Why IP? > ------- > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. > However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure > communications are still being developed. To improve on a situation > of link-specific data exchanges, and enable independent application > sets to share the same links, IP data exchanges are needed. Enabling > IP communication between vehicles (V2V), and between vehicles and the > immediate infrastructure (V2I), will provide (0) ability to reach the > rest of the world on the Internet (1) short and deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) ease of > reuse of existing Internet applications in a vehicular environment. > > Moving network to nearby moving network communications involve link > layers such as: 802.11p OCB (Outside the Context of a Basic Service > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light > Communications), IrDA, LTE-D. Only the IP protocols are capable of > running on each of these links and establish IP paths across them in > an interoperable manner. > > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate from one > moving network to another nearby moving network. > > In the automobile space, the Cooperative Adaptive Cruise Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the cross-roads, > the moving network inside a vehicle exchanges data with the moving > network in the red-light pole. > > Several public safety scenarios involve moving networks. Distinct > organizations deploy different moving networks (in-vehicle, on-person) > at an incident scene. These networks need to interoperate in order to > more effectively understand and deal with the incident scene. > > In connected rail scenarios the moving network deployed in trains > communicate with other moving networks at the cross-points. > > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol > enhancements. The 1-hop link-scoped protocols include the protocols > for route establishment involving ICMP Router Advertisements. The > n-hop path management protocols include n-hop path establishment > protocols (e.g. Babel, OSPF) and n-hop path search protocols (most > notably AODV and derivates). > > In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations. > > In some of the moving network applications the window of opportunity > for exchanging data with the immediate infrastructure may be very > short. For example, a car driving near a road-side unit may have only > 5s to exchange with that RSU (depending on speed, RSU range and > number). (ephemeral connections). > > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to nearby moving > network communications are focusing on low delays of the data paths, > reduced number of messages for path establishment, application > friendly, resilience to attacks, compatibility with DHCP and Mobile > IP. > > In addition, some moving network to nearby moving network applications > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the > 1-hop IP moving network to nearby moving netowrk mechanisms will need > to gracefully support IP multicast. > > Due to the inherent characteristics of safety-related communications, > all new moving network to nearby moving network mechanisms must afford > authenticity and confidentiality where necessary. Dynamically > establishing ephemeral communication paths between automobiles in > public areas must offer privacy safeguards for the end users > (passengers). > > Establishing 1-hop IP V2V paths must not break the existing on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. > > In a moving network deployed in an automobile, typically one exit > point connects the moving network to other moving networks. However, > in a more general manner (and to support reliability) any new > mechanism of moving network to nearby moving network communications > should support multi-homing: one router to use multiple interfaces > towards outside the moving network, or multiple routers. > > Current version of Internet protocols > ------------------------------------- > The group will only work on IPv6 solutions. > > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to nearby moving > network communications, often involving IPv6, and novel V2V and > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For > Vehicle-to-Internet communications, 3GPP LTE and other cellular > technologies represent the long-range connectivity method; for > Vehicle-to-Vehicle communications, LTE Direct is currently specified, > as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need > for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive > Cruise Control and Platooning. The IEEE developed a popular link for > short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a > set of requirements for V2V communications. > > Work Items > ---------- > - use-cases for moving network to nearby moving network communications > - Problem Statement for moving network to nearby moving network > communications > including V2V, V2I and DNS. > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Solutions, which might include new protocols or extensions to > existing protocols. With MIB. > - IPv6-over foo, where foo is pertinent for moving network to nearby > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) > - List of Research Papers in the V2V domain, identifying which uses IP. > > Timeline > -------- > - > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Fri Apr 8 07:07:01 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA3812D8F8; Fri, 8 Apr 2016 07:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gPrrS4QX5e4; Fri, 8 Apr 2016 07:06:56 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E278212D8FB; Fri, 8 Apr 2016 07:06:55 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id k135so40419192qke.0; Fri, 08 Apr 2016 07:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AdI1uHPG+l45A+Slwd5aHFvOLEs7Nj5pQaA+2aBMwwo=; b=to8laWv/d222GhVFgyivGdynKFEQGbPoRvK54zGz8kT67TsH7bhEyxFhzux143Cs6N vteRyhIAzMIcUFP83oapm8WWPmDAlYnMzyyqkMsC+trOGiuzoLdoCIvy2ZkXL654dJ13 aISNuQXHGxwMpPKzUZSQBHJCSFWd/judM3u3ZqftJLGPCdHAcYSk9ekdeJ9neu8JCBtS Gl/bi+flCplq9LJcNvUiSS8mtBogToEi9C1Q9XfK4k+N7ot7kDt7GehPY/PUkA4goGfU 8LzifJzEoskM009YgC+puVuQYygQ4KeGBFmrC5PDAgVfK+BM3X/W1mgMXLVu9URDe2yG evgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AdI1uHPG+l45A+Slwd5aHFvOLEs7Nj5pQaA+2aBMwwo=; b=B11f7LWQzkq6eYAFXS/TAmCCg6ECXMy1jOwHueGNpNijMiHxibphjypJkSGxVOOy4j iTiu6gDrYbEAg1aw15e7bV66xzpRru5qQODC3+Mbx7mofDbcGKqKcfVNQPSIwNq5N2NN 3+5ksbJSxThve6rAkVeBDbCTdn9JlwjamVhG8IsAl8M5a2aNdtVbD4K2CTR24AQHKj5z rTF/GlWMpqiq7RXcvKgknEQQrO1HIugAqxId2a1KARvH7VEA5UOwRATp3DFyv0bF3cyb DEGaPU++3qalZPYBMv4cwSfCGBDYEDIchvuEhBhRRbA7USbkzLBci7CE8plNBCCkoJ4j HajQ== X-Gm-Message-State: AD7BkJKzCl9JGsb6Y76CAueeUycYYBcq1XSebqN5e2QkOOGtM2uG7YP4YT4O6IQTCUUWlg== X-Received: by 10.55.207.156 with SMTP id v28mr11394208qkl.46.1460124414958; Fri, 08 Apr 2016 07:06:54 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:ec:6a07:837b:8c60? ([2001:67c:370:176:ec:6a07:837b:8c60]) by smtp.gmail.com with ESMTPSA id s16sm5576908qkl.31.2016.04.08.07.06.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 07:06:54 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: <5707B830.7090502@gmail.com> Date: Fri, 8 Apr 2016 07:06:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <68DEFC0C-7044-421F-A86A-D3AE0E7E0CBB@gmail.com> References: <57058375.6050101@gmail.com> <6B2D2039-34AD-41BA-9B9D-61164C9043CB@gmail.com> <570597A5.9050902@gmail.com> <57059F53.5030106@gmail.com> <56FF3138-1F13-4B5C-BBCF-D41FE66BE3B0@gmail.com> <5707B830.7090502@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3112) Archived-At: Cc: LISP mailing list list , "its@ietf.org" Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:06:58 -0000 CC=92ing the LISP working group since you are soliciting help. LISP WG folks, please comment. Thanks in advance. > Le 06/04/2016 23:05, Dino Farinacci a =E9crit : >>> Any new solution designed in this group must not alter what you >>> know to do v2i with LISP. For example, if there is prefix exchange >>> between vehicle and an RSU that must not break LISP from doing v2i >>> (vehicle to Internet) through that same RSU. There is a similar >>> problem in Mobile IP. >>=20 >> LISP doens=92t have a prefix exchange. The vehicle would be assigned = a >> static IPv6 EID address. There won=92t be any broad changes to the = LISP >> protocol to support this because we support such use-cases already. >=20 > It is good that LISP can work ok when prefix exchanges happen near it. = This kind of text can easily make part of a gap analysis draft. >=20 > If a car uses LISP for its V2I, and car uses a prefix exchange to a = nearby car, you may want that people in the Internet reach this latter = car via former's car LISP V2I. In that case, one may want LISP to = accept a prefix coming from another car, into the LISP system, maybe tag = it differently. There should be no prefix exchange. It takes too long to do signalling = when you want to move application data. The car should have an EID that = is preassigned (and based on the VIN number of the car - auto-makers = have asked for this requirement). When the car moves in signal range of an RSU, it uses it immmediately to = send traffic. Return traffic needs to be encapsulated to the RSU, so the = EID to RSU-RLOC binding needs to go to the mapping database as fast as = possible. We can take advantage of a liner physical path and do predictive RLOCs. = So encapsulated traffic can go to the current RSU, or the one the car is = about to approach, or both at the same time to minimize packet loss. > That would express that prefix exchanges can work fully independently = of LISP. Or avoided all together because it will serve no purpose. >> That is, an EID can move around when another device is the RLOC. So >> the RSU is the RLOC and encap/decaps packets to and from the EID (the >> car) that roams. The EIDs that come in range of the RSU are >> registered dynamically to the mapping system. >>=20 >> We do this for LISP-MN when LISP runs in a smartphone. And we do this >> when VM roams from one type-of-rack switch to another in the data >> center. In the former case, the EID and RLOC in are in the same node. >> In the latter case, the EID and RLOC are in separate nodes. >>=20 >> So we (the LISP WG) can present the solution and the ITS group can >> decide what the gaps are. >=20 > Ok. >=20 > Now the question is also whether there is someone from the LISP = community intent in contributing text to a WG item in ITS, called 'gap = analysis=92. We will get someone to do it. >=20 >>> If so, then this should be described so in the gap analysis or in a >>> requirements draft. Which one would you prefer? >>>=20 >>> (RSU: Road Side Unit: a set of computers linked by Ethernet and >>> situated in a box along the road, to control traffic lights and >>> other embedded sensors, and also do 802.11p to the vehicle; an RSU >>> is connected to the Internet by either ADSL or its own cellular >>> link). >>=20 >> And as I mentioned in the BOF. We solved this with planes. Where the >> EIDs were end-systems on the plane that had session continuity >> requirements. When the planes flew over routers on the ground, the >> routers were the RLOCs for the EIDs on the plane. Very much like cars >> driving by RSUs. >>=20 >> If you think it would be useful, we could even demonstrate this for >> the ITS group. >=20 > Thank you for the offer! Demonstrators are always welcome. We can show solutions and architectures for better understanding through = demos. > But, we are not there yet. Let's discuss charter now and in 1 month = we'll see. >=20 > Alex Ack. Dino >=20 >>=20 >> Dino >>=20 >>=20 From nobody Fri Apr 8 07:10:24 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E9812D8CF for ; Fri, 8 Apr 2016 07:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGDuVYiei-1E for ; Fri, 8 Apr 2016 07:10:20 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EF712D105 for ; Fri, 8 Apr 2016 07:10:20 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id o6so44259186qkc.2 for ; Fri, 08 Apr 2016 07:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HfHzkNtcacu2yWoci1wStrsBN0Gtp28BVofp38B/yPg=; b=AYZFEjFUSNrW92HeVZLUQH486X67tZWKmZ4C/WpNkFm64HojEfCpY4M+G1q+daLKab w4ZTEZ4UeAbEGpuyUGM7bfBBg8SunLY5UZJTWcFn7mvJg1tcFtWcH/c78/AaRFgLNbFU trkIUR1WSEknEzGFvXx+IDaMuRyZgVhnHL8m45kynnMiZpMAfw5BVOCFkDzs5rd3ue6a kqb63B0WSeJCMqUc7CVSHnQnVQuyiNV192frJTEleuU1Q5d8eYAzoDZDBcTwtita5+/k Cj8Erigw6K6UczoY8B5GZfsr6vfx2unNw+jLtom0tpKC23wEJFgKbsU0CMJntxxPZn6S pNsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HfHzkNtcacu2yWoci1wStrsBN0Gtp28BVofp38B/yPg=; b=hxgsigdJamPoXPgWDm6+wlGn5B5jY7pTqMLk9+SH7WwvV37GV+e0fnsP12QM8sCKWG O38brFDeuC3/FwQ1Pb2UPARyvwKWHBaITFXvtUjYmt3VeK7CqvO9/8Os/QOVX3AvWwOk EoqAjzMh28DI4IIH3lwZN2wBYAAzasFG+dUQSxQR0K6KR24fkA97UC8XyVrTBnlCaPL0 YGa0UY7IlPbDNoFP47D0/ksukIu/oWilA3nTJAH1lGky9guPT3e+hHiR401sJBWeiwqB ik15aVjsW8Bz+r2ljKa2EhfP8Eh/q9yxwW6q+uvmZbCY4GOVoicE5w29OUfgYurkseHI Of/A== X-Gm-Message-State: AD7BkJKFw7N6CZk1VLBhphQZd1fuiiRt+4PUXPplB1SxMTMF3b0wyrosIt04OxK23BxKAQ== X-Received: by 10.55.209.13 with SMTP id s13mr11247482qki.58.1460124619455; Fri, 08 Apr 2016 07:10:19 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:ec:6a07:837b:8c60? ([2001:67c:370:176:ec:6a07:837b:8c60]) by smtp.gmail.com with ESMTPSA id t10sm5531316qhc.13.2016.04.08.07.10.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 07:10:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: <5707B616.4040706@gmail.com> Date: Fri, 8 Apr 2016 07:10:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6C8F8863-552E-4190-ACEF-A3566E0F0633@gmail.com> References: <570591D1.4070904@gmail.com> <5707B616.4040706@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "its@ietf.org" , Michelle Wetterwald Subject: Re: [its] 6lo X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:10:23 -0000 I am wondering if v2v can succeed better with no data-oriented = commmunication (IP protocols get in the say and actually slow down = reaction time). Maybe the front facing camera alone provides enough = information to the computing elements in the following car to detect = when its getting close to the car it is following. The rate the image increases in size can determine the rate and distance = you are to the car in front of you.=20 Just wondering ... Dino > On Apr 8, 2016, at 6:45 AM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 06/04/2016 21:57, Michelle Wetterwald a =C3=A9crit : >> Hi Alex, all, >>=20 >> Thank you for these minutes >>=20 >> I would like to rephrase here the two comments that I made during = the >> meeting to the V2I problem statement draft and could not be captured = in >> the minutes: >> - in the V2I case, the performance of the system and the coverage = time >> vs. vehicle speed should be taken into account. At the contrary of = the >> V2V C-ACC case you described where both cars are moving in the same >> direction, which ensures some time to exchange prefixes, names, etc., = in >> the V2I case, the coverage time with one RSU may be short. Thus this >> signalling should have a really low latency. >=20 > I fully agree, that's the case. Dino also said things in this = direction. >=20 >> - Secondly, the potential congestion of the system when hundreds of = cars >> would be located in the same area and establishing or using V2I >> communications should also be taken into account as an issue. = Switching >> part of the traffic to a more available channel, as was proposed, may >> not always be possible. Reducing the size of the packet, however, by >> using header compression technique as in 6lo, may offer a potential >> improvement. >=20 > Do you think 6lo RFC techniques are compatible with using IP in moving = network to nearby moving or fixed network communications? >=20 > AFAIK 6lo implementations are on low-power radios (i.e. 802.15.4, = bluetooth), and as such have very small coverage, with cells like 10m. = Can a gar connect to it if moving at more than 10kmph? >=20 > Or is it that car uses 6lo to connect to a gas station RSU while = filling gas? If so it's V2I. >=20 > Or is it that driver uses 6lo NFC card to open/close doors? That's = _one_ fixed network (the car) and a Host (the NFC card) - it's not = moving network to nearby moving or fixed network communications. >=20 > If we could frame it as moving network to nearby moving or fixed = network communications for V2V and/or V2I, then it's in scope. >=20 > Alex >=20 >>=20 >> Best regards, >> Michelle Wetterwald >> ---- >> Senior expert in networking and telecommunications >>=20 >> 2016-04-06 19:46 GMT-03:00 Alexandre Petrescu >> >: >>=20 >> Raw meeting minutes, thanks to minute takers for efforts despite >> echo-ey PA system. >>=20 >> Alex >>=20 >> ------------------------------------------------------------------ >>=20 >> Minutes for [its] >>=20 >> =E2=80=A2 Introduction: >>=20 >>=20 >> =E2=80=93 Administrative - BOF Chairs - 5 min >>=20 >>=20 >> =E2=80=93 ITS Goals and Success Criteria - BOF Chairs - 10 min >>=20 >>=20 >> =E2=80=A2 Problem Space: >>=20 >>=20 >> =E2=80=93 Tutorial of IP in vehicular communications - Alex = Petrescu - 20 min >> Randel Gelland: Since there are so many MAC & PHY, they use their = own >> messaging -- so could use IP. But vehicals are using = different PHY >> & MAC, so they can't communicate >> Alex: But some of the radios are actually compatible >>=20 >> Bob Hinden: On "Topology" slide -- this is very simplified. There >> will be >> many cars, with very dynamic interconnection >> Alex: Yes. Gives more examples to support contention >>=20 >> Dapeng Liu: Once connectivity is established, >> IP will enable better communication. >>=20 >> Pat Thaler: Even for compatible PHY, MACs may be different, so = can't >> just day >> "use IP" >>=20 >> Erik Nordmark: Have people considered what the IP addressing will >> look like? >> In the car, the addressing is stable, but not outside the = car. How >> does one car know the address in the other car? >> Alex: Yes, people are working on this. IETF can help. >>=20 >> Carlos: Are people working on the addressing sheme. >>=20 >> Dino: We have an IP mobility problem >>=20 >> Dirk Kircher: Broadcast. Semantic layer. >> Alex: There may be multiple hops beween cars, and multiple hops in = a >> car. >> May need IPv4 broadcast, or IPv6 broadcast >>=20 >> Dino: Even without the mobility problem, we still would have >> physical layer >> incompatible problems. But that is exactly what IP solves. >>=20 >> =E2=80=93 ITS use-cases C-ACC and Platooning - Alex Petrescu - 10 = min >> draft-petrescu-its-cacc-sdo-04 >>=20 >> >> Lou Berger: Hackable. What's the security model? >> Alex: Do not have slides about this. >> Eric Rescolo: Why make any representation about exceeding = speedlimit. >> Alex: It's just an example >> Eric Rescolo: What if the police ask this question? >> >>=20 >> Sandra: there is a lot of work being done on security >> =3D Safety part >>=20 >> Eric Burdick: There are a lot of privacy issues. There is work >> about jamming. >> It's not just Mobile IP. >>=20 >> Erik Nordmark: There was an IETF plenary that is relevant to = security. >> =3D Police can probaly go get the data >>=20 >> Eric Rescolo: Lots of work to be done -- prevent querying in the = car. >>=20 >>=20 >> =E2=80=93 ITS V2V problem statement - Dapeng Liu - 5 min >> draft-petrescu-its-problem-00 >>=20 >> Randel Gelland: How do they know when they need to discover the >> other vehicles' >> address? >> Dirk Kircher: Sub-Problem(1) needs to be characterized correctly. >> What is a >> realistic use case: Answer: C-ACC >>=20 >> ...: do you have data? >> Alex: How much data do you want? >>=20 >> Randel Gellens: This shows how IP is useful, but it's not why IP = is >> needed? >> So it is needed to exhibit the need, not just the use case. >>=20 >> Erik Nordmark: how identities (or even temporary identities) >> established? >>=20 >> Hannes Tshofenig: Is there a need for another layer for identity? >>=20 >>=20 >> =E2=80=93 ITS V2I problem statement - Jaehoon Paul Jeong - 5 min >> draft-jeong-its-v2i-problem-statement-00 >>=20 >> Charlie: What does it mean to "directly" connect to the RSO's = network >> Jaehoon: Exchange prefixes >>=20 >> Woman >>=20 >> Dino: a lost packet could be a catastrophe, amidst a lot of = connection. >> Need to avoid chit-chat. Should avoid multiple solutions. >> If security requires Diffie-Hellman, may not get to finally = say >> "BRAKE" >> Dino: May not be able to go get a certificate. >>=20 >> <....?>: May not have time to >>=20 >> Dirk Kircher: Question about use case... >>=20 >> Alex: Some operators already provide connection between RSUs, and = thus >> can provide handovers >>=20 >> =E2=80=A2 Discussion - 10 min >>=20 >> Aaron Falk: Good to have the discussion. Useful confusion [??} >> Dirk Kircher: Use cases need discussion, as well as network = drivers. >> Carlos: Are you talking about requirements? >> Dirk: Network requirements... >> Erik Nordmark: Don't really grasp exactly why IP is needed for >> single hop. >> Will this use the same Internet? What about the timing >> requirements? >> Stan Ratliff: V2V could be mobile ad hoc network? >> Russ: Not if it's just one hop. >> <...> : Want to know what cars are closing in. Could want to send >> message >> just backwards. >> Dino: What if you *don't* have IP? A lot of vehicles already have >> IP, so it >> is already there. IP could simplify the automobile and the >> communications. We will want to write applications. Will = need >> to have >> compatible format. We will want open standards. >> Spencer Dawkins: Was waiting for a transport question. = Applications >> might be >> close to each other? About updating the car. >> Hannes: Applications might be running on many different computers >> and media, >> but still need to communicate. >> Pat Thaler: Updating the car is a different sort of thing than = V2I. >> We will >> have updates at the service station, so you're not moving. >> Three concerns: security problem. Time constraints. >> Spencer: Need to understand what the volume of data would be. >> Dirk: Is it, or is it not, TCP? There are a couple of protocols = in >> use today. >> Eric Burdick: Should assume that all protocols are broken. >> The control mechanisms could collapse with the number of = cars. >>=20 >> =E2=80=93 What documents are needed to advance this work? >> http://itu.int/go/ITScomms is complete list of ITU work items >>=20 >> Dino: Why include trains but not planes? >> Alex: O.K. >> Erik Burdick: What about when get onto the ocean? >> Dirk: Some of the use cases are very dissimilar. Need to pick one >> problem. >> Aaron from Jabber: Can assume use of certificates. >> Dino: Need to look at the requirements and see if there are = solutions, >> even though there are a lot of work items. >> Erik Nordmark: Can we figure out what is needed for the immediate = term? >> Randall Gellens: What about coordination with other SDOs? For = instance >> regarding IPv6-over-foo. >> Alex: With a working group we can have a channel by which to do = the >> coordination >> Randall: We have that with ISO, 3GPP, etc. >>=20 >> Closing remarks: >> We will publish the charter on the working group. In about a = month we >> will see if we have a rigorous charter. >>=20 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 >>=20 >>=20 >> -- >> Michelle Wetterwald >> michelle.wetterwald@gmail.com >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Fri Apr 8 08:06:04 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7533A12D951 for ; Fri, 8 Apr 2016 08:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.353 X-Spam-Level: X-Spam-Status: No, score=-4.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUhc7cbQv57j for ; Fri, 8 Apr 2016 08:05:59 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854C612D940 for ; Fri, 8 Apr 2016 08:05:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u38F5fS2007723; Fri, 8 Apr 2016 17:05:41 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0E7D0204CB8; Fri, 8 Apr 2016 17:06:53 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F3CC0201A77; Fri, 8 Apr 2016 17:06:52 +0200 (CEST) Received: from [132.166.85.93] ([132.166.85.93]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u38F5c8B011448; Fri, 8 Apr 2016 17:05:39 +0200 To: Dino Farinacci References: <570591D1.4070904@gmail.com> <5707B616.4040706@gmail.com> <6C8F8863-552E-4190-ACEF-A3566E0F0633@gmail.com> From: Alexandre Petrescu Message-ID: <5707C8C1.6030106@gmail.com> Date: Fri, 8 Apr 2016 12:05:37 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <6C8F8863-552E-4190-ACEF-A3566E0F0633@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" , Michelle Wetterwald Subject: Re: [its] 6lo X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 15:06:02 -0000 Le 08/04/2016 11:10, Dino Farinacci a écrit : > I am wondering if v2v can succeed better with no data-oriented > commmunication (IP protocols get in the say and actually slow down > reaction time). Maybe the front facing camera alone provides enough > information to the computing elements in the following car It would be wonderful if it were possible that the front camera of a truck wirelesly sends data to rear vehicles. But that's not possible because the truck frame in between is blocking these waves. That's why people plug the camera (some times IP-enabled) to an IP router in the truck which has additional IP interface (11p) towards the car behind. The car behind sends IP service discovery requests, and then receives an IP stream of video which shows what the truck sees. But beware human behaviour: analysts say that driver is too distracted by the realism of the image streamed by the truck - s/he believes being _in_ the truck and hits it. (multiple demonstrators exhibit this; the Samsung Safety Truck is shown just because we're in Argentina and it made much publicity). > to detect when its getting close to the car it is following. Yes, many cars on the market today analyse the image of the front and make multiple decisions to avoid hitting cars, pedestrians, keep lane, and so on. But that's an image processing problem, not communication problem. The problems of the webcams in reocnizing obstacles is that they may issue false positives. That's why they're assisted by radars. But radars have other problems on metal bridges. Assisted by lidars too, but these are too big and too latent. That's why only message exchanges (preferentially using TCP/IP protocols) are able to improve current systems of obstacle avoidance, lane keeping, self driving, etc. Alex > > The rate the image increases in size can determine the rate and > distance you are to the car in front of you. > > Just wondering ... > > Dino > >> On Apr 8, 2016, at 6:45 AM, Alexandre Petrescu >> wrote: >> >> >> >> Le 06/04/2016 21:57, Michelle Wetterwald a écrit : >>> Hi Alex, all, >>> >>> Thank you for these minutes >>> >>> I would like to rephrase here the two comments that I made during >>> the meeting to the V2I problem statement draft and could not be >>> captured in the minutes: - in the V2I case, the performance of >>> the system and the coverage time vs. vehicle speed should be >>> taken into account. At the contrary of the V2V C-ACC case you >>> described where both cars are moving in the same direction, which >>> ensures some time to exchange prefixes, names, etc., in the V2I >>> case, the coverage time with one RSU may be short. Thus this >>> signalling should have a really low latency. >> >> I fully agree, that's the case. Dino also said things in this >> direction. >> >>> - Secondly, the potential congestion of the system when hundreds >>> of cars would be located in the same area and establishing or >>> using V2I communications should also be taken into account as an >>> issue. Switching part of the traffic to a more available channel, >>> as was proposed, may not always be possible. Reducing the size of >>> the packet, however, by using header compression technique as in >>> 6lo, may offer a potential improvement. >> >> Do you think 6lo RFC techniques are compatible with using IP in >> moving network to nearby moving or fixed network communications? >> >> AFAIK 6lo implementations are on low-power radios (i.e. 802.15.4, >> bluetooth), and as such have very small coverage, with cells like >> 10m. Can a gar connect to it if moving at more than 10kmph? >> >> Or is it that car uses 6lo to connect to a gas station RSU while >> filling gas? If so it's V2I. >> >> Or is it that driver uses 6lo NFC card to open/close doors? That's >> _one_ fixed network (the car) and a Host (the NFC card) - it's not >> moving network to nearby moving or fixed network communications. >> >> If we could frame it as moving network to nearby moving or fixed >> network communications for V2V and/or V2I, then it's in scope. >> >> Alex >> >>> >>> Best regards, Michelle Wetterwald ---- Senior expert in >>> networking and telecommunications >>> >>> 2016-04-06 19:46 GMT-03:00 Alexandre Petrescu >>> >> >: >>> >>> Raw meeting minutes, thanks to minute takers for efforts despite >>> echo-ey PA system. >>> >>> Alex >>> >>> ------------------------------------------------------------------ >>> >>> >>> >>> >>> >>> Minutes for [its] >>> >>> • Introduction: >>> >>> >>> – Administrative - BOF Chairs - 5 min >>> >>> >>> – ITS Goals and Success Criteria - BOF Chairs - 10 min >>> >>> >>> • Problem Space: >>> >>> >>> – Tutorial of IP in vehicular communications - Alex Petrescu - >>> 20 min Randel Gelland: Since there are so many MAC & PHY, they >>> use their own messaging -- so could use IP. But vehicals are >>> using different PHY & MAC, so they can't communicate Alex: But >>> some of the radios are actually compatible >>> >>> Bob Hinden: On "Topology" slide -- this is very simplified. There >>> will be many cars, with very dynamic interconnection Alex: Yes. >>> Gives more examples to support contention >>> >>> Dapeng Liu: Once connectivity is established, IP will enable >>> better communication. >>> >>> Pat Thaler: Even for compatible PHY, MACs may be different, so >>> can't just day "use IP" >>> >>> Erik Nordmark: Have people considered what the IP addressing will >>> look like? In the car, the addressing is stable, but not outside >>> the car. How does one car know the address in the other car? >>> Alex: Yes, people are working on this. IETF can help. >>> >>> Carlos: Are people working on the addressing sheme. >>> >>> Dino: We have an IP mobility problem >>> >>> Dirk Kircher: Broadcast. Semantic layer. Alex: There may be >>> multiple hops beween cars, and multiple hops in a car. May need >>> IPv4 broadcast, or IPv6 broadcast >>> >>> Dino: Even without the mobility problem, we still would have >>> physical layer incompatible problems. But that is exactly what >>> IP solves. >>> >>> – ITS use-cases C-ACC and Platooning - Alex Petrescu - 10 min >>> draft-petrescu-its-cacc-sdo-04 >>> >>> Lou Berger: >>> Hackable. What's the security model? Alex: Do not have slides >>> about this. Eric Rescolo: Why make any representation about >>> exceeding speedlimit. Alex: It's just an example Eric Rescolo: >>> What if the police ask this question? >> speed parameter> >>> >>> Sandra: there is a lot of work being done on security = Safety >>> part >>> >>> Eric Burdick: There are a lot of privacy issues. There is work >>> about jamming. It's not just Mobile IP. >>> >>> Erik Nordmark: There was an IETF plenary that is relevant to >>> security. = Police can probaly go get the data >>> >>> Eric Rescolo: Lots of work to be done -- prevent querying in the >>> car. >>> >>> >>> – ITS V2V problem statement - Dapeng Liu - 5 min >>> draft-petrescu-its-problem-00 >>> >>> Randel Gelland: How do they know when they need to discover the >>> other vehicles' address? Dirk Kircher: Sub-Problem(1) needs to >>> be characterized correctly. What is a realistic use case: >>> Answer: C-ACC >>> >>> ...: do you have data? Alex: How much data do you want? >>> >>> Randel Gellens: This shows how IP is useful, but it's not why IP >>> is needed? So it is needed to exhibit the need, not just the use >>> case. >>> >>> Erik Nordmark: how identities (or even temporary identities) >>> established? >>> >>> Hannes Tshofenig: Is there a need for another layer for >>> identity? >>> >>> >>> – ITS V2I problem statement - Jaehoon Paul Jeong - 5 min >>> draft-jeong-its-v2i-problem-statement-00 >>> >>> Charlie: What does it mean to "directly" connect to the RSO's >>> network Jaehoon: Exchange prefixes >>> >>> Woman >>> >>> Dino: a lost packet could be a catastrophe, amidst a lot of >>> connection. Need to avoid chit-chat. Should avoid multiple >>> solutions. If security requires Diffie-Hellman, may not get to >>> finally say "BRAKE" Dino: May not be able to go get a >>> certificate. >>> >>> <....?>: May not have time to >>> >>> Dirk Kircher: Question about use case... >>> >>> Alex: Some operators already provide connection between RSUs, >>> and thus can provide handovers >>> >>> • Discussion - 10 min >>> >>> Aaron Falk: Good to have the discussion. Useful confusion [??} >>> Dirk Kircher: Use cases need discussion, as well as network >>> drivers. Carlos: Are you talking about requirements? Dirk: >>> Network requirements... Erik Nordmark: Don't really grasp >>> exactly why IP is needed for single hop. Will this use the same >>> Internet? What about the timing requirements? Stan Ratliff: V2V >>> could be mobile ad hoc network? Russ: Not if it's just one hop. >>> <...> : Want to know what cars are closing in. Could want to >>> send message just backwards. Dino: What if you *don't* have IP? A >>> lot of vehicles already have IP, so it is already there. IP >>> could simplify the automobile and the communications. We will >>> want to write applications. Will need to have compatible format. >>> We will want open standards. Spencer Dawkins: Was waiting for a >>> transport question. Applications might be close to each other? >>> About updating the car. Hannes: Applications might be running on >>> many different computers and media, but still need to >>> communicate. Pat Thaler: Updating the car is a different sort of >>> thing than V2I. We will have updates at the service station, so >>> you're not moving. Three concerns: security problem. Time >>> constraints. Spencer: Need to understand what the volume of data >>> would be. Dirk: Is it, or is it not, TCP? There are a couple of >>> protocols in use today. Eric Burdick: Should assume that all >>> protocols are broken. The control mechanisms could collapse with >>> the number of cars. >>> >>> – What documents are needed to advance this work? >>> http://itu.int/go/ITScomms is complete list of ITU work items >>> >>> Dino: Why include trains but not planes? Alex: O.K. Erik >>> Burdick: What about when get onto the ocean? Dirk: Some of the >>> use cases are very dissimilar. Need to pick one problem. Aaron >>> from Jabber: Can assume use of certificates. Dino: Need to look >>> at the requirements and see if there are solutions, even though >>> there are a lot of work items. Erik Nordmark: Can we figure out >>> what is needed for the immediate term? Randall Gellens: What >>> about coordination with other SDOs? For instance regarding >>> IPv6-over-foo. Alex: With a working group we can have a channel >>> by which to do the coordination Randall: We have that with ISO, >>> 3GPP, etc. >>> >>> Closing remarks: We will publish the charter on the working >>> group. In about a month we will see if we have a rigorous >>> charter. >>> >>> _______________________________________________ its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>> >>> >>> >>> -- Michelle Wetterwald michelle.wetterwald@gmail.com >>> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Fri Apr 8 13:14:16 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E02B12D5FC for ; Fri, 8 Apr 2016 13:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgr3GoFAE206 for ; Fri, 8 Apr 2016 13:14:12 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE9512D192 for ; Fri, 8 Apr 2016 13:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1680; q=dns/txt; s=iport; t=1460146452; x=1461356052; h=from:to:subject:date:message-id:mime-version; bh=gK5lbbIRt5/72HRSUGHKj57FNNjHsqWwNsI6W8T2MOQ=; b=JKmkEMdMXwErfaG6uAJFC0kNayfQF/ufpmSzyvGFq1GWu6nRF5yk9wd9 q6BGMBj6Nq9R9/ORB4SOO7xHGUx5LYlantFB0p5/+RoiHLuS+fNGy4z03 3qy7rGrbcMcF7bV6VMD+Pq0C21+5aEMF/SOXWZ4zQzp7EtB+wdAlE94lW s=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C/AgBfEAhX/4gNJK1cgzdTfQa4MIIPD?= =?us-ascii?q?oFzIYVsgTU4FAEBAQEBAQFlHAuESCNoAUoCNCcEIYgZDp8Tj12RZAEBAQEBAQQ?= =?us-ascii?q?BAQEBAQEBAQEPBASGIYF1h0eCTiuCKwWYBAGDI4FmiQKBUQEVhE2IWY8kAR4BQ?= =?us-ascii?q?4NnbAGIOn4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="asc'?scan'208";a="257682225" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 20:14:11 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u38KEApD006950 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Apr 2016 20:14:10 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 16:14:09 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 16:14:09 -0400 From: "Carlos Pignataro (cpignata)" To: "its@ietf.org" Thread-Topic: DRAFT IETF95 ITS meeting minutes Thread-Index: AQHRkdM1jGD7m0c8G0+US11MoDFmGA== Date: Fri, 8 Apr 2016 20:14:09 +0000 Message-ID: <6017F20C-06D9-44E9-A079-B408E2A11084@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.247.9] Content-Type: multipart/signed; boundary="Apple-Mail=_521D8D04-F90C-456D-BABE-A998046655B5"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: [its] DRAFT IETF95 ITS meeting minutes X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 20:14:13 -0000 --Apple-Mail=_521D8D04-F90C-456D-BABE-A998046655B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 ITS, Please find below the posted *DRAFT* meeting minutes for ITS. https://www.ietf.org/proceedings/95/minutes/minutes-95-its If you have any corrections, omissions, or other fixes, please reply and = do let us know. FYI, complete proceedings can be found at https://www.ietf.org/proceedings/95/its.html Thanks, =E2=80=94 Carlos. --Apple-Mail=_521D8D04-F90C-456D-BABE-A998046655B5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXCBEQAAoJEIXgpQGOZny9uZwP/3h4ZLnnoDUR7iS4kR9NyuTK u/ewvmXchZZzaCs1jbGCuJ6C5J2XpQoQJ6cx9uNfYWd5Ci7lQLSn3+Gi55m98lwv HGTUIahTCuA1qai6pIvugSbJCfSdYrCpfloq8r37ge9RS9XnulCw2YtizDGe8pVu 2iGwBH0pNJCgy5+ZsEsXhUu6ErU6W3DpWAGYp29+/IFoyG626RvLx+awd3WZFUA0 EO4fArsisP3l7a5h8xvMuXdn7R7TKcI/qDs0vkcjkwgR8WcE4ShicUjdPpQYPcVU 5761ZPF51KP3DXFarCcMITRBk5fVf+O4gdsVBpEAgepy8TjwjbYapDCTscoKSTR3 GSzDWDzgatLE+7kv1NQIUorN/i+4hy9UyQoinFtRblPr29agHfzoLYlGFBWBNepf 5/EYlwgxZmrMKCWzh6ppsjlXYu3NuxfRITrCt37ozKPKuyrw2ygKUdfsVGb/wfpD m7D1/CqctpibRdPDLzromKDcHI2TFi1eJObjXiEqinLqaPAWW7dAsz2N79wl4HVJ k5/Q7uxXa5VKS8qB6uS6wFq6CKVExRZh8nER/1HccHVBv+rJ021EXctuWas0kGnU KG9hVkF70GAyHk2tNnMUaj5Sd6O2JMeCKlA3b8VVObWqab+eQbkpIPpe70iQtA6F R5DVsEHoIqkl9KbBf/xf =ADwj -----END PGP SIGNATURE----- --Apple-Mail=_521D8D04-F90C-456D-BABE-A998046655B5-- From nobody Fri Apr 8 14:33:46 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EB812D665 for ; Fri, 8 Apr 2016 14:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEMBb4VU2H4K for ; Fri, 8 Apr 2016 14:33:42 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C8012D6BC for ; Fri, 8 Apr 2016 14:33:42 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id c6so101588133qga.1 for ; Fri, 08 Apr 2016 14:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Lt/qcwvsAKGkkDyOeg8PbfQOEKYCAmJdrHSja37lxiw=; b=yV4py9fwTIBu+2MXdpo+MlOTPfvAXHs55TGDFRC7Nx54aoQ9VP4ETigCC6ryypHRo/ TFZ0P4y73f96lWDDqDRoh909us76FMK2OD3U71rXgBIMX9fRlZH6ZFhcygJ/kSAc8Th6 HJUyQ3FVe03Ez3ymruBaAipju+dv8V/Rn6FL35WEcC9ON0UNjG+2cIeeV5mmTW0bDY3O CnG3IQaUK2KbOWiiR/MiZf6ICQ03+k5sRyh5B4Wpn072ue2kMdlQwONVH5dQLaCas4nW jTQF+qFP3OOMyN4T//x3Ib9h+pV9aiwp+ia4VNl2i4UaG1fSsiXrd3DJ4+ZpSFav2QEE AqLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Lt/qcwvsAKGkkDyOeg8PbfQOEKYCAmJdrHSja37lxiw=; b=T4wyqpD3LiHNe39QuZcnCjV5JZgCss+/J2ptiZWprL1pPqdmhf+3rrR88Z6p8MlT6d 85w6E/4zgZWIi+z0Es4gCsDcQsAF+YBZgv245aaGTX6j3KlMR/vZWrq4D42D5oq3zuxt 0dbU8hMn/iXZUGCQseSEA2DDWrKUNkJLW6CgTxUreaJ6UHZqHAhfpst3ifZZ8uEm+xj4 0f+e2EmJTKflCkQNsj5XpQmyvBngzTkQHN38aHqwEY7HnXztgoSdS/JQIyz1ChC3xB4+ /eBHWzzQTVgfH1lzn/theT2hiHR91ZAHa5OYzNkuODjeJUZwGOXJ1DUgSPwHXyASrNNl brtA== X-Gm-Message-State: AD7BkJJEldOx6NCJiiXrg0h2HZA+5dJXn29pxX84vpnnHgbJhSvwo7BcIXeqGLLpcqUCHw== X-Received: by 10.140.100.184 with SMTP id s53mr13812187qge.19.1460151221343; Fri, 08 Apr 2016 14:33:41 -0700 (PDT) Received: from [192.168.0.152] (host123.181-15-240.telecom.net.ar. [181.15.240.123]) by smtp.gmail.com with ESMTPSA id 78sm6316730qhr.4.2016.04.08.14.33.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 14:33:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: <5707C8C1.6030106@gmail.com> Date: Fri, 8 Apr 2016 14:33:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <570591D1.4070904@gmail.com> <5707B616.4040706@gmail.com> <6C8F8863-552E-4190-ACEF-A3566E0F0633@gmail.com> <5707C8C1.6030106@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "its@ietf.org" , Michelle Wetterwald Subject: Re: [its] 6lo X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 21:33:44 -0000 The whole point and question is, the car, as a single unit, being self = sufficient is probably the best way to solve this v2v problem. Dino > On Apr 8, 2016, at 8:05 AM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 08/04/2016 11:10, Dino Farinacci a =C3=A9crit : >> I am wondering if v2v can succeed better with no data-oriented >> commmunication (IP protocols get in the say and actually slow down >> reaction time). Maybe the front facing camera alone provides enough >> information to the computing elements in the following car >=20 > It would be wonderful if it were possible that the front camera of a > truck wirelesly sends data to rear vehicles. But that's not possible > because the truck frame in between is blocking these waves. >=20 > That's why people plug the camera (some times IP-enabled) to an IP > router in the truck which has additional IP interface (11p) towards = the > car behind. >=20 > The car behind sends IP service discovery requests, and then receives = an > IP stream of video which shows what the truck sees. >=20 > But beware human behaviour: analysts say that driver is too distracted > by the realism of the image streamed by the truck - s/he believes = being > _in_ the truck and hits it. >=20 > (multiple demonstrators exhibit this; the Samsung Safety Truck is = shown > just because we're in Argentina and it made much publicity). >=20 >> to detect when its getting close to the car it is following. >=20 > Yes, many cars on the market today analyse the image of the front and > make multiple decisions to avoid hitting cars, pedestrians, keep lane, > and so on. >=20 > But that's an image processing problem, not communication problem. >=20 > The problems of the webcams in reocnizing obstacles is that they may > issue false positives. That's why they're assisted by radars. But > radars have other problems on metal bridges. Assisted by lidars too, > but these are too big and too latent. >=20 > That's why only message exchanges (preferentially using TCP/IP > protocols) are able to improve current systems of obstacle avoidance, > lane keeping, self driving, etc. >=20 > Alex >=20 >>=20 >> The rate the image increases in size can determine the rate and >> distance you are to the car in front of you. >>=20 >> Just wondering ... >>=20 >> Dino >>=20 >>> On Apr 8, 2016, at 6:45 AM, Alexandre Petrescu >>> wrote: >>>=20 >>>=20 >>>=20 >>> Le 06/04/2016 21:57, Michelle Wetterwald a =C3=A9crit : >>>> Hi Alex, all, >>>>=20 >>>> Thank you for these minutes >>>>=20 >>>> I would like to rephrase here the two comments that I made during >>>> the meeting to the V2I problem statement draft and could not be >>>> captured in the minutes: - in the V2I case, the performance of >>>> the system and the coverage time vs. vehicle speed should be >>>> taken into account. At the contrary of the V2V C-ACC case you >>>> described where both cars are moving in the same direction, which >>>> ensures some time to exchange prefixes, names, etc., in the V2I >>>> case, the coverage time with one RSU may be short. Thus this >>>> signalling should have a really low latency. >>>=20 >>> I fully agree, that's the case. Dino also said things in this >>> direction. >>>=20 >>>> - Secondly, the potential congestion of the system when hundreds >>>> of cars would be located in the same area and establishing or >>>> using V2I communications should also be taken into account as an >>>> issue. Switching part of the traffic to a more available channel, >>>> as was proposed, may not always be possible. Reducing the size of >>>> the packet, however, by using header compression technique as in >>>> 6lo, may offer a potential improvement. >>>=20 >>> Do you think 6lo RFC techniques are compatible with using IP in >>> moving network to nearby moving or fixed network communications? >>>=20 >>> AFAIK 6lo implementations are on low-power radios (i.e. 802.15.4, >>> bluetooth), and as such have very small coverage, with cells like >>> 10m. Can a gar connect to it if moving at more than 10kmph? >>>=20 >>> Or is it that car uses 6lo to connect to a gas station RSU while >>> filling gas? If so it's V2I. >>>=20 >>> Or is it that driver uses 6lo NFC card to open/close doors? That's >>> _one_ fixed network (the car) and a Host (the NFC card) - it's not >>> moving network to nearby moving or fixed network communications. >>>=20 >>> If we could frame it as moving network to nearby moving or fixed >>> network communications for V2V and/or V2I, then it's in scope. >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Best regards, Michelle Wetterwald ---- Senior expert in >>>> networking and telecommunications >>>>=20 >>>> 2016-04-06 19:46 GMT-03:00 Alexandre Petrescu >>>> >>> >: >>>>=20 >>>> Raw meeting minutes, thanks to minute takers for efforts despite >>>> echo-ey PA system. >>>>=20 >>>> Alex >>>>=20 >>>> ------------------------------------------------------------------ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 > Minutes for [its] >>>>=20 >>>> =E2=80=A2 Introduction: >>>>=20 >>>>=20 >>>> =E2=80=93 Administrative - BOF Chairs - 5 min >>>>=20 >>>>=20 >>>> =E2=80=93 ITS Goals and Success Criteria - BOF Chairs - 10 min >>>>=20 >>>>=20 >>>> =E2=80=A2 Problem Space: >>>>=20 >>>>=20 >>>> =E2=80=93 Tutorial of IP in vehicular communications - Alex = Petrescu - >>>> 20 min Randel Gelland: Since there are so many MAC & PHY, they >>>> use their own messaging -- so could use IP. But vehicals are >>>> using different PHY & MAC, so they can't communicate Alex: But >>>> some of the radios are actually compatible >>>>=20 >>>> Bob Hinden: On "Topology" slide -- this is very simplified. There >>>> will be many cars, with very dynamic interconnection Alex: Yes. >>>> Gives more examples to support contention >>>>=20 >>>> Dapeng Liu: Once connectivity is established, IP will enable >>>> better communication. >>>>=20 >>>> Pat Thaler: Even for compatible PHY, MACs may be different, so >>>> can't just day "use IP" >>>>=20 >>>> Erik Nordmark: Have people considered what the IP addressing will >>>> look like? In the car, the addressing is stable, but not outside >>>> the car. How does one car know the address in the other car? >>>> Alex: Yes, people are working on this. IETF can help. >>>>=20 >>>> Carlos: Are people working on the addressing sheme. >>>>=20 >>>> Dino: We have an IP mobility problem >>>>=20 >>>> Dirk Kircher: Broadcast. Semantic layer. Alex: There may be >>>> multiple hops beween cars, and multiple hops in a car. May need >>>> IPv4 broadcast, or IPv6 broadcast >>>>=20 >>>> Dino: Even without the mobility problem, we still would have >>>> physical layer incompatible problems. But that is exactly what >>>> IP solves. >>>>=20 >>>> =E2=80=93 ITS use-cases C-ACC and Platooning - Alex Petrescu - 10 = min >>>> draft-petrescu-its-cacc-sdo-04 >>>>=20 >>>> Lou Berger: >>>> Hackable. What's the security model? Alex: Do not have slides >>>> about this. Eric Rescolo: Why make any representation about >>>> exceeding speedlimit. Alex: It's just an example Eric Rescolo: >>>> What if the police ask this question? >>> speed parameter> >>>>=20 >>>> Sandra: there is a lot of work being done on security =3D Safety >>>> part >>>>=20 >>>> Eric Burdick: There are a lot of privacy issues. There is work >>>> about jamming. It's not just Mobile IP. >>>>=20 >>>> Erik Nordmark: There was an IETF plenary that is relevant to >>>> security. =3D Police can probaly go get the data >>>>=20 >>>> Eric Rescolo: Lots of work to be done -- prevent querying in the >>>> car. >>>>=20 >>>>=20 >>>> =E2=80=93 ITS V2V problem statement - Dapeng Liu - 5 min >>>> draft-petrescu-its-problem-00 >>>>=20 >>>> Randel Gelland: How do they know when they need to discover the >>>> other vehicles' address? Dirk Kircher: Sub-Problem(1) needs to >>>> be characterized correctly. What is a realistic use case: >>>> Answer: C-ACC >>>>=20 >>>> ...: do you have data? Alex: How much data do you want? >>>>=20 >>>> Randel Gellens: This shows how IP is useful, but it's not why IP >>>> is needed? So it is needed to exhibit the need, not just the use >>>> case. >>>>=20 >>>> Erik Nordmark: how identities (or even temporary identities) >>>> established? >>>>=20 >>>> Hannes Tshofenig: Is there a need for another layer for >>>> identity? >>>>=20 >>>>=20 >>>> =E2=80=93 ITS V2I problem statement - Jaehoon Paul Jeong - 5 min >>>> draft-jeong-its-v2i-problem-statement-00 >>>>=20 >>>> Charlie: What does it mean to "directly" connect to the RSO's >>>> network Jaehoon: Exchange prefixes >>>>=20 >>>> Woman >>>>=20 >>>> Dino: a lost packet could be a catastrophe, amidst a lot of >>>> connection. Need to avoid chit-chat. Should avoid multiple >>>> solutions. If security requires Diffie-Hellman, may not get to >>>> finally say "BRAKE" Dino: May not be able to go get a >>>> certificate. >>>>=20 >>>> <....?>: May not have time to >>>>=20 >>>> Dirk Kircher: Question about use case... >>>>=20 >>>> Alex: Some operators already provide connection between RSUs, >>>> and thus can provide handovers >>>>=20 >>>> =E2=80=A2 Discussion - 10 min >>>>=20 >>>> Aaron Falk: Good to have the discussion. Useful confusion [??} >>>> Dirk Kircher: Use cases need discussion, as well as network >>>> drivers. Carlos: Are you talking about requirements? Dirk: >>>> Network requirements... Erik Nordmark: Don't really grasp >>>> exactly why IP is needed for single hop. Will this use the same >>>> Internet? What about the timing requirements? Stan Ratliff: V2V >>>> could be mobile ad hoc network? Russ: Not if it's just one hop. >>>> <...> : Want to know what cars are closing in. Could want to >>>> send message just backwards. Dino: What if you *don't* have IP? A >>>> lot of vehicles already have IP, so it is already there. IP >>>> could simplify the automobile and the communications. We will >>>> want to write applications. Will need to have compatible format. >>>> We will want open standards. Spencer Dawkins: Was waiting for a >>>> transport question. Applications might be close to each other? >>>> About updating the car. Hannes: Applications might be running on >>>> many different computers and media, but still need to >>>> communicate. Pat Thaler: Updating the car is a different sort of >>>> thing than V2I. We will have updates at the service station, so >>>> you're not moving. Three concerns: security problem. Time >>>> constraints. Spencer: Need to understand what the volume of data >>>> would be. Dirk: Is it, or is it not, TCP? There are a couple of >>>> protocols in use today. Eric Burdick: Should assume that all >>>> protocols are broken. The control mechanisms could collapse with >>>> the number of cars. >>>>=20 >>>> =E2=80=93 What documents are needed to advance this work? >>>> http://itu.int/go/ITScomms is complete list of ITU work items >>>>=20 >>>> Dino: Why include trains but not planes? Alex: O.K. Erik >>>> Burdick: What about when get onto the ocean? Dirk: Some of the >>>> use cases are very dissimilar. Need to pick one problem. Aaron >>>> from Jabber: Can assume use of certificates. Dino: Need to look >>>> at the requirements and see if there are solutions, even though >>>> there are a lot of work items. Erik Nordmark: Can we figure out >>>> what is needed for the immediate term? Randall Gellens: What >>>> about coordination with other SDOs? For instance regarding >>>> IPv6-over-foo. Alex: With a working group we can have a channel >>>> by which to do the coordination Randall: We have that with ISO, >>>> 3GPP, etc. >>>>=20 >>>> Closing remarks: We will publish the charter on the working >>>> group. In about a month we will see if we have a rigorous >>>> charter. >>>>=20 >>>> _______________________________________________ its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- Michelle Wetterwald michelle.wetterwald@gmail.com >>>> >>>=20 >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 From nobody Mon Apr 11 00:28:09 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EDA12E809 for ; Mon, 11 Apr 2016 00:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_1iBIXduU9I for ; Mon, 11 Apr 2016 00:28:05 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id 897FF12E808 for ; Mon, 11 Apr 2016 00:28:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,462,1454972400"; d="scan'208";a="3608302" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 11 Apr 2016 09:28:02 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 76900B99; Mon, 11 Apr 2016 09:28:02 +0200 (CEST) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Dino Farinacci'" , "'Alexandre Petrescu'" References: <570591D1.4070904@gmail.com> <5707B616.4040706@gmail.com> <6C8F8863-552E-4190-ACEF-A3566E0F0633@gmail.com> <5707C8C1.6030106@gmail.com> In-Reply-To: Date: Mon, 11 Apr 2016 09:28:02 +0200 Organization: EURECOM Message-ID: <019801d193c3$ae7453a0$0b5cfae0$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLmzkE25vbzKf9xfH861UXoYnkRmwE3SJcSAZnfClEBcP6m0AGond3OAiOLglWdGXVVwA== Content-Language: en-us Archived-At: Cc: its@ietf.org, 'Michelle Wetterwald' Subject: Re: [its] 6lo X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 07:28:08 -0000 Dear ITSer, In the different e-mails exchanged, there seems to be always reference = to industrial products that would use IP (IPv6 I guess) in vehicles, as = an example and justification of the need for an IPv6 solution for V2V = and V2I.=20 In order to give a clear overview of what the industry plans for this, I = mentioned in my previous e-mail that the IETF ITS should create a WI, = which would aim at referencing industrial products or vision that would = foresee an IETF need in ITS, and which could not be solved by other SDOs = (WAVE,...).=20 As mentioned in my previous e-mail, getting a list of academic papers is = only one side of the mirror, and my itself will not justify a WG...we = need an industrial justification and support.=20 Best Regards, J=C3=A9r=C3=B4me -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Dino Farinacci Sent: Friday 08 April 2016 23:33 To: Alexandre Petrescu Cc: its@ietf.org; Michelle Wetterwald Subject: Re: [its] 6lo The whole point and question is, the car, as a single unit, being self = sufficient is probably the best way to solve this v2v problem. Dino > On Apr 8, 2016, at 8:05 AM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 08/04/2016 11:10, Dino Farinacci a =C3=A9crit : >> I am wondering if v2v can succeed better with no data-oriented=20 >> commmunication (IP protocols get in the say and actually slow down=20 >> reaction time). Maybe the front facing camera alone provides enough=20 >> information to the computing elements in the following car >=20 > It would be wonderful if it were possible that the front camera of a=20 > truck wirelesly sends data to rear vehicles. But that's not possible=20 > because the truck frame in between is blocking these waves. >=20 > That's why people plug the camera (some times IP-enabled) to an IP=20 > router in the truck which has additional IP interface (11p) towards=20 > the car behind. >=20 > The car behind sends IP service discovery requests, and then receives=20 > an IP stream of video which shows what the truck sees. >=20 > But beware human behaviour: analysts say that driver is too distracted = > by the realism of the image streamed by the truck - s/he believes=20 > being _in_ the truck and hits it. >=20 > (multiple demonstrators exhibit this; the Samsung Safety Truck is=20 > shown just because we're in Argentina and it made much publicity). >=20 >> to detect when its getting close to the car it is following. >=20 > Yes, many cars on the market today analyse the image of the front and=20 > make multiple decisions to avoid hitting cars, pedestrians, keep lane, = > and so on. >=20 > But that's an image processing problem, not communication problem. >=20 > The problems of the webcams in reocnizing obstacles is that they may=20 > issue false positives. That's why they're assisted by radars. But=20 > radars have other problems on metal bridges. Assisted by lidars too,=20 > but these are too big and too latent. >=20 > That's why only message exchanges (preferentially using TCP/IP > protocols) are able to improve current systems of obstacle avoidance,=20 > lane keeping, self driving, etc. >=20 > Alex >=20 >>=20 >> The rate the image increases in size can determine the rate and=20 >> distance you are to the car in front of you. >>=20 >> Just wondering ... >>=20 >> Dino >>=20 >>> On Apr 8, 2016, at 6:45 AM, Alexandre Petrescu=20 >>> wrote: >>>=20 >>>=20 >>>=20 >>> Le 06/04/2016 21:57, Michelle Wetterwald a =C3=A9crit : >>>> Hi Alex, all, >>>>=20 >>>> Thank you for these minutes >>>>=20 >>>> I would like to rephrase here the two comments that I made during=20 >>>> the meeting to the V2I problem statement draft and could not be=20 >>>> captured in the minutes: - in the V2I case, the performance of the=20 >>>> system and the coverage time vs. vehicle speed should be taken into = >>>> account. At the contrary of the V2V C-ACC case you described where=20 >>>> both cars are moving in the same direction, which ensures some time = >>>> to exchange prefixes, names, etc., in the V2I case, the coverage=20 >>>> time with one RSU may be short. Thus this signalling should have a=20 >>>> really low latency. >>>=20 >>> I fully agree, that's the case. Dino also said things in this=20 >>> direction. >>>=20 >>>> - Secondly, the potential congestion of the system when hundreds of = >>>> cars would be located in the same area and establishing or using=20 >>>> V2I communications should also be taken into account as an issue.=20 >>>> Switching part of the traffic to a more available channel, as was=20 >>>> proposed, may not always be possible. Reducing the size of the=20 >>>> packet, however, by using header compression technique as in 6lo,=20 >>>> may offer a potential improvement. >>>=20 >>> Do you think 6lo RFC techniques are compatible with using IP in=20 >>> moving network to nearby moving or fixed network communications? >>>=20 >>> AFAIK 6lo implementations are on low-power radios (i.e. 802.15.4,=20 >>> bluetooth), and as such have very small coverage, with cells like=20 >>> 10m. Can a gar connect to it if moving at more than 10kmph? >>>=20 >>> Or is it that car uses 6lo to connect to a gas station RSU while=20 >>> filling gas? If so it's V2I. >>>=20 >>> Or is it that driver uses 6lo NFC card to open/close doors? That's=20 >>> _one_ fixed network (the car) and a Host (the NFC card) - it's not=20 >>> moving network to nearby moving or fixed network communications. >>>=20 >>> If we could frame it as moving network to nearby moving or fixed=20 >>> network communications for V2V and/or V2I, then it's in scope. >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Best regards, Michelle Wetterwald ---- Senior expert in networking=20 >>>> and telecommunications >>>>=20 >>>> 2016-04-06 19:46 GMT-03:00 Alexandre Petrescu=20 >>>> >>> >: >>>>=20 >>>> Raw meeting minutes, thanks to minute takers for efforts despite=20 >>>> echo-ey PA system. >>>>=20 >>>> Alex >>>>=20 >>>> ------------------------------------------------------------------ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 > Minutes for [its] >>>>=20 >>>> =E2=80=A2 Introduction: >>>>=20 >>>>=20 >>>> =E2=80=93 Administrative - BOF Chairs - 5 min >>>>=20 >>>>=20 >>>> =E2=80=93 ITS Goals and Success Criteria - BOF Chairs - 10 min >>>>=20 >>>>=20 >>>> =E2=80=A2 Problem Space: >>>>=20 >>>>=20 >>>> =E2=80=93 Tutorial of IP in vehicular communications - Alex = Petrescu - >>>> 20 min Randel Gelland: Since there are so many MAC & PHY, they use=20 >>>> their own messaging -- so could use IP. But vehicals are using=20 >>>> different PHY & MAC, so they can't communicate Alex: But some of=20 >>>> the radios are actually compatible >>>>=20 >>>> Bob Hinden: On "Topology" slide -- this is very simplified. There=20 >>>> will be many cars, with very dynamic interconnection Alex: Yes. >>>> Gives more examples to support contention >>>>=20 >>>> Dapeng Liu: Once connectivity is established, IP will enable better = >>>> communication. >>>>=20 >>>> Pat Thaler: Even for compatible PHY, MACs may be different, so=20 >>>> can't just day "use IP" >>>>=20 >>>> Erik Nordmark: Have people considered what the IP addressing will=20 >>>> look like? In the car, the addressing is stable, but not outside=20 >>>> the car. How does one car know the address in the other car? >>>> Alex: Yes, people are working on this. IETF can help. >>>>=20 >>>> Carlos: Are people working on the addressing sheme. >>>>=20 >>>> Dino: We have an IP mobility problem >>>>=20 >>>> Dirk Kircher: Broadcast. Semantic layer. Alex: There may be=20 >>>> multiple hops beween cars, and multiple hops in a car. May need >>>> IPv4 broadcast, or IPv6 broadcast >>>>=20 >>>> Dino: Even without the mobility problem, we still would have=20 >>>> physical layer incompatible problems. But that is exactly what IP=20 >>>> solves. >>>>=20 >>>> =E2=80=93 ITS use-cases C-ACC and Platooning - Alex Petrescu - 10 = min >>>> draft-petrescu-its-cacc-sdo-04 >>>>=20 >>>> Lou Berger: >>>> Hackable. What's the security model? Alex: Do not have slides=20 >>>> about this. Eric Rescolo: Why make any representation about=20 >>>> exceeding speedlimit. Alex: It's just an example Eric Rescolo: >>>> What if the police ask this question? >>> speed parameter> >>>>=20 >>>> Sandra: there is a lot of work being done on security =3D Safety = part >>>>=20 >>>> Eric Burdick: There are a lot of privacy issues. There is work=20 >>>> about jamming. It's not just Mobile IP. >>>>=20 >>>> Erik Nordmark: There was an IETF plenary that is relevant to=20 >>>> security. =3D Police can probaly go get the data >>>>=20 >>>> Eric Rescolo: Lots of work to be done -- prevent querying in the=20 >>>> car. >>>>=20 >>>>=20 >>>> =E2=80=93 ITS V2V problem statement - Dapeng Liu - 5 min >>>> draft-petrescu-its-problem-00 >>>>=20 >>>> Randel Gelland: How do they know when they need to discover the=20 >>>> other vehicles' address? Dirk Kircher: Sub-Problem(1) needs to be=20 >>>> characterized correctly. What is a realistic use case: >>>> Answer: C-ACC >>>>=20 >>>> ...: do you have data? Alex: How much data do you want? >>>>=20 >>>> Randel Gellens: This shows how IP is useful, but it's not why IP is = >>>> needed? So it is needed to exhibit the need, not just the use case. >>>>=20 >>>> Erik Nordmark: how identities (or even temporary identities)=20 >>>> established? >>>>=20 >>>> Hannes Tshofenig: Is there a need for another layer for identity? >>>>=20 >>>>=20 >>>> =E2=80=93 ITS V2I problem statement - Jaehoon Paul Jeong - 5 min >>>> draft-jeong-its-v2i-problem-statement-00 >>>>=20 >>>> Charlie: What does it mean to "directly" connect to the RSO's=20 >>>> network Jaehoon: Exchange prefixes >>>>=20 >>>> Woman >>>>=20 >>>> Dino: a lost packet could be a catastrophe, amidst a lot of=20 >>>> connection. Need to avoid chit-chat. Should avoid multiple=20 >>>> solutions. If security requires Diffie-Hellman, may not get to=20 >>>> finally say "BRAKE" Dino: May not be able to go get a certificate. >>>>=20 >>>> <....?>: May not have time to >>>>=20 >>>> Dirk Kircher: Question about use case... >>>>=20 >>>> Alex: Some operators already provide connection between RSUs, and=20 >>>> thus can provide handovers >>>>=20 >>>> =E2=80=A2 Discussion - 10 min >>>>=20 >>>> Aaron Falk: Good to have the discussion. Useful confusion [??}=20 >>>> Dirk Kircher: Use cases need discussion, as well as network=20 >>>> drivers. Carlos: Are you talking about requirements? Dirk: >>>> Network requirements... Erik Nordmark: Don't really grasp exactly=20 >>>> why IP is needed for single hop. Will this use the same Internet?=20 >>>> What about the timing requirements? Stan Ratliff: V2V could be=20 >>>> mobile ad hoc network? Russ: Not if it's just one hop. >>>> <...> : Want to know what cars are closing in. Could want to send=20 >>>> message just backwards. Dino: What if you *don't* have IP? A lot of = >>>> vehicles already have IP, so it is already there. IP could=20 >>>> simplify the automobile and the communications. We will want to=20 >>>> write applications. Will need to have compatible format. >>>> We will want open standards. Spencer Dawkins: Was waiting for a=20 >>>> transport question. Applications might be close to each other? >>>> About updating the car. Hannes: Applications might be running on=20 >>>> many different computers and media, but still need to communicate.=20 >>>> Pat Thaler: Updating the car is a different sort of thing than V2I. = >>>> We will have updates at the service station, so you're not moving.=20 >>>> Three concerns: security problem. Time constraints. Spencer: Need=20 >>>> to understand what the volume of data would be. Dirk: Is it, or is=20 >>>> it not, TCP? There are a couple of protocols in use today. Eric=20 >>>> Burdick: Should assume that all protocols are broken. The control=20 >>>> mechanisms could collapse with the number of cars. >>>>=20 >>>> =E2=80=93 What documents are needed to advance this work? >>>> http://itu.int/go/ITScomms is complete list of ITU work items >>>>=20 >>>> Dino: Why include trains but not planes? Alex: O.K. Erik >>>> Burdick: What about when get onto the ocean? Dirk: Some of the use=20 >>>> cases are very dissimilar. Need to pick one problem. Aaron from=20 >>>> Jabber: Can assume use of certificates. Dino: Need to look at the=20 >>>> requirements and see if there are solutions, even though there are=20 >>>> a lot of work items. Erik Nordmark: Can we figure out what is=20 >>>> needed for the immediate term? Randall Gellens: What about=20 >>>> coordination with other SDOs? For instance regarding=20 >>>> IPv6-over-foo. Alex: With a working group we can have a channel by=20 >>>> which to do the coordination Randall: We have that with ISO, 3GPP,=20 >>>> etc. >>>>=20 >>>> Closing remarks: We will publish the charter on the working group. = >>>> In about a month we will see if we have a rigorous charter. >>>>=20 >>>> _______________________________________________ its mailing list=20 >>>> its@ietf.org =20 >>>> https://www.ietf.org/mailman/listinfo/its >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- Michelle Wetterwald michelle.wetterwald@gmail.com=20 >>>> >>>=20 >>> _______________________________________________ its mailing list=20 >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Mon Apr 11 00:50:11 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056C412E751 for ; Mon, 11 Apr 2016 00:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wqb3Qf815j1q for ; Mon, 11 Apr 2016 00:50:07 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C1812E649 for ; Mon, 11 Apr 2016 00:50:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3B7o1CH021685; Mon, 11 Apr 2016 09:50:01 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 37D2C204EE8; Mon, 11 Apr 2016 09:51:17 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 25B30204EE9; Mon, 11 Apr 2016 09:51:17 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3B7o1Li030346; Mon, 11 Apr 2016 09:50:01 +0200 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Dino Farinacci'" References: <570591D1.4070904@gmail.com> <5707B616.4040706@gmail.com> <6C8F8863-552E-4190-ACEF-A3566E0F0633@gmail.com> <5707C8C1.6030106@gmail.com> <019801d193c3$ae7453a0$0b5cfae0$@eurecom.fr> From: Alexandre Petrescu Message-ID: <570B5729.8080805@gmail.com> Date: Mon, 11 Apr 2016 09:50:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <019801d193c3$ae7453a0$0b5cfae0$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: its@ietf.org, 'Michelle Wetterwald' Subject: Re: [its] WG items (was: 6lo) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 07:50:10 -0000 Jérôme, That is right. A WI (Working Group Item) should be written for each need, and according to participants' interest. Currently, there is interest in several WG items. I will reply separately to your initial email. Alex Le 11/04/2016 09:28, Jérôme Härri a écrit : > Dear ITSer, > > In the different e-mails exchanged, there seems to be always > reference to industrial products that would use IP (IPv6 I guess) in > vehicles, as an example and justification of the need for an IPv6 > solution for V2V and V2I. > > In order to give a clear overview of what the industry plans for > this, I mentioned in my previous e-mail that the IETF ITS should > create a WI, which would aim at referencing industrial products or > vision that would foresee an IETF need in ITS, and which could not be > solved by other SDOs (WAVE,...). > > As mentioned in my previous e-mail, getting a list of academic papers > is only one side of the mirror, and my itself will not justify a > WG...we need an industrial justification and support. > > Best Regards, > > Jérôme > > -----Original Message----- From: its [mailto:its-bounces@ietf.org] On > Behalf Of Dino Farinacci Sent: Friday 08 April 2016 23:33 To: > Alexandre Petrescu Cc: its@ietf.org; Michelle Wetterwald Subject: Re: > [its] 6lo > > The whole point and question is, the car, as a single unit, being > self sufficient is probably the best way to solve this v2v problem. > > Dino > >> On Apr 8, 2016, at 8:05 AM, Alexandre Petrescu >> wrote: >> >> >> >> Le 08/04/2016 11:10, Dino Farinacci a écrit : >>> I am wondering if v2v can succeed better with no data-oriented >>> commmunication (IP protocols get in the say and actually slow >>> down reaction time). Maybe the front facing camera alone provides >>> enough information to the computing elements in the following >>> car >> >> It would be wonderful if it were possible that the front camera of >> a truck wirelesly sends data to rear vehicles. But that's not >> possible because the truck frame in between is blocking these >> waves. >> >> That's why people plug the camera (some times IP-enabled) to an IP >> router in the truck which has additional IP interface (11p) >> towards the car behind. >> >> The car behind sends IP service discovery requests, and then >> receives an IP stream of video which shows what the truck sees. >> >> But beware human behaviour: analysts say that driver is too >> distracted by the realism of the image streamed by the truck - s/he >> believes being _in_ the truck and hits it. >> >> (multiple demonstrators exhibit this; the Samsung Safety Truck is >> shown just because we're in Argentina and it made much publicity). >> >>> to detect when its getting close to the car it is following. >> >> Yes, many cars on the market today analyse the image of the front >> and make multiple decisions to avoid hitting cars, pedestrians, >> keep lane, and so on. >> >> But that's an image processing problem, not communication problem. >> >> The problems of the webcams in reocnizing obstacles is that they >> may issue false positives. That's why they're assisted by radars. >> But radars have other problems on metal bridges. Assisted by >> lidars too, but these are too big and too latent. >> >> That's why only message exchanges (preferentially using TCP/IP >> protocols) are able to improve current systems of obstacle >> avoidance, lane keeping, self driving, etc. >> >> Alex >> >>> >>> The rate the image increases in size can determine the rate and >>> distance you are to the car in front of you. >>> >>> Just wondering ... >>> >>> Dino >>> >>>> On Apr 8, 2016, at 6:45 AM, Alexandre Petrescu >>>> wrote: >>>> >>>> >>>> >>>> Le 06/04/2016 21:57, Michelle Wetterwald a écrit : >>>>> Hi Alex, all, >>>>> >>>>> Thank you for these minutes >>>>> >>>>> I would like to rephrase here the two comments that I made >>>>> during the meeting to the V2I problem statement draft and >>>>> could not be captured in the minutes: - in the V2I case, the >>>>> performance of the system and the coverage time vs. vehicle >>>>> speed should be taken into account. At the contrary of the >>>>> V2V C-ACC case you described where both cars are moving in >>>>> the same direction, which ensures some time to exchange >>>>> prefixes, names, etc., in the V2I case, the coverage time >>>>> with one RSU may be short. Thus this signalling should have >>>>> a really low latency. >>>> >>>> I fully agree, that's the case. Dino also said things in this >>>> direction. >>>> >>>>> - Secondly, the potential congestion of the system when >>>>> hundreds of cars would be located in the same area and >>>>> establishing or using V2I communications should also be taken >>>>> into account as an issue. Switching part of the traffic to a >>>>> more available channel, as was proposed, may not always be >>>>> possible. Reducing the size of the packet, however, by using >>>>> header compression technique as in 6lo, may offer a potential >>>>> improvement. >>>> >>>> Do you think 6lo RFC techniques are compatible with using IP >>>> in moving network to nearby moving or fixed network >>>> communications? >>>> >>>> AFAIK 6lo implementations are on low-power radios (i.e. >>>> 802.15.4, bluetooth), and as such have very small coverage, >>>> with cells like 10m. Can a gar connect to it if moving at more >>>> than 10kmph? >>>> >>>> Or is it that car uses 6lo to connect to a gas station RSU >>>> while filling gas? If so it's V2I. >>>> >>>> Or is it that driver uses 6lo NFC card to open/close doors? >>>> That's _one_ fixed network (the car) and a Host (the NFC card) >>>> - it's not moving network to nearby moving or fixed network >>>> communications. >>>> >>>> If we could frame it as moving network to nearby moving or >>>> fixed network communications for V2V and/or V2I, then it's in >>>> scope. >>>> >>>> Alex >>>> >>>>> >>>>> Best regards, Michelle Wetterwald ---- Senior expert in >>>>> networking and telecommunications >>>>> >>>>> 2016-04-06 19:46 GMT-03:00 Alexandre Petrescu >>>>> >>>> >: >>>>> >>>>> Raw meeting minutes, thanks to minute takers for efforts >>>>> despite echo-ey PA system. >>>>> >>>>> Alex >>>>> >>>>> ------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >> >>>>> Minutes for [its] >>>>> >>>>> • Introduction: >>>>> >>>>> >>>>> – Administrative - BOF Chairs - 5 min >>>>> >>>>> >>>>> – ITS Goals and Success Criteria - BOF Chairs - 10 min >>>>> >>>>> >>>>> • Problem Space: >>>>> >>>>> >>>>> – Tutorial of IP in vehicular communications - Alex Petrescu >>>>> - 20 min Randel Gelland: Since there are so many MAC & PHY, >>>>> they use their own messaging -- so could use IP. But >>>>> vehicals are using different PHY & MAC, so they can't >>>>> communicate Alex: But some of the radios are actually >>>>> compatible >>>>> >>>>> Bob Hinden: On "Topology" slide -- this is very simplified. >>>>> There will be many cars, with very dynamic interconnection >>>>> Alex: Yes. Gives more examples to support contention >>>>> >>>>> Dapeng Liu: Once connectivity is established, IP will enable >>>>> better communication. >>>>> >>>>> Pat Thaler: Even for compatible PHY, MACs may be different, >>>>> so can't just day "use IP" >>>>> >>>>> Erik Nordmark: Have people considered what the IP addressing >>>>> will look like? In the car, the addressing is stable, but not >>>>> outside the car. How does one car know the address in the >>>>> other car? Alex: Yes, people are working on this. IETF can >>>>> help. >>>>> >>>>> Carlos: Are people working on the addressing sheme. >>>>> >>>>> Dino: We have an IP mobility problem >>>>> >>>>> Dirk Kircher: Broadcast. Semantic layer. Alex: There may be >>>>> multiple hops beween cars, and multiple hops in a car. May >>>>> need IPv4 broadcast, or IPv6 broadcast >>>>> >>>>> Dino: Even without the mobility problem, we still would have >>>>> physical layer incompatible problems. But that is exactly >>>>> what IP solves. >>>>> >>>>> – ITS use-cases C-ACC and Platooning - Alex Petrescu - 10 >>>>> min draft-petrescu-its-cacc-sdo-04 >>>>> >>>>> Lou Berger: >>>>> Hackable. What's the security model? Alex: Do not have >>>>> slides about this. Eric Rescolo: Why make any representation >>>>> about exceeding speedlimit. Alex: It's just an example Eric >>>>> Rescolo: What if the police ask this question? >>>> floor - add speed parameter> >>>>> >>>>> Sandra: there is a lot of work being done on security = >>>>> Safety part >>>>> >>>>> Eric Burdick: There are a lot of privacy issues. There is >>>>> work about jamming. It's not just Mobile IP. >>>>> >>>>> Erik Nordmark: There was an IETF plenary that is relevant to >>>>> security. = Police can probaly go get the data >>>>> >>>>> Eric Rescolo: Lots of work to be done -- prevent querying in >>>>> the car. >>>>> >>>>> >>>>> – ITS V2V problem statement - Dapeng Liu - 5 min >>>>> draft-petrescu-its-problem-00 >>>>> >>>>> Randel Gelland: How do they know when they need to discover >>>>> the other vehicles' address? Dirk Kircher: Sub-Problem(1) >>>>> needs to be characterized correctly. What is a realistic use >>>>> case: Answer: C-ACC >>>>> >>>>> ...: do you have data? Alex: How much data do you want? >>>>> >>>>> Randel Gellens: This shows how IP is useful, but it's not why >>>>> IP is needed? So it is needed to exhibit the need, not just >>>>> the use case. >>>>> >>>>> Erik Nordmark: how identities (or even temporary identities) >>>>> established? >>>>> >>>>> Hannes Tshofenig: Is there a need for another layer for >>>>> identity? >>>>> >>>>> >>>>> – ITS V2I problem statement - Jaehoon Paul Jeong - 5 min >>>>> draft-jeong-its-v2i-problem-statement-00 >>>>> >>>>> Charlie: What does it mean to "directly" connect to the >>>>> RSO's network Jaehoon: Exchange prefixes >>>>> >>>>> Woman >>>>> >>>>> Dino: a lost packet could be a catastrophe, amidst a lot of >>>>> connection. Need to avoid chit-chat. Should avoid multiple >>>>> solutions. If security requires Diffie-Hellman, may not get >>>>> to finally say "BRAKE" Dino: May not be able to go get a >>>>> certificate. >>>>> >>>>> <....?>: May not have time to >>>>> >>>>> Dirk Kircher: Question about use case... >>>>> >>>>> Alex: Some operators already provide connection between RSUs, >>>>> and thus can provide handovers >>>>> >>>>> • Discussion - 10 min >>>>> >>>>> Aaron Falk: Good to have the discussion. Useful confusion >>>>> [??} Dirk Kircher: Use cases need discussion, as well as >>>>> network drivers. Carlos: Are you talking about requirements? >>>>> Dirk: Network requirements... Erik Nordmark: Don't really >>>>> grasp exactly why IP is needed for single hop. Will this use >>>>> the same Internet? What about the timing requirements? Stan >>>>> Ratliff: V2V could be mobile ad hoc network? Russ: Not if >>>>> it's just one hop. <...> : Want to know what cars are closing >>>>> in. Could want to send message just backwards. Dino: What if >>>>> you *don't* have IP? A lot of vehicles already have IP, so it >>>>> is already there. IP could simplify the automobile and the >>>>> communications. We will want to write applications. Will >>>>> need to have compatible format. We will want open standards. >>>>> Spencer Dawkins: Was waiting for a transport question. >>>>> Applications might be close to each other? About updating the >>>>> car. Hannes: Applications might be running on many different >>>>> computers and media, but still need to communicate. Pat >>>>> Thaler: Updating the car is a different sort of thing than >>>>> V2I. We will have updates at the service station, so you're >>>>> not moving. Three concerns: security problem. Time >>>>> constraints. Spencer: Need to understand what the volume of >>>>> data would be. Dirk: Is it, or is it not, TCP? There are a >>>>> couple of protocols in use today. Eric Burdick: Should assume >>>>> that all protocols are broken. The control mechanisms could >>>>> collapse with the number of cars. >>>>> >>>>> – What documents are needed to advance this work? >>>>> http://itu.int/go/ITScomms is complete list of ITU work >>>>> items >>>>> >>>>> Dino: Why include trains but not planes? Alex: O.K. Erik >>>>> Burdick: What about when get onto the ocean? Dirk: Some of >>>>> the use cases are very dissimilar. Need to pick one problem. >>>>> Aaron from Jabber: Can assume use of certificates. Dino: Need >>>>> to look at the requirements and see if there are solutions, >>>>> even though there are a lot of work items. Erik Nordmark: Can >>>>> we figure out what is needed for the immediate term? Randall >>>>> Gellens: What about coordination with other SDOs? For >>>>> instance regarding IPv6-over-foo. Alex: With a working group >>>>> we can have a channel by which to do the coordination >>>>> Randall: We have that with ISO, 3GPP, etc. >>>>> >>>>> Closing remarks: We will publish the charter on the working >>>>> group. In about a month we will see if we have a rigorous >>>>> charter. >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> >>>>> >>>>> -- Michelle Wetterwald michelle.wetterwald@gmail.com >>>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Mon Apr 11 00:51:41 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D7A12E106 for ; Mon, 11 Apr 2016 00:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqscglTF5RCn for ; Mon, 11 Apr 2016 00:51:38 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id 060A712DC6A for ; Mon, 11 Apr 2016 00:51:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,462,1454972400"; d="scan'208";a="3608431" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 11 Apr 2016 09:51:37 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 3A151C5C; Mon, 11 Apr 2016 09:51:37 +0200 (CEST) From: =?iso-8859-1?B?Suly9G1lIEjkcnJp?= To: "'Alexandre Petrescu'" , References: <201604080903146552249@cnnic.cn> <5707BA2E.2080902@gmail.com> In-Reply-To: <5707BA2E.2080902@gmail.com> Date: Mon, 11 Apr 2016 09:51:37 +0200 Organization: EURECOM Message-ID: <01a001d193c6$f9aeb880$ed0c2980$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJQXMJgm2h//0Q9lyIcl4XwCGdMLQFgfraNnnvKfgA= Content-Language: en-us Archived-At: Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 07:51:41 -0000 Dear ITSers, I would not focus to MIP (only or even at all) for handling IPv6 connectivity for moving vehicles before having *clearly* defined the = type of link and data traffic model that will be used by connected cars.=20 For example, if we assume pure MIP, it represents a good strategy if you want to keep an IP connectivity 'open' while the car moves...and this, regarding if and how many 'bits' are actually transmitted. So, = considering what we have 'today' as data model for connected cars, it is more = related to M2M-type of traffic (small packets, sensor-type update)..so, using MIP = for this would cost a lot in overhead for very small benefit in terms of = data. The challenge here would indeed be to improve the RO and reduce the overhead...but is it really required?? On the other side, DMM-type MIP will not keep a link open if not used = and will only handle IPv6 mobility for active links. That would imply that = the M2M-type of traffic will not have an IPv6 mobility management, but quick IPv6 link establishment when M2M traffic is required to be transmitted. Here, the challenge is related to quick prefix/DHCP and DNS handling = when under coverage and while M2M data is to be transmitted (possibly with = one handover in between). This sounds more what we will have...and maybe = more urgent to address than handling mobility. And you could also consider that PMIP-type of mobility management be = more adapted to connected vehicles, as it could natively 'hide' mobility to = the applications... Now, if we have more 'stream-like' communication, how long is such link active? How many 'handovers' could be required to handle this IPv6 link (under typical mobility and considering small or medium cells) ?=20 My point is we should not putting the cart before the horse, and first define what we understand as an IPv6 'link' in a vehicular context, as = well as defining what would be the typical traffic models that will be = there...(I know that IETF would like to be agnostic to a type of traffic model, but that might not be possible in a vehicular context..).=20 Then only we can look at the gaps between currently existing IPv6 technologies... Best Regards, J=E9r=F4me -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Friday 08 April 2016 16:03 To: its@ietf.org Subject: Re: [its] charter ITS Le 07/04/2016 22:03, Z.W. Yan a =E9crit : > Hi, All, About the charter, I think we should also consider and=20 > describe the NEMO and nested-NEMO scenarios and protocols. > Otherwise, it just falls back to the application of plain MIP/PMIP no=20 > matter in the V2V case or V2I case. Zhiwei Yan, I disagree with you saying it's just a plain MIP. There is currently a 'gap analysis' part, section 14.2 'Mobile IP': https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-04#page-15 For Mobile IP: - currently a car can't send a BU to another car if the HA is absent (out of LTE coverage). That's an old Route Optimization problem in MIP. Do you agree with this gap? And, to be more clear, this should _not_ lead to developping extensions = of Mobile IP to solve this V2V case, because there are other bigger = problems I can describe separately. One of these relates to security. Alex > > BR, Zhiwei Yan 2016-04-08 > ---------------------------------------------------------------------- > -- > > > Z.W. Yan > > > _______________________________________________ its mailing list=20 > its@ietf.org https://www.ietf.org/mailman/listinfo/its > _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Mon Apr 11 01:14:32 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7475A12E881 for ; Mon, 11 Apr 2016 01:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Md-gnGlxpw9 for ; Mon, 11 Apr 2016 01:14:27 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09AE12E87F for ; Mon, 11 Apr 2016 01:14:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3B8EOD0013338; Mon, 11 Apr 2016 10:14:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2E43C2008F4; Mon, 11 Apr 2016 10:15:40 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 20BA120143A; Mon, 11 Apr 2016 10:15:40 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3B8EO4J002947; Mon, 11 Apr 2016 10:14:24 +0200 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> From: Alexandre Petrescu Message-ID: <570B5CE0.7090805@gmail.com> Date: Mon, 11 Apr 2016 10:14:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <009301d19059$96917820$c3b46860$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: its@ietf.org Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 08:14:30 -0000 Jérôme, Le 07/04/2016 01:11, Jérôme Härri a écrit : > Dear ITSers, Dear Alex, > > Here are some comments on the updated charter: > > 1)Can we keep a reference to IEEE 802.11p, considering it does not > exist anymore? It is now fully integrated into IEEE 802.11-2012 as > OCB mode (and 10Mhz @5.9Ghz) of course. The question is relevant. Let's use "802.11-OCB" instead of "802.11p" everywhere. Do you agree? > 2)Should we really keep C-ACC (or Platooning) in the charter > explicitly as use case, considering it is a seriously controversial > aspect with some SDOs (ex. In Automotive SDOs)? In the ISO > presentation, Thierry mentions traffic efficiency/infotainment > applications, such as in-signage applications... C-ACC and Platooning are use-cases exhibiting the need for V2V. There are more use-cases needing V2V: e.g. "V2V emergency vehicle warning", "V2V emergency stop use cases" documented at 3GPP. I dont think it's worth documenting all of them, because their salient V2V characteristics are all exhibited by only one. For Thierry's note: I think you mean "In-Vehicle Signage (IVS)" case study (slide 14 of "ISO TC204 needs" at https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf ) If yes, that is a typical V2I use-case. Maybe, "I2V" - Infrastructure to Vehicle communications. It follows the same moving network to nearby moving or fixed network paradigm: more precisely expressed as: fixed network to nearby moving network communications. > a.We might have to aim at less controversial use cases to attract > automotive industries Which one use-case would you think of? Does it follow the paradigm of moving network to nearby moving or fixed network communications? > 3)One potential WI I could think of (rather a basic one): _definition > of a vehicular wireless ‘link’ in an automotive context_ > > a.To me, this is a fundamental brick in the larger IETF WG ITS > house.. I think that is right. There seems to be interest in precisely defining what that 'link' is in an automotive context. This interest was illustrated by the IPv6 over 802.11-OCB discussion. Such a link is used in V2V and V2I and I2V. We should work on this, but within certain conditions: (1) we should not create new link characteristics, but describe the existing ones, (2) we should describe how the link layer is interfaced with the IP layer. The title of such a WG item should be "IPv6 over foo". That said, how do you see the work on a potential WI talking about the definition of a vehicular wireless link in an automotive context? > > 4)I would suggest to be more explicit in the foreseen challenges of > this WG, instead of mentioning general use case (which end up be > controversial) > > a.Example: maintaining IPv6 connectivity in fast and asymmetric > wireless links; also under quickly changing topologies (actually > suggested by Dick Roy on the chat room) Yes, that's a long-term challenge: maintaining IPv6 connectivity in fast and asymmetric wireless links, and under quivkly changing topologies. The near term objective is: moving network to nearby moving or fixed network communications. > > b.Example: IPv6 addressing in link-local scope.. I agree. Erik also said something about potential work on an addressing architecture for the V2V topology. Do you think there is enough interest in IPv6 addressing architecture for the V2V topology such as to propose a WG item for it? > c.Example: guaranteeing privacy in IPv6 moving networks etc.. I agree. For this there is ongoing discussion with people inclined on security work. > > 5)Before listing academic papers referring to IPv6 in vehicles, I > would suggest to first try to list commercial products/solutions that > are in vehicles and are using IPv6, possibly suffering from a silo > limitations (ex. restricted to a single technology, single use > case…) Sounds relevant. But too many separate items? How about _one_ item with two sections: section with list of papers, and section with list of commercial products. > a.I think we need to get to products first, before academic visions It's debatable. How about answering first the above question, and then we'll see. Alex > > My two cents.. > > Best Regards, > > Jérôme > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre > Petrescu *Sent:* Wednesday 06 April 2016 23:45 *To:* its@ietf.org > *Subject:* [its] charter ITS > > ITSers, > > Please see below the current charter. > > - the two Problem Statements drafts V2V and V2I joined, so there is > less text in charter. - added an Item on "List of Research > papers..." > > Erik: did I understand you correctly that there should be some item > on discussing whether link-local addressing is sufficient, whether > prefix exchange is necessary? > > Dino: should LISP be included in the gap analysis draft which > includes C-ACC use-case? OR should we separate a dedicated I-D only > with gap analysis including ND, MIP, AODVv2, LISP? > > Person from mediatek: is the 'zeroconf' need in the > vehicle-to-vehicle interface illustrated good enough by the words > "moving network to nearby moving network communications"? Or is it > better to say "the 1-IP-hop between nearby moving networks must be > self-configured"? > > Nabil, Sandra: is it ok to have a working group item "List of > Research Papers for IP in V2V and V2I communications"? > > Other comments? > > Alex > > ------------------------------------------------------------------ > > ITS (name to change) Charter April 6th, 2016 > http://ietf.org/mailman/listinfo/its > > > Intelligent Transportation Systems (its) > ---------------------------------------- Current Status: WG forming > > Chairs: TBD > > Assigned Area Director: TBD > > Mailing list Address: its@ietf.org 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: > > Goal ---- The goal of this group is to standardize IP-based protocols > for establishing direct and secure connectivity between moving > networks, some of which could be fixed permanently or temporarily. > > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ The group is > concerned with all situations involving moving network to nearby > moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in > a train, or train-to-intersection signalling. > > Example from the automobile communications space > ------------------------------------------------ Automobiles and > vehicles of all types are increasingly connected to the Internet, > either as vehicle-to-vehicle, vehicle-to-infra or > vehicle-to-Internet. Entertainment apps enhancing comfort, reliable > data exchanges for road safety, and automated driving are features > coming in automobiles to hit the roads from now to year 2020. > Highlighting increased safety as an immediate result of > hyper-connectivity applied to vehicles, public authorities worldwide > are increasingly mandating secure communication technology > requirements in vehicles. > > Emergency apps for new instrumented ambulances carry many benefits > both to the users and to society in general. > > Why IP? ------- Today, there are several deployed Vehicle-to-Internet > technologies, including car tethering through driver's cellular > smartphone. However, Vehicle-to-Vehicle and > Vehicle-to-Infrastructure communications are still being developed. > To improve on a situation of link-specific data exchanges, and enable > independent application sets to share the same links, IP data > exchanges are needed. Enabling IP communication between vehicles > (V2V), and between vehicles and the immediate infrastructure (V2I), > will provide (0) ability to reach the rest of the world on the > Internet (1) short and deterministic delays, (2) fast forwarding > through scalable paths of routers, (3) ease of reuse of existing > Internet applications in a vehicular environment. > > Moving network to nearby moving network communications involve link > layers such as: 802.11p OCB (Outside the Context of a Basic Service > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light > Communications), IrDA, LTE-D. Only the IP protocols are capable of > running on each of these links and establish IP paths across them in > an interoperable manner. > > Scenarios? ---------- There are a few scenarios exhibiting the need > to communicate from one moving network to another nearby moving > network. > > In the automobile space, the Cooperative Adaptive Cruise Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the > cross-roads, the moving network inside a vehicle exchanges data with > the moving network in the red-light pole. > > Several public safety scenarios involve moving networks. Distinct > organizations deploy different moving networks (in-vehicle, > on-person) at an incident scene. These networks need to interoperate > in order to more effectively understand and deal with the incident > scene. > > In connected rail scenarios the moving network deployed in trains > communicate with other moving networks at the cross-points. > > What kind of solutions? ----------------------- The current technical > solutions considered to achieve moving network to nearby moving > network communications are of two kinds: IP routing protocols for > n-hop path management and 1-hop link-scoped IP protocol enhancements. > The 1-hop link-scoped protocols include the protocols for route > establishment involving ICMP Router Advertisements. The n-hop path > management protocols include n-hop path establishment protocols (e.g. > Babel, OSPF) and n-hop path search protocols (most notably AODV and > derivates). > > In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations. > > In some of the moving network applications the window of opportunity > for exchanging data with the immediate infrastructure may be very > short. For example, a car driving near a road-side unit may have > only 5s to exchange with that RSU (depending on speed, RSU range and > number). (ephemeral connections). > > What kind of requirements? -------------------------- The > requirements for mechanisms for moving network to nearby moving > network communications are focusing on low delays of the data paths, > reduced number of messages for path establishment, application > friendly, resilience to attacks, compatibility with DHCP and Mobile > IP. > > In addition, some moving network to nearby moving network > applications involve IP multicast mechanisms (e.g. virtual siren); > thus C-ACC the 1-hop IP moving network to nearby moving netowrk > mechanisms will need to gracefully support IP multicast. > > Due to the inherent characteristics of safety-related > communications, all new moving network to nearby moving network > mechanisms must afford authenticity and confidentiality where > necessary. Dynamically establishing ephemeral communication paths > between automobiles in public areas must offer privacy safeguards for > the end users (passengers). > > Establishing 1-hop IP V2V paths must not break the existing on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. > > In a moving network deployed in an automobile, typically one exit > point connects the moving network to other moving networks. > However, in a more general manner (and to support reliability) any > new mechanism of moving network to nearby moving network > communications should support multi-homing: one router to use > multiple interfaces towards outside the moving network, or multiple > routers. > > Current version of Internet protocols > ------------------------------------- The group will only work on > IPv6 solutions. > > What SDOs may need this work? ----------------------------- The > requirements and standards for moving network to nearby moving > network communications, often involving IPv6, and novel V2V and > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For > Vehicle-to-Internet communications, 3GPP LTE and other cellular > technologies represent the long-range connectivity method; for > Vehicle-to-Vehicle communications, LTE Direct is currently > specified, as well as OCB mode of IEEE 802.11. Several use-cases > exhibit a need for IPv6 data exchanges between vehicles: ETSI's > Cooperative Adaptive Cruise Control and Platooning. The IEEE > developed a popular link for short-range communications - IEEE > 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V > communications. > > Work Items ---------- - use-cases for moving network to nearby moving > network communications - Problem Statement for moving network to > nearby moving network communications including V2V, V2I and DNS. - > Security and Privacy Requirements for moving network to nearby moving > network communications - Solutions, which might include new protocols > or extensions to existing protocols. With MIB. - IPv6-over foo, > where foo is pertinent for moving network to nearby moving network > communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) - List of > Research Papers in the V2V domain, identifying which uses IP. > > Timeline -------- - > From nobody Mon Apr 11 01:47:58 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D8F12E979 for ; Mon, 11 Apr 2016 01:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_DR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDjJXkiYbK8a for ; Mon, 11 Apr 2016 01:47:52 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D6312E978 for ; Mon, 11 Apr 2016 01:47:52 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id g184so146946930lfb.3 for ; Mon, 11 Apr 2016 01:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=cLW1iONWhI61ZSYXxAb+qIPc42GcmQZ+c7mpbx0fQuU=; b=TK4mUl04JdRBBY7Y8e6mdGOlOFihlAiLA02mnkUsZ7TNn5hGYQpeSHFQmw6sZQPnmq Pnhl/AfIfow5yiJDT3AMyNidiALz+zcmcDJNcjEPOeXwdxKMGB6Dx0aBX7kzGGPk643G nE6F1P/QW9cgfCNnCwJuCp1ndJyiPGkBDxuk8qfivNnyFlA7BehReqItykOZ8Tx/cDRS JeUwPihwDUtE05pXw9X2ZwOHHop8xnnMpz8phXV6lW4pz4ak9ZGjBjMB317Ul49slXFc Dm/NmF8GIkpWGwD/VyqU1l8sSFw5Sy69MBheD52GLDTHvuLCqULUJG9NRkUm8q8/R/Jy NS0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=cLW1iONWhI61ZSYXxAb+qIPc42GcmQZ+c7mpbx0fQuU=; b=gmMIiYso7mR7fqiKUYRLwaZx4T1pFHJ9KFmg82O8hAthEGxr0/cUaRrRc+opgNDxv6 ErflrgBuFWBpIXb7VYJFin7MSNzMO7MyyWMoQ9AArnP/+edPzuvJ5fNBQUgCd1LCtNc9 NAKBrWKr612NDOSJvqRS2h534KYmlmI+LSEEUulniwCdPepfDoZDLp3wGuXoIKmx84ql x67qjnGNlq6m67khmHVv0OyWCk3Jf3qfwp5+oCOFqVJBqMpYAH1H6CUg/rLDDpeZSJni QfXo8Crw9v+pKbJZkl7ru6q2Q8wnkXjw+KdOYyPqyrfR9LZ7DONHF7vP/npYs+lJlgUv p+Ew== X-Gm-Message-State: AOPr4FUwjEeqINnzwJTm5/xeppvlFJ16fateD/+nyttkgBXt42Ef0PGmBnksxQ/JMOkg/3mddXdWL7tYovyIUA== MIME-Version: 1.0 X-Received: by 10.25.152.147 with SMTP id a141mr3351129lfe.83.1460364469925; Mon, 11 Apr 2016 01:47:49 -0700 (PDT) Received: by 10.25.82.69 with HTTP; Mon, 11 Apr 2016 01:47:49 -0700 (PDT) In-Reply-To: <570B5CE0.7090805@gmail.com> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <570B5CE0.7090805@gmail.com> Date: Mon, 11 Apr 2016 14:17:49 +0530 Message-ID: From: "Dr. Karan Verma" To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a11401c9e78fe4c05303199d6 Archived-At: Cc: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , its@ietf.org Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 08:47:55 -0000 --001a11401c9e78fe4c05303199d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Everyone, I also contribution for a list of papers for IP-based V2V and V2I, still i'm writing final revive comments. I will as send as soon as possible. Thank You On Mon, Apr 11, 2016 at 1:44 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > J=C3=A9r=C3=B4me, > > Le 07/04/2016 01:11, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : > >> Dear ITSers, Dear Alex, >> >> Here are some comments on the updated charter: >> >> 1)Can we keep a reference to IEEE 802.11p, considering it does not >> exist anymore? It is now fully integrated into IEEE 802.11-2012 as >> OCB mode (and 10Mhz @5.9Ghz) of course. >> > > The question is relevant. > > Let's use "802.11-OCB" instead of "802.11p" everywhere. Do you agree? > > 2)Should we really keep C-ACC (or Platooning) in the charter >> explicitly as use case, considering it is a seriously controversial >> aspect with some SDOs (ex. In Automotive SDOs)? In the ISO >> presentation, Thierry mentions traffic efficiency/infotainment >> applications, such as in-signage applications... >> > > C-ACC and Platooning are use-cases exhibiting the need for V2V. There > are more use-cases needing V2V: e.g. "V2V emergency vehicle warning", > "V2V emergency stop use cases" documented at 3GPP. I dont think it's > worth documenting all of them, because their salient V2V characteristics > are all exhibited by only one. > > For Thierry's note: I think you mean "In-Vehicle Signage (IVS)" case > study (slide 14 of "ISO TC204 needs" at > https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf ) > > If yes, that is a typical V2I use-case. Maybe, "I2V" - Infrastructure > to Vehicle communications. It follows the same moving network to nearby > moving or fixed network paradigm: more precisely expressed as: fixed > network to nearby moving network communications. > > a.We might have to aim at less controversial use cases to attract >> automotive industries >> > > Which one use-case would you think of? > > Does it follow the paradigm of moving network to nearby moving or fixed > network communications? > > 3)One potential WI I could think of (rather a basic one): _definition >> of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive context_ >> >> a.To me, this is a fundamental brick in the larger IETF WG ITS >> house.. >> > > I think that is right. > > There seems to be interest in precisely defining what that 'link' is in > an automotive context. > > This interest was illustrated by the IPv6 over 802.11-OCB discussion. > > Such a link is used in V2V and V2I and I2V. > > We should work on this, but within certain conditions: (1) we should not > create new link characteristics, but describe the existing ones, (2) we > should describe how the link layer is interfaced with the IP layer. > > The title of such a WG item should be "IPv6 over foo". > > That said, how do you see the work on a potential WI talking about the > definition of a vehicular wireless link in an automotive context? > > >> 4)I would suggest to be more explicit in the foreseen challenges of >> this WG, instead of mentioning general use case (which end up be >> controversial) >> >> a.Example: maintaining IPv6 connectivity in fast and asymmetric >> wireless links; also under quickly changing topologies (actually >> suggested by Dick Roy on the chat room) >> > > Yes, that's a long-term challenge: maintaining IPv6 connectivity in fast > and asymmetric wireless links, and under quivkly changing topologies. > > The near term objective is: moving network to nearby moving or fixed > network communications. > > >> b.Example: IPv6 addressing in link-local scope.. >> > > I agree. Erik also said something about potential work on an addressing > architecture for the V2V topology. > > Do you think there is enough interest in IPv6 addressing architecture > for the V2V topology such as to propose a WG item for it? > > c.Example: guaranteeing privacy in IPv6 moving networks etc.. >> > > I agree. For this there is ongoing discussion with people inclined on > security work. > > >> 5)Before listing academic papers referring to IPv6 in vehicles, I >> would suggest to first try to list commercial products/solutions that >> are in vehicles and are using IPv6, possibly suffering from a silo >> limitations (ex. restricted to a single technology, single use >> case=E2=80=A6) >> > > Sounds relevant. But too many separate items? > > How about _one_ item with two sections: section with list of papers, and > section with list of commercial products. > > a.I think we need to get to products first, before academic visions >> > > It's debatable. How about answering first the above question, and then > we'll see. > > Alex > > >> My two cents.. >> >> Best Regards, >> >> J=C3=A9r=C3=B4me >> >> *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre >> Petrescu *Sent:* Wednesday 06 April 2016 23:45 *To:* its@ietf.org >> *Subject:* [its] charter ITS >> >> >> ITSers, >> >> Please see below the current charter. >> >> - the two Problem Statements drafts V2V and V2I joined, so there is >> less text in charter. - added an Item on "List of Research >> papers..." >> >> Erik: did I understand you correctly that there should be some item >> on discussing whether link-local addressing is sufficient, whether >> prefix exchange is necessary? >> >> Dino: should LISP be included in the gap analysis draft which >> includes C-ACC use-case? OR should we separate a dedicated I-D only >> with gap analysis including ND, MIP, AODVv2, LISP? >> >> Person from mediatek: is the 'zeroconf' need in the >> vehicle-to-vehicle interface illustrated good enough by the words >> "moving network to nearby moving network communications"? Or is it >> better to say "the 1-IP-hop between nearby moving networks must be >> self-configured"? >> >> Nabil, Sandra: is it ok to have a working group item "List of >> Research Papers for IP in V2V and V2I communications"? >> >> Other comments? >> >> Alex >> >> ------------------------------------------------------------------ >> >> ITS (name to change) Charter April 6th, 2016 >> http://ietf.org/mailman/listinfo/its >> >> >> Intelligent Transportation Systems (its) >> ---------------------------------------- Current Status: WG forming >> >> Chairs: TBD >> >> Assigned Area Director: TBD >> >> Mailing list Address: its@ietf.org 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: >> >> Goal ---- The goal of this group is to standardize IP-based protocols >> for establishing direct and secure connectivity between moving >> networks, some of which could be fixed permanently or temporarily. >> >> Moving Network to Nearby Moving Network Communications >> ------------------------------------------------------ The group is >> concerned with all situations involving moving network to nearby >> moving network communications. For example: vehicle-to-vehicle >> communications, nomadic user wearing a PAN and communicating to a >> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in >> a train, or train-to-intersection signalling. >> >> Example from the automobile communications space >> ------------------------------------------------ Automobiles and >> vehicles of all types are increasingly connected to the Internet, >> either as vehicle-to-vehicle, vehicle-to-infra or >> vehicle-to-Internet. Entertainment apps enhancing comfort, reliable >> data exchanges for road safety, and automated driving are features >> coming in automobiles to hit the roads from now to year 2020. >> Highlighting increased safety as an immediate result of >> hyper-connectivity applied to vehicles, public authorities worldwide >> are increasingly mandating secure communication technology >> requirements in vehicles. >> >> Emergency apps for new instrumented ambulances carry many benefits >> both to the users and to society in general. >> >> Why IP? ------- Today, there are several deployed Vehicle-to-Internet >> technologies, including car tethering through driver's cellular >> smartphone. However, Vehicle-to-Vehicle and >> Vehicle-to-Infrastructure communications are still being developed. >> To improve on a situation of link-specific data exchanges, and enable >> independent application sets to share the same links, IP data >> exchanges are needed. Enabling IP communication between vehicles >> (V2V), and between vehicles and the immediate infrastructure (V2I), >> will provide (0) ability to reach the rest of the world on the >> Internet (1) short and deterministic delays, (2) fast forwarding >> through scalable paths of routers, (3) ease of reuse of existing >> Internet applications in a vehicular environment. >> >> Moving network to nearby moving network communications involve link >> layers such as: 802.11p OCB (Outside the Context of a Basic Service >> Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light >> Communications), IrDA, LTE-D. Only the IP protocols are capable of >> running on each of these links and establish IP paths across them in >> an interoperable manner. >> >> Scenarios? ---------- There are a few scenarios exhibiting the need >> to communicate from one moving network to another nearby moving >> network. >> >> In the automobile space, the Cooperative Adaptive Cruise Control and >> Platooning features consider that vehicles close to each other >> exchange data describing their kinematic status. At the >> cross-roads, the moving network inside a vehicle exchanges data with >> the moving network in the red-light pole. >> >> Several public safety scenarios involve moving networks. Distinct >> organizations deploy different moving networks (in-vehicle, >> on-person) at an incident scene. These networks need to interoperate >> in order to more effectively understand and deal with the incident >> scene. >> >> In connected rail scenarios the moving network deployed in trains >> communicate with other moving networks at the cross-points. >> >> What kind of solutions? ----------------------- The current technical >> solutions considered to achieve moving network to nearby moving >> network communications are of two kinds: IP routing protocols for >> n-hop path management and 1-hop link-scoped IP protocol enhancements. >> The 1-hop link-scoped protocols include the protocols for route >> establishment involving ICMP Router Advertisements. The n-hop path >> management protocols include n-hop path establishment protocols (e.g. >> Babel, OSPF) and n-hop path search protocols (most notably AODV and >> derivates). >> >> In this proposed Working Group the focus is on 1-hop protocols, and >> leverage from other Working Groups for the n-hop situations. >> >> In some of the moving network applications the window of opportunity >> for exchanging data with the immediate infrastructure may be very >> short. For example, a car driving near a road-side unit may have >> only 5s to exchange with that RSU (depending on speed, RSU range and >> number). (ephemeral connections). >> >> What kind of requirements? -------------------------- The >> requirements for mechanisms for moving network to nearby moving >> network communications are focusing on low delays of the data paths, >> reduced number of messages for path establishment, application >> friendly, resilience to attacks, compatibility with DHCP and Mobile >> IP. >> >> In addition, some moving network to nearby moving network >> applications involve IP multicast mechanisms (e.g. virtual siren); >> thus C-ACC the 1-hop IP moving network to nearby moving netowrk >> mechanisms will need to gracefully support IP multicast. >> >> Due to the inherent characteristics of safety-related >> communications, all new moving network to nearby moving network >> mechanisms must afford authenticity and confidentiality where >> necessary. Dynamically establishing ephemeral communication paths >> between automobiles in public areas must offer privacy safeguards for >> the end users (passengers). >> >> Establishing 1-hop IP V2V paths must not break the existing on-board >> protocols and applications which communicate with the Internet, >> possibly via multiple radios. >> >> In a moving network deployed in an automobile, typically one exit >> point connects the moving network to other moving networks. >> However, in a more general manner (and to support reliability) any >> new mechanism of moving network to nearby moving network >> communications should support multi-homing: one router to use >> multiple interfaces towards outside the moving network, or multiple >> routers. >> >> Current version of Internet protocols >> ------------------------------------- The group will only work on >> IPv6 solutions. >> >> What SDOs may need this work? ----------------------------- The >> requirements and standards for moving network to nearby moving >> network communications, often involving IPv6, and novel V2V and >> V2Infra concepts, are developed mainly at ISO TC204 "Intelligent >> Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For >> Vehicle-to-Internet communications, 3GPP LTE and other cellular >> technologies represent the long-range connectivity method; for >> Vehicle-to-Vehicle communications, LTE Direct is currently >> specified, as well as OCB mode of IEEE 802.11. Several use-cases >> exhibit a need for IPv6 data exchanges between vehicles: ETSI's >> Cooperative Adaptive Cruise Control and Platooning. The IEEE >> developed a popular link for short-range communications - IEEE >> 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V >> communications. >> >> Work Items ---------- - use-cases for moving network to nearby moving >> network communications - Problem Statement for moving network to >> nearby moving network communications including V2V, V2I and DNS. - >> Security and Privacy Requirements for moving network to nearby moving >> network communications - Solutions, which might include new protocols >> or extensions to existing protocols. With MIB. - IPv6-over foo, >> where foo is pertinent for moving network to nearby moving network >> communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) - List of >> Research Papers in the V2V domain, identifying which uses IP. >> >> Timeline -------- - >> >> > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 Best Regards Dr. Karan Verma Assistant Professor Computer Science and Engineering Dept. Central University Rajasthan, India Website: www.drkaranverma.com Phone: +917568169258 --001a11401c9e78fe4c05303199d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Everyone,


I also= =C2=A0contribution= for a list of papers for IP-based V2V and V2I, still i'm writing final= =C2=A0revive=C2=A0comments. I will as send as soon as possible.

<= /div>

Thank You=C2=A0

O= n Mon, Apr 11, 2016 at 1:44 PM, Alexandre Petrescu <alexandre.p= etrescu@gmail.com> wrote:
J= =C3=A9r=C3=B4me,

Le 07/04/2016 01:11, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit :
Dear ITSers,=C2=A0 Dear Alex,

Here are some comments on the updated charter:

 1)Can we keep a reference to IEEE 802.11p, considering it does not
exist anymore? It is now fully integrated into IEEE 802.11-2012 as
OCB mode (and 10Mhz @5.9Ghz) of course.

The question is relevant.

Let's use "802.11-OCB" instead of "802.11p" everywh= ere.=C2=A0 Do you agree?

2)Should we really keep C-ACC (or Platooning) in the charter
explicitly as use case, considering it is a seriously controversial
aspect with some SDOs (ex. In Automotive SDOs)? In the ISO
presentation, Thierry mentions traffic efficiency/infotainment
applications, such as in-signage applications...

C-ACC and Platooning are use-cases exhibiting the need for V2V.=C2=A0 There=
are more use-cases needing V2V: e.g. "V2V emergency vehicle warning&qu= ot;,
"V2V emergency stop use cases" documented at 3GPP.=C2=A0 I dont t= hink it's worth documenting all of them, because their salient V2V char= acteristics are all exhibited by only one.

For Thierry's note: I think you mean "In-Vehicle Signage (IVS)&quo= t; case
study (slide 14 of "ISO TC204 needs" at
https://www.ietf.org/proceedings/95/sl= ides/slides-95-its-7.pdf )

If yes, that is a typical V2I use-case.=C2=A0 Maybe, "I2V" - Infr= astructure
to Vehicle communications.=C2=A0 It follows the same moving network to near= by
moving or fixed network paradigm: more precisely expressed as:=C2=A0 fixed<= span class=3D"">
network to nearby moving network communications.

a.We might have to aim at less controversial use cases to attract
automotive industries

Which one use-case would you think of?

Does it follow the paradigm of moving network to nearby moving or fixed
network communications?

3)One potential WI I could think of (rather a basic one): _definition
of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive context_
a.To me, this is=C2=A0 a fundamental brick in the larger IETF WG ITS
house..

I think that is right.

There seems to be interest in precisely defining what that 'link' i= s in
an automotive context.

This interest was illustrated by the IPv6 over 802.11-OCB discussion.

Such a link is used in V2V and V2I and I2V.

We should work on this, but within certain conditions: (1) we should not create new link characteristics, but describe the existing ones, (2) we
should describe how the link layer is interfaced with the IP layer.

The title of such a WG item should be "IPv6 over foo".

That said, how do you see the work on a potential WI talking about the
definition of a vehicular wireless link in an automotive context?


4)I would suggest to be more explicit in the foreseen challenges of
this WG, instead of mentioning general use case (which end up be
controversial)

 a.Example: maintaining IPv6 connectivity in fast and asymmetric
wireless links; also under quickly changing topologies (actually
suggested by Dick Roy on the chat room)

Yes, that's a long-term challenge: maintaining IPv6 connectivity in fas= t
and asymmetric wireless links, and under quivkly changing topologies.

The near term objective is: moving network to nearby moving or fixed
network communications.


b.Example: IPv6 addressing in link-local scope..

I agree.=C2=A0 Erik also said something about potential work on an addressi= ng
architecture for the V2V topology.

Do you think there is enough interest in IPv6 addressing architecture
for the V2V topology such as to propose a WG item for it?

c.Example: guaranteeing privacy in IPv6 moving networks etc..

I agree.=C2=A0 For this there is ongoing discussion with people inclined on=
security work.


5)Before listing academic papers referring to IPv6 in vehicles, I
would suggest to first try to list commercial products/solutions that
are in vehicles and are using IPv6, possibly suffering from a silo
limitations (ex. restricted to a single technology, single use
case=E2=80=A6)

Sounds relevant.=C2=A0 But too many separate items?

How about _one_ item with two sections: section with list of papers, and section with list of commercial products.

a.I think we need to get to products first, before academic visions

It's debatable.=C2=A0 How about answering first the above question, and= then
we'll see.

Alex


My two cents..

Best Regards,

J=C3=A9r=C3=B4me

 *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre
Petrescu *Sent:* Wednesday 06 April 2016 23:45 *To:* its@ietf.org
*Subject:* [its] charter ITS


ITSers,

Please see below the current charter.

- the two Problem Statements drafts V2V and V2I joined, so there is
less text in charter. - added an Item on "List of Research
papers..."

Erik: did I understand you correctly that there should be some item
on discussing whether link-local addressing is sufficient, whether
prefix exchange is necessary?

Dino: should LISP be included in the gap analysis draft which
includes C-ACC use-case?=C2=A0 OR should we separate a dedicated I-D only with gap analysis including ND, MIP, AODVv2, LISP?

Person from mediatek: is the 'zeroconf' need in the
vehicle-to-vehicle interface illustrated good enough by the words
"moving network to nearby moving network communications"?=C2=A0 O= r is it
better to say "the 1-IP-hop between nearby moving networks must be
self-configured"?

Nabil, Sandra: is it ok to have a working group item "List of
Research Papers for IP in V2V and V2I communications"?

Other comments?

Alex

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

ITS (name to change) Charter April 6th, 2016
http://ietf.org/mailman/listinfo/its


Intelligent Transportation Systems (its)
---------------------------------------- Current Status: WG forming

Chairs: TBD

Assigned Area Director: TBD

Mailing list Address: its= @ietf.org <mailto:= its@ietf.org> To

Subscribe: https://www.ietf.org/mailman/listinfo/its Ar= chive:
http://www.ietf.org/mail-archive/web/i= ts/current/maillist.html

Additional web page TBD

Charter:

Goal ---- The goal of this group is to standardize IP-based protocols
for establishing direct and secure connectivity between moving
networks, some of which could be fixed permanently or temporarily.

Moving Network to Nearby Moving Network Communications
------------------------------------------------------ The group is
concerned with all situations involving moving network to nearby
moving network communications.=C2=A0 For example: vehicle-to-vehicle
communications, nomadic user wearing a PAN and communicating to a
homenet, vehicle-to-infrastructure communications, wagon-to-wagon in
a train, or train-to-intersection signalling.

Example from the automobile communications space
------------------------------------------------ Automobiles and
vehicles of all types are increasingly connected to the Internet,
either as vehicle-to-vehicle, vehicle-to-infra or
vehicle-to-Internet.=C2=A0 Entertainment apps enhancing comfort, reliable data exchanges for road safety, and automated driving are features
coming in automobiles to hit the roads from now to year 2020.
Highlighting increased safety as an immediate result of
hyper-connectivity applied to vehicles, public authorities worldwide
are increasingly mandating secure communication technology
requirements in vehicles.

Emergency apps for new instrumented ambulances carry many benefits
both to the users and to society in general.

Why IP? ------- Today, there are several deployed Vehicle-to-Internet
technologies, including car tethering through driver's cellular
smartphone. However, Vehicle-to-Vehicle and
Vehicle-to-Infrastructure communications are still being developed.
To improve on a situation of link-specific data exchanges, and enable
independent application sets to share the same links, IP data
exchanges are needed.=C2=A0 Enabling IP communication between vehicles
(V2V), and between vehicles and the immediate infrastructure (V2I),
will provide (0) ability to reach the rest of the world on the
Internet (1) short and deterministic delays, (2) fast forwarding
through scalable paths of routers, (3) ease of reuse of existing
Internet applications in a vehicular environment.

Moving network to nearby moving network communications involve link
layers such as: 802.11p OCB (Outside the Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light
Communications), IrDA, LTE-D.=C2=A0 Only the IP protocols are capable of running on each of these links and establish IP paths across them in
an interoperable manner.

Scenarios? ---------- There are a few scenarios exhibiting the need
to communicate from one moving network to another nearby moving
network.

In the automobile space, the Cooperative Adaptive Cruise Control and
Platooning features consider that vehicles close to each other
exchange data describing their kinematic status.=C2=A0 At the
cross-roads, the moving network inside a vehicle exchanges data with
the moving network in the red-light pole.

Several public safety scenarios involve moving networks.=C2=A0 Distinct
organizations deploy different moving networks (in-vehicle,
on-person) at an incident scene.=C2=A0 These networks need to interoperate<= br> in order to more effectively understand and deal with the incident
scene.

In connected rail scenarios the moving network deployed in trains
communicate with other moving networks at the cross-points.

What kind of solutions? ----------------------- The current technical
solutions considered to achieve moving network to nearby moving
network communications are of two kinds: IP routing protocols for
n-hop path management and 1-hop link-scoped IP protocol enhancements.
The 1-hop link-scoped protocols include the protocols for route
establishment involving ICMP Router Advertisements.=C2=A0 The n-hop path management protocols include n-hop path establishment protocols (e.g.
Babel, OSPF) and n-hop path search protocols (most notably AODV and
derivates).

In this proposed Working Group the focus is on 1-hop protocols, and
leverage from other Working Groups for the n-hop situations.

In some of the moving network applications the window of opportunity
for exchanging data with the immediate infrastructure may be very
short.=C2=A0 For example, a car driving near a road-side unit may have
only 5s to exchange with that RSU (depending on speed, RSU range and
number). (ephemeral connections).

What kind of requirements? -------------------------- The
requirements for mechanisms for moving network to nearby moving
network communications are focusing on low delays of the data paths,
reduced number of messages for path establishment, application
friendly, resilience to attacks, compatibility with DHCP and Mobile
IP.

In addition, some moving network to nearby moving network
applications involve IP multicast mechanisms (e.g. virtual siren);
thus C-ACC the 1-hop IP moving network to nearby moving netowrk
mechanisms will need to gracefully support IP multicast.

Due to the inherent characteristics of safety-related
communications, all new moving network to nearby moving network
mechanisms must afford authenticity and confidentiality where
necessary.=C2=A0 Dynamically establishing ephemeral communication paths
between automobiles in public areas must offer privacy safeguards for
the end users (passengers).

Establishing 1-hop IP V2V paths must not break the existing on-board
protocols and applications which communicate with the Internet,
possibly via multiple radios.

In a moving network deployed in an automobile, typically one exit
point connects the moving network to other moving networks.
However, in a more general manner (and to support reliability) any
new mechanism of moving network to nearby moving network
communications should support multi-homing: one router to use
multiple interfaces towards outside the moving network, or multiple
routers.

Current version of Internet protocols
------------------------------------- The group will only work on
IPv6 solutions.

What SDOs may need this work? ----------------------------- The
requirements and standards for moving network to nearby moving
network communications, often involving IPv6, and novel V2V and
V2Infra concepts, are developed mainly at ISO TC204 "Intelligent
Transport Systems", 3GPP, ETSI, NHTSA and IEEE.=C2=A0 For
Vehicle-to-Internet communications, 3GPP LTE and other cellular
technologies represent the long-range connectivity method; for
Vehicle-to-Vehicle communications, LTE Direct is currently
specified, as well as OCB mode of IEEE 802.11.=C2=A0 Several use-cases
exhibit a need for IPv6 data exchanges between vehicles: ETSI's
Cooperative Adaptive Cruise Control and Platooning.=C2=A0 The IEEE
developed a popular link for short-range communications - IEEE
802.11p "WAVE".=C2=A0 The NHTSA wrote a set of requirements for V= 2V
communications.

Work Items ---------- - use-cases for moving network to nearby moving
network communications - Problem Statement for moving network to
nearby moving network communications including V2V, V2I and DNS. -
Security and Privacy Requirements for moving network to nearby moving
network communications - Solutions, which might include new protocols
or extensions to existing protocols.=C2=A0 With MIB. - IPv6-over foo,
where foo is pertinent for moving network to nearby moving network
communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) - List of
Research Papers in the V2V domain, identifying which uses IP.

Timeline -------- -


_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its



--
=
Best Regards=C2=A0

Dr. Karan Verma=C2=A0
Assistant Professor=C2=A0=C2=A0
Computer Science and Engineering Dept.
<= div dir=3D"ltr" style=3D"font-size:small">
Central University Rajasthan= , India=C2=A0
Website:=C2=A0www.drkaranverma.com
--001a11401c9e78fe4c05303199d6-- From nobody Mon Apr 11 04:26:47 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB62C12EC5B for ; Mon, 11 Apr 2016 04:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.353 X-Spam-Level: X-Spam-Status: No, score=-4.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ap5Tt0umGwEb for ; Mon, 11 Apr 2016 04:26:40 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2026512EC58 for ; Mon, 11 Apr 2016 04:26:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3BBQb9J029137; Mon, 11 Apr 2016 13:26:37 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9FA46205160; Mon, 11 Apr 2016 13:27:53 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 91816205099; Mon, 11 Apr 2016 13:27:53 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3BBQbgP007912; Mon, 11 Apr 2016 13:26:37 +0200 To: Michelle Wetterwald References: <570591D1.4070904@gmail.com> From: Alexandre Petrescu Message-ID: <570B89ED.30004@gmail.com> Date: Mon, 11 Apr 2016 13:26:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] Raw meeting minutes X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 11:26:46 -0000 Michelle, Le 07/04/2016 02:57, Michelle Wetterwald a écrit : > Hi Alex, all, > > Thank you for these minutes > > I would like to rephrase here the two comments that I made during > the meeting to the V2I problem statement draft and could not be > captured in the minutes: - in the V2I case, the performance of the > system and the coverage time vs. vehicle speed should be taken into > account. At the contrary of the V2V C-ACC case you described where > both cars are moving in the same direction, which ensures some time > to exchange prefixes, names, etc., in the V2I case, the coverage > time with one RSU may be short. Thus this signalling should have a > really low latency. This looks like an IP handover performance issue, or improvement. For the moment we do not look at it. > - Secondly, the potential congestion of the system when hundreds of > cars would be located in the same area and establishing or using V2I > communications should also be taken into account as an issue. > Switching part of the traffic to a more available channel, as was > proposed, may not always be possible. Reducing the size of the > packet, however, by using header compression technique as in 6lo, > may offer a potential improvement. This kind of activity is typically part of IPv6-over-foo document. For example, look at RFC 2460 "Transmission of IPv6 Packets over Ethernet". Do you think there is some work to do about IPv6-over-'foo'? ('foo' is a link layer for vehicular communications.) There can be something about leveraging 6lo techniques in IPv6-over-'foo'. Do you know of a use-case needing 6lo techniques in vehicular networks? Alex > > Best regards, Michelle Wetterwald ---- Senior expert in networking > and telecommunications > > 2016-04-06 19:46 GMT-03:00 Alexandre Petrescu > >: > > Raw meeting minutes, thanks to minute takers for efforts despite > echo-ey PA system. > > Alex > > ------------------------------------------------------------------ > > Minutes for [its] > > • Introduction: > > > – Administrative - BOF Chairs - 5 min > > > – ITS Goals and Success Criteria - BOF Chairs - 10 min > > > • Problem Space: > > > – Tutorial of IP in vehicular communications - Alex Petrescu - 20 min > Randel Gelland: Since there are so many MAC & PHY, they use their own > messaging -- so could use IP. But vehicals are using different PHY & > MAC, so they can't communicate Alex: But some of the radios are > actually compatible > > Bob Hinden: On "Topology" slide -- this is very simplified. There > will be many cars, with very dynamic interconnection Alex: Yes. Gives > more examples to support contention > > Dapeng Liu: Once connectivity is established, IP will enable better > communication. > > Pat Thaler: Even for compatible PHY, MACs may be different, so can't > just day "use IP" > > Erik Nordmark: Have people considered what the IP addressing will > look like? In the car, the addressing is stable, but not outside the > car. How does one car know the address in the other car? Alex: Yes, > people are working on this. IETF can help. > > Carlos: Are people working on the addressing sheme. > > Dino: We have an IP mobility problem > > Dirk Kircher: Broadcast. Semantic layer. Alex: There may be > multiple hops beween cars, and multiple hops in a car. May need IPv4 > broadcast, or IPv6 broadcast > > Dino: Even without the mobility problem, we still would have > physical layer incompatible problems. But that is exactly what IP > solves. > > – ITS use-cases C-ACC and Platooning - Alex Petrescu - 10 min > draft-petrescu-its-cacc-sdo-04 > > Lou Berger: > Hackable. What's the security model? Alex: Do not have slides about > this. Eric Rescolo: Why make any representation about exceeding > speedlimit. Alex: It's just an example Eric Rescolo: What if the > police ask this question? > > Sandra: there is a lot of work being done on security = Safety part > > Eric Burdick: There are a lot of privacy issues. There is work > about jamming. It's not just Mobile IP. > > Erik Nordmark: There was an IETF plenary that is relevant to > security. = Police can probaly go get the data > > Eric Rescolo: Lots of work to be done -- prevent querying in the > car. > > > – ITS V2V problem statement - Dapeng Liu - 5 min > draft-petrescu-its-problem-00 > > Randel Gelland: How do they know when they need to discover the > other vehicles' address? Dirk Kircher: Sub-Problem(1) needs to be > characterized correctly. What is a realistic use case: Answer: > C-ACC > > ...: do you have data? Alex: How much data do you want? > > Randel Gellens: This shows how IP is useful, but it's not why IP is > needed? So it is needed to exhibit the need, not just the use case. > > Erik Nordmark: how identities (or even temporary identities) > established? > > Hannes Tshofenig: Is there a need for another layer for identity? > > > – ITS V2I problem statement - Jaehoon Paul Jeong - 5 min > draft-jeong-its-v2i-problem-statement-00 > > Charlie: What does it mean to "directly" connect to the RSO's network > Jaehoon: Exchange prefixes > > Woman > > Dino: a lost packet could be a catastrophe, amidst a lot of > connection. Need to avoid chit-chat. Should avoid multiple > solutions. If security requires Diffie-Hellman, may not get to > finally say "BRAKE" Dino: May not be able to go get a certificate. > > <....?>: May not have time to > > Dirk Kircher: Question about use case... > > Alex: Some operators already provide connection between RSUs, and > thus can provide handovers > > • Discussion - 10 min > > Aaron Falk: Good to have the discussion. Useful confusion [??} Dirk > Kircher: Use cases need discussion, as well as network drivers. > Carlos: Are you talking about requirements? Dirk: Network > requirements... Erik Nordmark: Don't really grasp exactly why IP is > needed for single hop. Will this use the same Internet? What about > the timing requirements? Stan Ratliff: V2V could be mobile ad hoc > network? Russ: Not if it's just one hop. <...> : Want to know what > cars are closing in. Could want to send message just backwards. > Dino: What if you *don't* have IP? A lot of vehicles already have > IP, so it is already there. IP could simplify the automobile and the > communications. We will want to write applications. Will need to > have compatible format. We will want open standards. Spencer > Dawkins: Was waiting for a transport question. Applications might be > close to each other? About updating the car. Hannes: Applications > might be running on many different computers and media, but still > need to communicate. Pat Thaler: Updating the car is a different > sort of thing than V2I. We will have updates at the service station, > so you're not moving. Three concerns: security problem. Time > constraints. Spencer: Need to understand what the volume of data > would be. Dirk: Is it, or is it not, TCP? There are a couple of > protocols in use today. Eric Burdick: Should assume that all > protocols are broken. The control mechanisms could collapse with the > number of cars. > > – What documents are needed to advance this work? > http://itu.int/go/ITScomms is complete list of ITU work items > > Dino: Why include trains but not planes? Alex: O.K. Erik Burdick: > What about when get onto the ocean? Dirk: Some of the use cases are > very dissimilar. Need to pick one problem. Aaron from Jabber: Can > assume use of certificates. Dino: Need to look at the requirements > and see if there are solutions, even though there are a lot of work > items. Erik Nordmark: Can we figure out what is needed for the > immediate term? Randall Gellens: What about coordination with other > SDOs? For instance regarding IPv6-over-foo. Alex: With a working > group we can have a channel by which to do the coordination Randall: > We have that with ISO, 3GPP, etc. > > Closing remarks: We will publish the charter on the working group. In > about a month we will see if we have a rigorous charter. > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > -- Michelle Wetterwald michelle.wetterwald@gmail.com > From nobody Wed Apr 13 18:22:55 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B754E12E5C8 for ; Wed, 13 Apr 2016 18:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz-7MLcBzrD0 for ; Wed, 13 Apr 2016 18:22:50 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6288C12E5C3 for ; Wed, 13 Apr 2016 18:22:50 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id t10so89635067ywa.0 for ; Wed, 13 Apr 2016 18:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I0xNtPBLFRJi/t4SIicwHu9jYMyc94J9UM4pYpiTCVY=; b=fufPCKSejPlMtpYK5pIa3zdrBD8lvSbclYdd57uAQcy+/339y20JQJZXG3RfbKzVjl TYgOZ1mP5iu8ouaXkaN2J4BScLqQkTpSu1N2P6h/6ZCl3ldHzXfaj5QzMjCYalGm/Ymv 4fzJVaqtxQJ70eRJ1PD7Rn0r1jC0vVmkLvIIsK7biPsYTUXEIJCbM8usSyPRtuZLXXzj NHOmRzNB/MuRfe/9tCSor0a8/sAXOXjMH70GYlHhC/9fLM1nfzgqICyCTb7Zw1Q7+U3N uN3UIaqg4yCXGw7rM4Pdg5auffDzz9E00tZPFGp+mF0w64uzOs1nE/uk5YXN9WqOcnf/ qHtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I0xNtPBLFRJi/t4SIicwHu9jYMyc94J9UM4pYpiTCVY=; b=Q5YU7+ASlrvFKsKYraS/K4mMh0yxRV6dZSBKtD1ZfH4iKC1T0gY9IuPBiHTysqUd+P IHLUxLkvC0weK7yGs9vIntE52RNcwycH5z4t4w9LMR0eksjPjqNRLi2+OJ/w1c3tFDBG M/fpJws+D9kJ8ScM76b1Ym5JgJzliYzXeWBINKZxhjtyRJ/h+z483HDJBeZ3R5AUIxhZ UkQ5zP19dqyITShC2JX//FVnvAvl83uollfFHsWeVGfoEtYiOwJ0PaxKQXxybwODMo/8 rWG+Q3lAZ/Um6Y0i+lWCVTwpaMdiHqaYe6egMTqXKGgRKSpVyDZCuzVBr4pp3MVxe9jm InvQ== X-Gm-Message-State: AOPr4FWZv+gUQZVTqoNSX0pQW0nm5FuYGamxMVWjb0t1rG+RbAUXThZFtMjjG8h9OGKtksIQsTutlACu8LIXJg== X-Received: by 10.13.214.146 with SMTP id y140mr7652442ywd.216.1460596969528; Wed, 13 Apr 2016 18:22:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.4.22 with HTTP; Wed, 13 Apr 2016 18:22:19 -0700 (PDT) In-Reply-To: <009301d19059$96917820$c3b46860$@eurecom.fr> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> From: "Mr. Jaehoon Paul Jeong" Date: Thu, 14 Apr 2016 10:22:19 +0900 Message-ID: To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= Content-Type: multipart/alternative; boundary=94eb2c0766da8761a9053067bb85 Archived-At: Cc: Alexandre Petrescu , its@ietf.org Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 01:22:53 -0000 --94eb2c0766da8761a9053067bb85 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi J=C3=A9r=C3=B4me, I have an opinion on your comment 5) below. I think that a list of high-quality papers about IP-based V2V and V2I can teach very useful lessons to software designers of IP in V2V and V2I in the industry. Multiple people are working for this IP-based V2V and V2I (including Sandra Cespedes and me) in academia and more people(including Nabil Benamar) are willing to work for this area. I think we need to utilize the list of such papers as the ground for our ITS group through a WI. Note that the draft of the list will include the summary of the main ideas of the papers. For the industry current activities for this area, I believe that you can share them as references through our ITS mailing list rather than through a WI. Could you join my team that are making efforts for a list of such papers? Thanks. Best Regards, Paul On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri wrote: > Dear ITSers, Dear Alex, > > > > Here are some comments on the updated charter: > > 1) Can we keep a reference to IEEE 802.11p, considering it does not > exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mo= de > (and 10Mhz @5.9Ghz) of course. > > > > 2) Should we really keep C-ACC (or Platooning) in the charter > explicitly as use case, considering it is a seriously controversial aspec= t > with some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry > mentions traffic efficiency/infotainment applications, such as in-signage > applications... > > a. We might have to aim at less controversial use cases to attract > automotive industries > > > > 3) One potential WI I could think of (rather a basic one): *definiti= on > of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive context* > > a. To me, this is a fundamental brick in the larger IETF WG ITS > house.. > > > > 4) I would suggest to be more explicit in the foreseen challenges of > this WG, instead of mentioning general use case (which end up be > controversial) > > a. Example: maintaining IPv6 connectivity in fast and asymmetric > wireless links; also under quickly changing topologies (actually suggeste= d > by Dick Roy on the chat room) > > b. Example: IPv6 addressing in link-local scope.. > > c. Example: guaranteeing privacy in IPv6 moving networks etc.. > > > > 5) Before listing academic papers referring to IPv6 in vehicles, I > would suggest to first try to list commercial products/solutions that are > in vehicles and are using IPv6, possibly suffering from a silo limitation= s > (ex. restricted to a single technology, single use case=E2=80=A6) > > a. I think we need to get to products first, before academic vision= s > > > > My two cents.. > > > > Best Regards, > > > > J=C3=A9r=C3=B4me > > > > > > > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre > Petrescu > *Sent:* Wednesday 06 April 2016 23:45 > *To:* its@ietf.org > *Subject:* [its] charter ITS > > > > ITSers, > > Please see below the current charter. > > - the two Problem Statements drafts V2V and V2I joined, so there is less > text in charter. > - added an Item on "List of Research papers..." > > Erik: did I understand you correctly that there should be some item on > discussing whether link-local addressing is sufficient, whether prefix > exchange is necessary? > > Dino: should LISP be included in the gap analysis draft which includes > C-ACC use-case? OR should we separate a dedicated I-D only with gap > analysis including ND, MIP, AODVv2, LISP? > > Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle > interface illustrated good enough by the words "moving network to nearby > moving network communications"? Or is it better to say "the 1-IP-hop > between nearby moving networks must be self-configured"? > > Nabil, Sandra: is it ok to have a working group item "List of Research > Papers for IP in V2V and V2I communications"? > > Other comments? > > Alex > > ------------------------------------------------------------------ > > ITS (name to change) > Charter > April 6th, 2016 > http://ietf.org/mailman/listinfo/its > > > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming > > Chairs: > TBD > > Assigned Area Director: > TBD > > Mailing list > Address: its@ietf.org > 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: > > Goal > ---- > The goal of this group is to standardize IP-based protocols for > establishing direct and secure connectivity between moving networks, > some of which could be fixed permanently or temporarily. > > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving network to > nearby moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > train, or train-to-intersection signalling. > > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to > the Internet, either as vehicle-to-vehicle, vehicle-to-infra or > vehicle-to-Internet. Entertainment apps enhancing comfort, reliable > data exchanges for road safety, and automated driving are features > coming in automobiles to hit the roads from now to year 2020. > Highlighting increased safety as an immediate result of > hyper-connectivity applied to vehicles, public authorities worldwide > are increasingly mandating secure communication technology > requirements in vehicles. > > Emergency apps for new instrumented ambulances carry many benefits > both to the users and to society in general. > > Why IP? > ------- > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. > However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure > communications are still being developed. To improve on a situation > of link-specific data exchanges, and enable independent application > sets to share the same links, IP data exchanges are needed. Enabling > IP communication between vehicles (V2V), and between vehicles and the > immediate infrastructure (V2I), will provide (0) ability to reach the > rest of the world on the Internet (1) short and deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) ease of > reuse of existing Internet applications in a vehicular environment. > > Moving network to nearby moving network communications involve link > layers such as: 802.11p OCB (Outside the Context of a Basic Service > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light > Communications), IrDA, LTE-D. Only the IP protocols are capable of > running on each of these links and establish IP paths across them in > an interoperable manner. > > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate from one > moving network to another nearby moving network. > > In the automobile space, the Cooperative Adaptive Cruise Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the cross-roads, > the moving network inside a vehicle exchanges data with the moving > network in the red-light pole. > > Several public safety scenarios involve moving networks. Distinct > organizations deploy different moving networks (in-vehicle, on-person) > at an incident scene. These networks need to interoperate in order to > more effectively understand and deal with the incident scene. > > In connected rail scenarios the moving network deployed in trains > communicate with other moving networks at the cross-points. > > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol > enhancements. The 1-hop link-scoped protocols include the protocols > for route establishment involving ICMP Router Advertisements. The > n-hop path management protocols include n-hop path establishment > protocols (e.g. Babel, OSPF) and n-hop path search protocols (most > notably AODV and derivates). > > In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations. > > In some of the moving network applications the window of opportunity > for exchanging data with the immediate infrastructure may be very > short. For example, a car driving near a road-side unit may have only > 5s to exchange with that RSU (depending on speed, RSU range and > number). (ephemeral connections). > > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to nearby moving > network communications are focusing on low delays of the data paths, > reduced number of messages for path establishment, application > friendly, resilience to attacks, compatibility with DHCP and Mobile > IP. > > In addition, some moving network to nearby moving network applications > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the > 1-hop IP moving network to nearby moving netowrk mechanisms will need > to gracefully support IP multicast. > > Due to the inherent characteristics of safety-related communications, > all new moving network to nearby moving network mechanisms must afford > authenticity and confidentiality where necessary. Dynamically > establishing ephemeral communication paths between automobiles in > public areas must offer privacy safeguards for the end users > (passengers). > > Establishing 1-hop IP V2V paths must not break the existing on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. > > In a moving network deployed in an automobile, typically one exit > point connects the moving network to other moving networks. However, > in a more general manner (and to support reliability) any new > mechanism of moving network to nearby moving network communications > should support multi-homing: one router to use multiple interfaces > towards outside the moving network, or multiple routers. > > Current version of Internet protocols > ------------------------------------- > The group will only work on IPv6 solutions. > > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to nearby moving > network communications, often involving IPv6, and novel V2V and > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For > Vehicle-to-Internet communications, 3GPP LTE and other cellular > technologies represent the long-range connectivity method; for > Vehicle-to-Vehicle communications, LTE Direct is currently specified, > as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need > for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive > Cruise Control and Platooning. The IEEE developed a popular link for > short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a > set of requirements for V2V communications. > > Work Items > ---------- > - use-cases for moving network to nearby moving network communications > - Problem Statement for moving network to nearby moving network > communications > including V2V, V2I and DNS. > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Solutions, which might include new protocols or extensions to > existing protocols. With MIB. > - IPv6-over foo, where foo is pertinent for moving network to nearby > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) > - List of Research Papers in the V2V domain, identifying which uses IP. > > Timeline > -------- > - > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --94eb2c0766da8761a9053067bb85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi J=C3=A9r=C3=B4me,
I have an opinion on y= our comment 5) below.

I think that a list of high-= quality papers about IP-based V2V and V2I
can teach very useful l= essons to software designers of IP in V2V and V2I
in the industry= .
Multiple people are working for this IP-based V2V and V2I=C2=A0=
(including Sandra Cespedes and me) in academia and=C2=A0
more people(including Nabil Benamar) are willing to work for this area.<= /div>

I think we need to utilize the list of such papers= as the ground for our ITS group
through a WI. Note that the draf= t of the list will include the summary of the main=C2=A0
ideas of= the papers.

For the industry current activities f= or this area, I believe that you can share them
as references thr= ough our ITS mailing list rather than through a WI.=C2=A0

Could you join my team that are making efforts for a list of such p= apers?

Thanks.

Best Regar= ds,
Paul
=C2=A0

On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4= rri <jerome.haerri@eurecom.fr> wrote:

Dear IT= Sers, =C2=A0Dear Alex,

=C2=A0

Here are some comments on the updated charter:<= u>

=

1)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Can we keep a= reference to IEEE 802.11p, considering it does not exist anymore? It is no= w fully integrated into IEEE 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of= course.

=C2= =A0

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Should we really= keep C-ACC (or Platooning) in the charter explicitly as use case, consider= ing it is a seriously controversial aspect with some SDOs (ex. In Automotiv= e SDOs)? In the ISO presentation, Thierry mentions traffic efficiency/infot= ainment applications, such as in-signage applications...

a.=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 One potential WI I could think of (rather a basic one): = definition of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive = context

= a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 To me, this is=C2=A0 a fundamental brick in= the larger IETF WG ITS house..

=C2=A0

4)=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 I would suggest to be more explicit in the foreseen challenges of this= WG, instead of mentioning general use case (which end up be controversial)=

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Example: maintaining IPv6 connectivity in fast and asy= mmetric wireless links; also under quickly changing topologies (actually su= ggested by Dick Roy on the chat room)

b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Example: IPv6 addressin= g in link-local scope..

c.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Example: guaranteeing privacy i= n IPv6 moving networks etc..

=C2=A0

5)=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 a.=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 = =C2=A0

M= y two cents..

=C2=A0

Best Regards,

=C2=A0

J=C3=A9r=C3=B4me=

=C2=A0<= /span>

=C2=A0

= =C2=A0

From: its [mailto= :its-bounces@ietf= .org] On Behalf Of Alexandre Petrescu
Sent: Wednesday = 06 April 2016 23:45
To: its@ietf.org
Subject: [its] charter ITS

=C2=A0

ITSers,

Please see= below the current charter.

- the two Problem Statements drafts V2V = and V2I joined, so there is less text in charter.
- added an Item on &qu= ot;List of Research papers..."

Erik: did I understand you corre= ctly that there should be some item on discussing whether link-local addres= sing is sufficient, whether prefix exchange is necessary?

Dino: shou= ld LISP be included in the gap analysis draft which includes C-ACC use-case= ?=C2=A0 OR should we separate a dedicated I-D only with gap analysis includ= ing ND, MIP, AODVv2, LISP?

Person from mediatek: is the 'zerocon= f' need in the vehicle-to-vehicle interface illustrated good enough by = the words "moving network to nearby moving network communications"= ;?=C2=A0 Or is it better to say "the 1-IP-hop between nearby moving ne= tworks must be self-configured"?

Nabil, Sandra: is it ok to hav= e a working group item "List of Research Papers for IP in V2V and V2I = communications"?

Other comments?

Alex

-----------= -------------------------------------------------------

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ITS (name to c= hange)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Charter
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 April 6th, 2016
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://ietf.org/mailman/listinfo/i= ts


Intelligent Transportation Systems (its)
-------------= ---------------------------
Current Status: WG forming

Chairs:=C2=A0=C2=A0 TBD

Assigned Area Director:
=C2=A0=C2=A0 TBD
Mailing list
=C2=A0=C2=A0 Address: its@ietf.org
=C2=A0=C2=A0 To Subscribe: https://www.ietf.= org/mailman/listinfo/its
=C2=A0=C2=A0 Archive:
=C2=A0=C2=A0 http://www.ietf.org/mail-archive/web/its/current/maillist.html=

Additional web page
=C2=A0=C2=A0 TBD

Charter:

= Goal
----
The goal of this group is to standardize IP-based protocols= for
establishing direct and secure connectivity between moving networks= ,
some of which could be fixed permanently or temporarily.

Moving= Network to Nearby Moving Network Communications
-----------------------= -------------------------------
The group is concerned with all situatio= ns involving moving network to
nearby moving network communications.=C2= =A0 For example: vehicle-to-vehicle
communications, nomadic user wearing= a PAN and communicating to a
homenet, vehicle-to-infrastructure communi= cations, wagon-to-wagon in a
train, or train-to-intersection signalling.=

Example from the automobile communications space
---------------= ---------------------------------
Automobiles and vehicles of all types = are increasingly connected to
the Internet, either as vehicle-to-vehicle= , vehicle-to-infra or
vehicle-to-Internet.=C2=A0 Entertainment apps enha= ncing comfort, reliable
data exchanges for road safety, and automated dr= iving are features
coming in automobiles to hit the roads from now to ye= ar 2020.
Highlighting increased safety as an immediate result of
hype= r-connectivity applied to vehicles, public authorities worldwide
are inc= reasingly mandating secure communication technology
requirements in vehi= cles.

Emergency apps for new instrumented ambulances carry many bene= fits
both to the users and to society in general.

Why IP?
----= ---
Today, there are several deployed Vehicle-to-Internet technologies,<= br>including car tethering through driver's cellular smartphone.
How= ever, Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communications ar= e still being developed.=C2=A0 To improve on a situation
of link-specifi= c data exchanges, and enable independent application
sets to share the s= ame links, IP data exchanges are needed.=C2=A0 Enabling
IP communication= between vehicles (V2V), and between vehicles and the
immediate infrastr= ucture (V2I), will provide (0) ability to reach the
rest of the world on= the Internet (1) short and deterministic delays,
(2) fast forwarding th= rough scalable paths of routers, (3) ease of
reuse of existing Internet = applications in a vehicular environment.

Moving network to nearby mo= ving network communications involve link
layers such as: 802.11p OCB (Ou= tside the Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11= ac, VLC (Visible Light
Communications), IrDA, LTE-D.=C2=A0 Only the IP p= rotocols are capable of
running on each of these links and establish IP = paths across them in
an interoperable manner.

Scenarios?
-----= -----
There are a few scenarios exhibiting the need to communicate from = one
moving network to another nearby moving network.

In the autom= obile space, the Cooperative Adaptive Cruise Control and
Platooning feat= ures consider that vehicles close to each other
exchange data describing= their kinematic status.=C2=A0 At the cross-roads,
the moving network in= side a vehicle exchanges data with the moving
network in the red-light p= ole.

Several public safety scenarios involve moving networks.=C2=A0 = Distinct
organizations deploy different moving networks (in-vehicle, on-= person)
at an incident scene.=C2=A0 These networks need to interoperate = in order to
more effectively understand and deal with the incident scene= .

In connected rail scenarios the moving network deployed in trains<= br>communicate with other moving networks at the cross-points.

What = kind of solutions?
-----------------------
The current technical solu= tions considered to achieve moving network
to nearby moving network comm= unications are of two kinds: IP routing
protocols for n-hop path managem= ent and 1-hop link-scoped IP protocol
enhancements.=C2=A0 The 1-hop link= -scoped protocols include the protocols
for route establishment involvin= g ICMP Router Advertisements.=C2=A0 The
n-hop path management protocols = include n-hop path establishment
protocols (e.g. Babel, OSPF) and n-hop = path search protocols (most
notably AODV and derivates).

In this = proposed Working Group the focus is on 1-hop protocols, and
leverage fro= m other Working Groups for the n-hop situations.

In some of the movi= ng network applications the window of opportunity
for exchanging data wi= th the immediate infrastructure may be very
short.=C2=A0 For example, a = car driving near a road-side unit may have only
5s to exchange with that= RSU (depending on speed, RSU range and
number). (ephemeral connections)= .

What kind of requirements?
--------------------------
The re= quirements for mechanisms for moving network to nearby moving
network co= mmunications are focusing on low delays of the data paths,
reduced numbe= r of messages for path establishment, application
friendly, resilience t= o attacks, compatibility with DHCP and Mobile
IP.

In addition, so= me moving network to nearby moving network applications
involve IP multi= cast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP moving net= work to nearby moving netowrk mechanisms will need
to gracefully support= IP multicast.

Due to the inherent characteristics of safety-related= communications,
all new moving network to nearby moving network mechani= sms must afford
authenticity and confidentiality where necessary.=C2=A0 = Dynamically
establishing ephemeral communication paths between automobil= es in
public areas must offer privacy safeguards for the end users
(p= assengers).

Establishing 1-hop IP V2V paths must not break the exist= ing on-board
protocols and applications which communicate with the Inter= net,
possibly via multiple radios.

In a moving network deployed i= n an automobile, typically one exit
point connects the moving network to= other moving networks.=C2=A0 However,
in a more general manner (and to = support reliability) any new
mechanism of moving network to nearby movin= g network communications
should support multi-homing: one router to use = multiple interfaces
towards outside the moving network, or multiple rout= ers.

Current version of Internet protocols
----------------------= ---------------
The group will only work on IPv6 solutions.

What = SDOs may need this work?
-----------------------------
The requiremen= ts and standards for moving network to nearby moving
network communicati= ons, often involving IPv6, and novel V2V and
V2Infra concepts, are devel= oped mainly at ISO TC204 "Intelligent
Transport Systems", 3GPP= , ETSI, NHTSA and IEEE.=C2=A0 For
Vehicle-to-Internet communications, 3G= PP LTE and other cellular
technologies represent the long-range connecti= vity method; for
Vehicle-to-Vehicle communications, LTE Direct is curren= tly specified,
as well as OCB mode of IEEE 802.11.=C2=A0 Several use-cas= es exhibit a need
for IPv6 data exchanges between vehicles: ETSI's C= ooperative Adaptive
Cruise Control and Platooning.=C2=A0 The IEEE develo= ped a popular link for
short-range communications - IEEE 802.11p "W= AVE".=C2=A0 The NHTSA wrote a
set of requirements for V2V communica= tions.

Work Items
----------
- use-cases for moving network to= nearby moving network communications
- Problem Statement for moving net= work to nearby moving network communications
=C2=A0 including V2V, V2I a= nd DNS.
- Security and Privacy Requirements for moving network to
=C2= =A0 nearby moving network communications
- Solutions, which might includ= e new protocols or extensions to
=C2=A0 existing protocols.=C2=A0 With M= IB.
- IPv6-over foo, where foo is pertinent for moving network to nearby=
=C2=A0 moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.= 11ad)
- List of Research Papers in the V2V domain, identifying which use= s IP.

Timeline
--------
-

=

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its




--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant ProfessorDepartment of Software
Sungkyunkwan University
Office: +82-31-299-4= 957
Email: j= aehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu<= br>Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
--94eb2c0766da8761a9053067bb85-- From nobody Thu Apr 14 00:09:47 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2F112D53D for ; Thu, 14 Apr 2016 00:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WAnv1ehFqxP for ; Thu, 14 Apr 2016 00:09:41 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id 03E9C12D513 for ; Thu, 14 Apr 2016 00:09:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,483,1454972400"; d="scan'208,217";a="3675339" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 14 Apr 2016 09:09:39 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 82F59329; Thu, 14 Apr 2016 09:09:39 +0200 (CEST) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Mr. Jaehoon Paul Jeong'" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> In-Reply-To: Date: Thu, 14 Apr 2016 09:09:39 +0200 Organization: EURECOM Message-ID: <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0096_01D1962D.5FDC41A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt54qCPzaRhlgKe35lrbFRjfOAYQFS/geMAQE6Hj2gPcWZMA== Content-Language: en-us Archived-At: Cc: 'Alexandre Petrescu' , its@ietf.org Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 07:09:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0096_01D1962D.5FDC41A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Paul, =20 Thanks for your feedback. Do not get me wrong, I am an academic and with = my team, we also work on IP-based V2V and V2I, in particular related to = mobility management with DMM, but also in the context of vehicular IoT.=20 =20 I just have the feeling that people are perfectly aware of the fact that = IP can be used for V2V and V2I, but does not =E2=80=98need=E2=80=99 to = be used as other solutions already perfectly fit their need. Listing = papers will not change this awareness.=20 =20 So, as a complement to academic papers, it would help to be able to = pin-point which industrial activities are using or are strongly planning = (short term I mean) to use pure IPv6 system in vehicles.=20 =20 My feeling here is we have a different eco-system that the Automotive = industry (and automotive industry-related SDO)..more likely the IoT = industry=E2=80=A6and as such, we should not need to have the (direct) = involvement of automotive industry in the Charter. If we can make this = clear by an industry-based =E2=80=98survey=E2=80=99, that would help = make the case for the WG. Btw, you can count on me your draft..we can add some IP-based V2V and = V2I for mobility management and also IoT. =20 Cheers, =20 J=C3=A9r=C3=B4me =20 From: Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com]=20 Sent: Thursday 14 April 2016 03:22 To: J=C3=A9r=C3=B4me H=C3=A4rri Cc: Alexandre Petrescu; its@ietf.org Subject: Re: [its] charter ITS =20 Hi J=C3=A9r=C3=B4me, I have an opinion on your comment 5) below. =20 I think that a list of high-quality papers about IP-based V2V and V2I can teach very useful lessons to software designers of IP in V2V and V2I in the industry. Multiple people are working for this IP-based V2V and V2I=20 (including Sandra Cespedes and me) in academia and=20 more people(including Nabil Benamar) are willing to work for this area. =20 I think we need to utilize the list of such papers as the ground for our = ITS group through a WI. Note that the draft of the list will include the summary = of the main=20 ideas of the papers. =20 For the industry current activities for this area, I believe that you = can share them as references through our ITS mailing list rather than through a WI.=20 =20 Could you join my team that are making efforts for a list of such = papers? =20 Thanks. =20 Best Regards, Paul =20 =20 On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri = wrote: Dear ITSers, Dear Alex, =20 Here are some comments on the updated charter: 1) Can we keep a reference to IEEE 802.11p, considering it does not = exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB = mode (and 10Mhz @5.9Ghz) of course.=20 =20 2) Should we really keep C-ACC (or Platooning) in the charter = explicitly as use case, considering it is a seriously controversial = aspect with some SDOs (ex. In Automotive SDOs)? In the ISO presentation, = Thierry mentions traffic efficiency/infotainment applications, such as = in-signage applications... a. We might have to aim at less controversial use cases to attract = automotive industries =20 3) One potential WI I could think of (rather a basic one): = definition of a vehicular wireless =E2=80=98link=E2=80=99 in an = automotive context a. To me, this is a fundamental brick in the larger IETF WG ITS = house.. =20 4) I would suggest to be more explicit in the foreseen challenges = of this WG, instead of mentioning general use case (which end up be = controversial) a. Example: maintaining IPv6 connectivity in fast and asymmetric = wireless links; also under quickly changing topologies (actually = suggested by Dick Roy on the chat room) b. Example: IPv6 addressing in link-local scope.. c. Example: guaranteeing privacy in IPv6 moving networks etc.. =20 5) Before listing academic papers referring to IPv6 in vehicles, I = would suggest to first try to list commercial products/solutions that = are in vehicles and are using IPv6, possibly suffering from a silo = limitations (ex. restricted to a single technology, single use = case=E2=80=A6) a. I think we need to get to products first, before academic = visions =20 My two cents.. =20 Best Regards, =20 J=C3=A9r=C3=B4me =20 =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Wednesday 06 April 2016 23:45 To: its@ietf.org Subject: [its] charter ITS =20 ITSers, Please see below the current charter. - the two Problem Statements drafts V2V and V2I joined, so there is less = text in charter. - added an Item on "List of Research papers..." Erik: did I understand you correctly that there should be some item on = discussing whether link-local addressing is sufficient, whether prefix = exchange is necessary? Dino: should LISP be included in the gap analysis draft which includes = C-ACC use-case? OR should we separate a dedicated I-D only with gap = analysis including ND, MIP, AODVv2, LISP? Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle = interface illustrated good enough by the words "moving network to nearby = moving network communications"? Or is it better to say "the 1-IP-hop = between nearby moving networks must be self-configured"? Nabil, Sandra: is it ok to have a working group item "List of Research = Papers for IP in V2V and V2I communications"? Other comments? Alex ------------------------------------------------------------------ ITS (name to change) Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: WG forming Chairs: TBD Assigned Area Director: TBD Mailing list Address: its@ietf.org 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: Goal ---- The goal of this group is to standardize IP-based protocols for establishing direct and secure connectivity between moving networks, some of which could be fixed permanently or temporarily. Moving Network to Nearby Moving Network Communications ------------------------------------------------------ The group is concerned with all situations involving moving network to nearby moving network communications. For example: vehicle-to-vehicle communications, nomadic user wearing a PAN and communicating to a homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a train, or train-to-intersection signalling. Example from the automobile communications space ------------------------------------------------ Automobiles and vehicles of all types are increasingly connected to the Internet, either as vehicle-to-vehicle, vehicle-to-infra or vehicle-to-Internet. Entertainment apps enhancing comfort, reliable data exchanges for road safety, and automated driving are features coming in automobiles to hit the roads from now to year 2020. Highlighting increased safety as an immediate result of hyper-connectivity applied to vehicles, public authorities worldwide are increasingly mandating secure communication technology requirements in vehicles. Emergency apps for new instrumented ambulances carry many benefits both to the users and to society in general. Why IP? ------- Today, there are several deployed Vehicle-to-Internet technologies, including car tethering through driver's cellular smartphone. However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are still being developed. To improve on a situation of link-specific data exchanges, and enable independent application sets to share the same links, IP data exchanges are needed. Enabling IP communication between vehicles (V2V), and between vehicles and the immediate infrastructure (V2I), will provide (0) ability to reach the rest of the world on the Internet (1) short and deterministic delays, (2) fast forwarding through scalable paths of routers, (3) ease of reuse of existing Internet applications in a vehicular environment. Moving network to nearby moving network communications involve link layers such as: 802.11p OCB (Outside the Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light Communications), IrDA, LTE-D. Only the IP protocols are capable of running on each of these links and establish IP paths across them in an interoperable manner. Scenarios? ---------- There are a few scenarios exhibiting the need to communicate from one moving network to another nearby moving network. In the automobile space, the Cooperative Adaptive Cruise Control and Platooning features consider that vehicles close to each other exchange data describing their kinematic status. At the cross-roads, the moving network inside a vehicle exchanges data with the moving network in the red-light pole. Several public safety scenarios involve moving networks. Distinct organizations deploy different moving networks (in-vehicle, on-person) at an incident scene. These networks need to interoperate in order to more effectively understand and deal with the incident scene. In connected rail scenarios the moving network deployed in trains communicate with other moving networks at the cross-points. What kind of solutions? ----------------------- The current technical solutions considered to achieve moving network to nearby moving network communications are of two kinds: IP routing protocols for n-hop path management and 1-hop link-scoped IP protocol enhancements. The 1-hop link-scoped protocols include the protocols for route establishment involving ICMP Router Advertisements. The n-hop path management protocols include n-hop path establishment protocols (e.g. Babel, OSPF) and n-hop path search protocols (most notably AODV and derivates). In this proposed Working Group the focus is on 1-hop protocols, and leverage from other Working Groups for the n-hop situations. In some of the moving network applications the window of opportunity for exchanging data with the immediate infrastructure may be very short. For example, a car driving near a road-side unit may have only 5s to exchange with that RSU (depending on speed, RSU range and number). (ephemeral connections). What kind of requirements? -------------------------- The requirements for mechanisms for moving network to nearby moving network communications are focusing on low delays of the data paths, reduced number of messages for path establishment, application friendly, resilience to attacks, compatibility with DHCP and Mobile IP. In addition, some moving network to nearby moving network applications involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the 1-hop IP moving network to nearby moving netowrk mechanisms will need to gracefully support IP multicast. Due to the inherent characteristics of safety-related communications, all new moving network to nearby moving network mechanisms must afford authenticity and confidentiality where necessary. Dynamically establishing ephemeral communication paths between automobiles in public areas must offer privacy safeguards for the end users (passengers). Establishing 1-hop IP V2V paths must not break the existing on-board protocols and applications which communicate with the Internet, possibly via multiple radios. In a moving network deployed in an automobile, typically one exit point connects the moving network to other moving networks. However, in a more general manner (and to support reliability) any new mechanism of moving network to nearby moving network communications should support multi-homing: one router to use multiple interfaces towards outside the moving network, or multiple routers. Current version of Internet protocols ------------------------------------- The group will only work on IPv6 solutions. What SDOs may need this work? ----------------------------- The requirements and standards for moving network to nearby moving network communications, often involving IPv6, and novel V2V and V2Infra concepts, are developed mainly at ISO TC204 "Intelligent Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For Vehicle-to-Internet communications, 3GPP LTE and other cellular technologies represent the long-range connectivity method; for Vehicle-to-Vehicle communications, LTE Direct is currently specified, as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning. The IEEE developed a popular link for short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V communications. Work Items ---------- - use-cases for moving network to nearby moving network communications - Problem Statement for moving network to nearby moving network = communications including V2V, V2I and DNS. - Security and Privacy Requirements for moving network to nearby moving network communications - Solutions, which might include new protocols or extensions to existing protocols. With MIB. - IPv6-over foo, where foo is pertinent for moving network to nearby moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in the V2V domain, identifying which uses IP. Timeline -------- - _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, = pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php = =20 ------=_NextPart_000_0096_01D1962D.5FDC41A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

Thanks for your feedback. Do not get me wrong, I am an academic and = with my team, we also work on IP-based V2V and V2I, in particular = related to mobility management with DMM, but also in the context of = vehicular IoT.

 

I just have the feeling that people are perfectly aware of the fact = that IP can be used for V2V and V2I, but does not = =E2=80=98need=E2=80=99 to be used as other solutions already = perfectly fit their need. Listing papers will not change this awareness. =

 

So, as a complement to academic papers, it would help to be able to = pin-point which industrial activities are using or are strongly planning = (short term I mean) to use pure IPv6 system in vehicles. =

 

My feeling here is we have a different eco-system that the Automotive = industry (and automotive industry-related SDO)..more likely the IoT = industry=E2=80=A6and as such, we should not need to have the (direct) = involvement of automotive industry in the Charter. If we can make this = clear by an industry-based =E2=80=98survey=E2=80=99, that would help = make the case for the WG.

Btw, you can count on me your draft..we can add some IP-based V2V and = V2I for mobility management and also IoT.

 

Cheers,

 

J=C3=A9r=C3=B4me

 

From:= = Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com]
Sent: = Thursday 14 April 2016 03:22
To: J=C3=A9r=C3=B4me = H=C3=A4rri
Cc: Alexandre Petrescu; = its@ietf.org
Subject: Re: [its] charter = ITS

 

Hi = J=C3=A9r=C3=B4me,

I have = an opinion on your comment 5) below.

 

I = think that a list of high-quality papers about IP-based V2V and = V2I

can teach very useful = lessons to software designers of IP in V2V and = V2I

in the = industry.

Multiple people = are working for this IP-based V2V and = V2I 

(including = Sandra Cespedes and me) in academia = and 

more = people(including Nabil Benamar) are willing to work for this = area.

 

I = think we need to utilize the list of such papers as the ground for our = ITS group

through a WI. = Note that the draft of the list will include the summary of the = main 

ideas of the = papers.

 

For the industry current activities for this area, I = believe that you can share them

as references through our ITS mailing list rather than = through a WI. 

 

Could you join my team that are making efforts for a = list of such papers?

 

Thanks.

 

Best Regards,

Paul

 

 

On Thu, = Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr> = wrote:

Dear ITSers,  Dear Alex,

 

Here are some comments on the updated = charter:

1)      = Can we keep a reference to IEEE 802.11p, considering it does not = exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB = mode (and 10Mhz @5.9Ghz) of course.

 

2)      = Should we really keep C-ACC (or Platooning) in the charter explicitly = as use case, considering it is a seriously controversial aspect with = some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry = mentions traffic efficiency/infotainment applications, such as = in-signage applications...

a.     &nb= sp; We might have to aim at less controversial use cases to attract = automotive industries

 

3)      = One potential WI I could think of (rather a basic one): definition = of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive = context

a.     &nb= sp; To me, this is  a fundamental brick in the larger IETF WG ITS = house..

 

4)      = I would suggest to be more explicit in the foreseen challenges of = this WG, instead of mentioning general use case (which end up be = controversial)

a.     &nb= sp; Example: maintaining IPv6 connectivity in fast and asymmetric = wireless links; also under quickly changing topologies (actually = suggested by Dick Roy on the chat room)

b.      = Example: IPv6 addressing in link-local = scope..

c.     &nb= sp; Example: guaranteeing privacy in IPv6 moving networks = etc..

 

5)      = Before listing academic papers referring to IPv6 in vehicles, I would = suggest to first try to list commercial products/solutions that are in = vehicles and are using IPv6, possibly suffering from a silo limitations = (ex. restricted to a single technology, single use = case=E2=80=A6)

a.     &nb= sp; I think we need to get to products first, before academic = visions

 

My two cents..

 

Best Regards,

 

J=C3=A9r=C3=B4me

 

 

 

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of = Alexandre Petrescu
Sent: Wednesday 06 April 2016 = 23:45
To: its@ietf.org
Subject: [its] charter = ITS

 <= /o:p>

ITSers,

Please see below the = current charter.

- the two Problem Statements drafts V2V and V2I = joined, so there is less text in charter.
- added an Item on = "List of Research papers..."

Erik: did I understand you = correctly that there should be some item on discussing whether = link-local addressing is sufficient, whether prefix exchange is = necessary?

Dino: should LISP be included in the gap analysis = draft which includes C-ACC use-case?  OR should we separate a = dedicated I-D only with gap analysis including ND, MIP, AODVv2, = LISP?

Person from mediatek: is the 'zeroconf' need in the = vehicle-to-vehicle interface illustrated good enough by the words = "moving network to nearby moving network = communications"?  Or is it better to say "the 1-IP-hop = between nearby moving networks must be = self-configured"?

Nabil, Sandra: is it ok to have a working = group item "List of Research Papers for IP in V2V and V2I = communications"?

Other = comments?

Alex

--------------------------------------------= ----------------------

       &= nbsp;     ITS (name to = change)
          &n= bsp;        = Charter
          &n= bsp;  April 6th, = 2016
         http://ietf.org/mailman/listinfo/its


Int= elligent Transportation Systems = (its)
----------------------------------------
Current Status: WG = forming

Chairs:
   TBD

Assigned Area = Director:
   TBD

Mailing list
   = Address: its@ietf.org
   To Subscribe: https://www.ietf.org/mailman/listinfo/its
 =   Archive:
   http://www.ietf.org/mail-archive/web/its/current/mailli= st.html

Additional web page
   = TBD

Charter:

Goal
----
The goal of this group is to = standardize IP-based protocols for
establishing direct and secure = connectivity between moving networks,
some of which could be fixed = permanently or temporarily.

Moving Network to Nearby Moving = Network = Communications
------------------------------------------------------<= br>The group is concerned with all situations involving moving network = to
nearby moving network communications.  For example: = vehicle-to-vehicle
communications, nomadic user wearing a PAN and = communicating to a
homenet, vehicle-to-infrastructure communications, = wagon-to-wagon in a
train, or train-to-intersection = signalling.

Example from the automobile communications = space
------------------------------------------------
Automobiles = and vehicles of all types are increasingly connected to
the Internet, = either as vehicle-to-vehicle, vehicle-to-infra = or
vehicle-to-Internet.  Entertainment apps enhancing comfort, = reliable
data exchanges for road safety, and automated driving are = features
coming in automobiles to hit the roads from now to year = 2020.
Highlighting increased safety as an immediate result = of
hyper-connectivity applied to vehicles, public authorities = worldwide
are increasingly mandating secure communication = technology
requirements in vehicles.

Emergency apps for new = instrumented ambulances carry many benefits
both to the users and to = society in general.

Why IP?
-------
Today, there are = several deployed Vehicle-to-Internet technologies,
including car = tethering through driver's cellular smartphone.
However, = Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communications are = still being developed.  To improve on a situation
of = link-specific data exchanges, and enable independent application
sets = to share the same links, IP data exchanges are needed.  = Enabling
IP communication between vehicles (V2V), and between = vehicles and the
immediate infrastructure (V2I), will provide (0) = ability to reach the
rest of the world on the Internet (1) short and = deterministic delays,
(2) fast forwarding through scalable paths of = routers, (3) ease of
reuse of existing Internet applications in a = vehicular environment.

Moving network to nearby moving network = communications involve link
layers such as: 802.11p OCB (Outside the = Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC = (Visible Light
Communications), IrDA, LTE-D.  Only the IP = protocols are capable of
running on each of these links and establish = IP paths across them in
an interoperable = manner.

Scenarios?
----------
There are a few scenarios = exhibiting the need to communicate from one
moving network to another = nearby moving network.

In the automobile space, the Cooperative = Adaptive Cruise Control and
Platooning features consider that = vehicles close to each other
exchange data describing their kinematic = status.  At the cross-roads,
the moving network inside a vehicle = exchanges data with the moving
network in the red-light = pole.

Several public safety scenarios involve moving = networks.  Distinct
organizations deploy different moving = networks (in-vehicle, on-person)
at an incident scene.  These = networks need to interoperate in order to
more effectively understand = and deal with the incident scene.

In connected rail scenarios the = moving network deployed in trains
communicate with other moving = networks at the cross-points.

What kind of = solutions?
-----------------------
The current technical solutions = considered to achieve moving network
to nearby moving network = communications are of two kinds: IP routing
protocols for n-hop path = management and 1-hop link-scoped IP protocol
enhancements.  The = 1-hop link-scoped protocols include the protocols
for route = establishment involving ICMP Router Advertisements.  The
n-hop = path management protocols include n-hop path establishment
protocols = (e.g. Babel, OSPF) and n-hop path search protocols (most
notably AODV = and derivates).

In this proposed Working Group the focus is on = 1-hop protocols, and
leverage from other Working Groups for the n-hop = situations.

In some of the moving network applications the window = of opportunity
for exchanging data with the immediate infrastructure = may be very
short.  For example, a car driving near a road-side = unit may have only
5s to exchange with that RSU (depending on speed, = RSU range and
number). (ephemeral connections).

What kind of = requirements?
--------------------------
The requirements for = mechanisms for moving network to nearby moving
network communications = are focusing on low delays of the data paths,
reduced number of = messages for path establishment, application
friendly, resilience to = attacks, compatibility with DHCP and Mobile
IP.

In addition, = some moving network to nearby moving network applications
involve IP = multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP = moving network to nearby moving netowrk mechanisms will need
to = gracefully support IP multicast.

Due to the inherent = characteristics of safety-related communications,
all new moving = network to nearby moving network mechanisms must afford
authenticity = and confidentiality where necessary.  Dynamically
establishing = ephemeral communication paths between automobiles in
public areas = must offer privacy safeguards for the end = users
(passengers).

Establishing 1-hop IP V2V paths must not = break the existing on-board
protocols and applications which = communicate with the Internet,
possibly via multiple = radios.

In a moving network deployed in an automobile, typically = one exit
point connects the moving network to other moving = networks.  However,
in a more general manner (and to support = reliability) any new
mechanism of moving network to nearby moving = network communications
should support multi-homing: one router to use = multiple interfaces
towards outside the moving network, or multiple = routers.

Current version of Internet = protocols
-------------------------------------
The group will = only work on IPv6 solutions.

What SDOs may need this = work?
-----------------------------
The requirements and standards = for moving network to nearby moving
network communications, often = involving IPv6, and novel V2V and
V2Infra concepts, are developed = mainly at ISO TC204 "Intelligent
Transport Systems", 3GPP, = ETSI, NHTSA and IEEE.  For
Vehicle-to-Internet communications, = 3GPP LTE and other cellular
technologies represent the long-range = connectivity method; for
Vehicle-to-Vehicle communications, LTE = Direct is currently specified,
as well as OCB mode of IEEE = 802.11.  Several use-cases exhibit a need
for IPv6 data = exchanges between vehicles: ETSI's Cooperative Adaptive
Cruise = Control and Platooning.  The IEEE developed a popular link = for
short-range communications - IEEE 802.11p "WAVE".  = The NHTSA wrote a
set of requirements for V2V = communications.

Work Items
----------
- use-cases for = moving network to nearby moving network communications
- Problem = Statement for moving network to nearby moving network = communications
  including V2V, V2I and DNS.
- Security and = Privacy Requirements for moving network to
  nearby moving = network communications
- Solutions, which might include new protocols = or extensions to
  existing protocols.  With MIB.
- = IPv6-over foo, where foo is pertinent for moving network to = nearby
  moving network communications (e.g. 802.11 OCB, VLC, = LTE-D, 802.11ad)
- List of Research Papers in the V2V domain, = identifying which uses = IP.

Timeline
--------
-


______________________________________= _________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its



 

-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant = Professor
Department of Software
Sungkyunkwan = University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php

------=_NextPart_000_0096_01D1962D.5FDC41A0-- From nobody Thu Apr 14 00:36:59 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A1912D9E2 for ; Thu, 14 Apr 2016 00:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHLB5ZLjHGbQ for ; Thu, 14 Apr 2016 00:36:52 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E7412D968 for ; Thu, 14 Apr 2016 00:36:51 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id d68so95636002ywe.1 for ; Thu, 14 Apr 2016 00:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nt/xLPdooj4r+dO4WXfQreq/80g+sd4xRkp3qt7ydTo=; b=B+5LPt9N185upb47APoXOUfK4X4tikCBEL1gwRGZZ0dnXjcSwnLVSHzSawqqG/3cQ8 8pNY0+E7PDNkO8KICf1jJryTzYylBJdZIFrtLDOtcX9fEDBw99XPb3u3BH6swk4e2tsX V/9Vkqk/+FG7gTT5DLPCc5tISwYuYoTBZXL31GWhAnNnfyd8la8rmSWmHruVrepA4zAh gTgtWcZkPo28xhs6uQi+LcblXejQi2wTfj7mdRuajYkhS3nOTZz0S0Ap5H692pSFNX7r FGfmv5UVZXQdV+Yuo40Z1f8/b4bfqinz4uoC0sNJ1aSccP6+Mk3F4gbOE36vZLsVBYOU X5gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nt/xLPdooj4r+dO4WXfQreq/80g+sd4xRkp3qt7ydTo=; b=XGyXwjbossAKqFaNNvh0yWm4Q6CTyY6pGxChNGGEQRFyrguCxykkq8lhXM82VlshEr KwpkQnzdqhCxmr0KwqW7mr5QQd2CbNuKH/sKX2XTCXupifUH0I0lkxFqrQdrDjU7/4fQ wot1fGP47fCOU51VuiBGIsf/EPxfc2oEj08Cm998g+mdtZruzBiZRzVVtGG3P0pGZM8T MJK4GX/NYA/93cohNeJnw/+D3xNGoprrmmwMzBM0tolR31u0gLS2NaqBIE8byEd9poor 6XUOJ3HSxq6NKt4jsw/HiDL60AmnD6k794mcseddfGUWjXpe1UsNcoi9Lv9KOCEcHDuV jrfA== X-Gm-Message-State: AOPr4FXkoMYxNByAm4d3CWNcBLdR+NL9VIe9a7qerJEFsgaHB661FddENI1vMJgBhNkqlp8jtQaSbjSyJaJZmQ== X-Received: by 10.129.107.67 with SMTP id g64mr7264880ywc.19.1460619411105; Thu, 14 Apr 2016 00:36:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.4.22 with HTTP; Thu, 14 Apr 2016 00:36:21 -0700 (PDT) In-Reply-To: <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> From: "Mr. Jaehoon Paul Jeong" Date: Thu, 14 Apr 2016 16:36:21 +0900 Message-ID: To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= Content-Type: multipart/alternative; boundary=001a114170a826ae5205306cf552 Archived-At: Cc: Alexandre Petrescu , its@ietf.org Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 07:36:56 -0000 --001a114170a826ae5205306cf552 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable J=C3=A9r=C3=B4me, I missed that you are also an academic person. I got it :-) I understand your points for industry activity related to vehicular networking. Your observation seems true. BTW, I will invite you to my team for the draft for a list of academic papers for V2V and V2I by a personal message. Thanks. Paul On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri wrote: > Hi Paul, > > > > Thanks for your feedback. Do not get me wrong, I am an academic and with > my team, we also work on IP-based V2V and V2I, in particular related to > mobility management with DMM, but also in the context of vehicular IoT. > > > > I just have the feeling that people are perfectly aware of the fact that > IP *can* be used for V2V and V2I, but does not =E2=80=98*need*=E2=80=99 t= o be used as > other solutions already perfectly fit their need. Listing papers will not > change this awareness. > > > > So, as a complement to academic papers, it would help to be able to > pin-point which industrial activities are using or are strongly planning > (short term I mean) to use pure IPv6 system in vehicles. > > > > My feeling here is we have a different eco-system that the Automotive > industry (and automotive industry-related SDO)..more likely the IoT > industry=E2=80=A6and as such, we should not need to have the (direct) inv= olvement > of automotive industry in the Charter. If we can make this clear by an > industry-based =E2=80=98survey=E2=80=99, that would help make the case fo= r the WG. > > Btw, you can count on me your draft..we can add some IP-based V2V and V2I > for mobility management and also IoT. > > > > Cheers, > > > > J=C3=A9r=C3=B4me > > > > *From:* Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] > *Sent:* Thursday 14 April 2016 03:22 > *To:* J=C3=A9r=C3=B4me H=C3=A4rri > *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [its] charter ITS > > > > Hi J=C3=A9r=C3=B4me, > > I have an opinion on your comment 5) below. > > > > I think that a list of high-quality papers about IP-based V2V and V2I > > can teach very useful lessons to software designers of IP in V2V and V2I > > in the industry. > > Multiple people are working for this IP-based V2V and V2I > > (including Sandra Cespedes and me) in academia and > > more people(including Nabil Benamar) are willing to work for this area. > > > > I think we need to utilize the list of such papers as the ground for our > ITS group > > through a WI. Note that the draft of the list will include the summary of > the main > > ideas of the papers. > > > > For the industry current activities for this area, I believe that you can > share them > > as references through our ITS mailing list rather than through a WI. > > > > Could you join my team that are making efforts for a list of such papers? > > > > Thanks. > > > > Best Regards, > > Paul > > > > > > On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri > wrote: > > Dear ITSers, Dear Alex, > > > > Here are some comments on the updated charter: > > 1) Can we keep a reference to IEEE 802.11p, considering it does not > exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mo= de > (and 10Mhz @5.9Ghz) of course. > > > > 2) Should we really keep C-ACC (or Platooning) in the charter > explicitly as use case, considering it is a seriously controversial aspec= t > with some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry > mentions traffic efficiency/infotainment applications, such as in-signage > applications... > > a. We might have to aim at less controversial use cases to attract > automotive industries > > > > 3) One potential WI I could think of (rather a basic one): *definiti= on > of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive context* > > a. To me, this is a fundamental brick in the larger IETF WG ITS > house.. > > > > 4) I would suggest to be more explicit in the foreseen challenges of > this WG, instead of mentioning general use case (which end up be > controversial) > > a. Example: maintaining IPv6 connectivity in fast and asymmetric > wireless links; also under quickly changing topologies (actually suggeste= d > by Dick Roy on the chat room) > > b. Example: IPv6 addressing in link-local scope.. > > c. Example: guaranteeing privacy in IPv6 moving networks etc.. > > > > 5) Before listing academic papers referring to IPv6 in vehicles, I > would suggest to first try to list commercial products/solutions that are > in vehicles and are using IPv6, possibly suffering from a silo limitation= s > (ex. restricted to a single technology, single use case=E2=80=A6) > > a. I think we need to get to products first, before academic vision= s > > > > My two cents.. > > > > Best Regards, > > > > J=C3=A9r=C3=B4me > > > > > > > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre > Petrescu > *Sent:* Wednesday 06 April 2016 23:45 > *To:* its@ietf.org > *Subject:* [its] charter ITS > > > > ITSers, > > Please see below the current charter. > > - the two Problem Statements drafts V2V and V2I joined, so there is less > text in charter. > - added an Item on "List of Research papers..." > > Erik: did I understand you correctly that there should be some item on > discussing whether link-local addressing is sufficient, whether prefix > exchange is necessary? > > Dino: should LISP be included in the gap analysis draft which includes > C-ACC use-case? OR should we separate a dedicated I-D only with gap > analysis including ND, MIP, AODVv2, LISP? > > Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle > interface illustrated good enough by the words "moving network to nearby > moving network communications"? Or is it better to say "the 1-IP-hop > between nearby moving networks must be self-configured"? > > Nabil, Sandra: is it ok to have a working group item "List of Research > Papers for IP in V2V and V2I communications"? > > Other comments? > > Alex > > ------------------------------------------------------------------ > > ITS (name to change) > Charter > April 6th, 2016 > http://ietf.org/mailman/listinfo/its > > > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming > > Chairs: > TBD > > Assigned Area Director: > TBD > > Mailing list > Address: its@ietf.org > 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: > > Goal > ---- > The goal of this group is to standardize IP-based protocols for > establishing direct and secure connectivity between moving networks, > some of which could be fixed permanently or temporarily. > > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving network to > nearby moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > train, or train-to-intersection signalling. > > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to > the Internet, either as vehicle-to-vehicle, vehicle-to-infra or > vehicle-to-Internet. Entertainment apps enhancing comfort, reliable > data exchanges for road safety, and automated driving are features > coming in automobiles to hit the roads from now to year 2020. > Highlighting increased safety as an immediate result of > hyper-connectivity applied to vehicles, public authorities worldwide > are increasingly mandating secure communication technology > requirements in vehicles. > > Emergency apps for new instrumented ambulances carry many benefits > both to the users and to society in general. > > Why IP? > ------- > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. > However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure > communications are still being developed. To improve on a situation > of link-specific data exchanges, and enable independent application > sets to share the same links, IP data exchanges are needed. Enabling > IP communication between vehicles (V2V), and between vehicles and the > immediate infrastructure (V2I), will provide (0) ability to reach the > rest of the world on the Internet (1) short and deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) ease of > reuse of existing Internet applications in a vehicular environment. > > Moving network to nearby moving network communications involve link > layers such as: 802.11p OCB (Outside the Context of a Basic Service > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light > Communications), IrDA, LTE-D. Only the IP protocols are capable of > running on each of these links and establish IP paths across them in > an interoperable manner. > > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate from one > moving network to another nearby moving network. > > In the automobile space, the Cooperative Adaptive Cruise Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the cross-roads, > the moving network inside a vehicle exchanges data with the moving > network in the red-light pole. > > Several public safety scenarios involve moving networks. Distinct > organizations deploy different moving networks (in-vehicle, on-person) > at an incident scene. These networks need to interoperate in order to > more effectively understand and deal with the incident scene. > > In connected rail scenarios the moving network deployed in trains > communicate with other moving networks at the cross-points. > > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol > enhancements. The 1-hop link-scoped protocols include the protocols > for route establishment involving ICMP Router Advertisements. The > n-hop path management protocols include n-hop path establishment > protocols (e.g. Babel, OSPF) and n-hop path search protocols (most > notably AODV and derivates). > > In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations. > > In some of the moving network applications the window of opportunity > for exchanging data with the immediate infrastructure may be very > short. For example, a car driving near a road-side unit may have only > 5s to exchange with that RSU (depending on speed, RSU range and > number). (ephemeral connections). > > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to nearby moving > network communications are focusing on low delays of the data paths, > reduced number of messages for path establishment, application > friendly, resilience to attacks, compatibility with DHCP and Mobile > IP. > > In addition, some moving network to nearby moving network applications > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the > 1-hop IP moving network to nearby moving netowrk mechanisms will need > to gracefully support IP multicast. > > Due to the inherent characteristics of safety-related communications, > all new moving network to nearby moving network mechanisms must afford > authenticity and confidentiality where necessary. Dynamically > establishing ephemeral communication paths between automobiles in > public areas must offer privacy safeguards for the end users > (passengers). > > Establishing 1-hop IP V2V paths must not break the existing on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. > > In a moving network deployed in an automobile, typically one exit > point connects the moving network to other moving networks. However, > in a more general manner (and to support reliability) any new > mechanism of moving network to nearby moving network communications > should support multi-homing: one router to use multiple interfaces > towards outside the moving network, or multiple routers. > > Current version of Internet protocols > ------------------------------------- > The group will only work on IPv6 solutions. > > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to nearby moving > network communications, often involving IPv6, and novel V2V and > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For > Vehicle-to-Internet communications, 3GPP LTE and other cellular > technologies represent the long-range connectivity method; for > Vehicle-to-Vehicle communications, LTE Direct is currently specified, > as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need > for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive > Cruise Control and Platooning. The IEEE developed a popular link for > short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a > set of requirements for V2V communications. > > Work Items > ---------- > - use-cases for moving network to nearby moving network communications > - Problem Statement for moving network to nearby moving network > communications > including V2V, V2I and DNS. > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Solutions, which might include new protocols or extensions to > existing protocols. With MIB. > - IPv6-over foo, where foo is pertinent for moving network to nearby > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) > - List of Research Papers in the V2V domain, identifying which uses IP. > > Timeline > -------- > - > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a114170a826ae5205306cf552 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
J=C3=A9r=C3=B4me,
I missed that you are also an ac= ademic person.
I got it :-)

I understand= your points for industry activity related to vehicular networking.
Your observation seems true.

BTW, I will invite= you to my team for the draft for a list of academic papers for V2V and V2I=
by a personal message.

Thanks.

Paul

On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4r= ri <jerome.haerri@eurecom.fr> wrote:
<= p class=3D"MsoNormal">Hi Paul,

=C2=A0

Thanks for y= our feedback. Do not get me wrong, I am an academic and with my team, we al= so work on IP-based V2V and V2I, in particular related to mobility manageme= nt with DMM, but also in the context of vehicular IoT.

=C2=A0=

I just have th= e feeling that people are perfectly aware of the fact that IP can be= used for V2V and V2I, but does not =E2=80=98need=E2=80=99 to be use= d as other solutions already perfectly fit their need. Listing papers will = not change this awareness.

= =C2=A0

So, as a complement to academic papers, it= would help to be able to pin-point which industrial activities are using o= r are strongly planning (short term I mean) to use pure IPv6 system in vehi= cles.

=C2=A0

My feeling here is we have a different eco-system that the Auto= motive industry (and automotive industry-related SDO)..more likely the IoT = industry=E2=80=A6and as such, we should not need to have the (direct) invol= vement of automotive industry in the Charter. If we can make this clear by = an industry-based =E2=80=98survey=E2=80=99, that would help make the case f= or the WG.

Btw, you can count on me your draft..we can add some IP-based V2= V and V2I for mobility management and also IoT.

=C2=A0<= /p>

Cheers,<= /span>

=C2=A0

J=C3=A9r= =C3=B4me

=C2=A0

From: Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] =
Sent: Thursday 14 April 2016 03:22
To: J=C3=A9r=C3=B4m= e H=C3=A4rri
Cc: Alexandre Petrescu; its@ietf.org
Subject: = Re: [its] charter ITS

=C2=A0

Hi J=C3=A9r=C3=B4= me,

I have an opinion on your comment 5) below.

=

=C2=A0

I think that a list of high-quality papers about IP-based V2V and V2I=

can teach very useful l= essons to software designers of IP in V2V and V2I

in the industry.

Multiple people are working for this IP-based V2V and V2= I=C2=A0

(including Sandr= a Cespedes and me) in academia and=C2=A0

more people(including Nabil Benamar) are willing to work f= or this area.

=C2= =A0

I think we need to utilize = the list of such papers as the ground for our ITS group

through a WI. Note that the draft of the li= st will include the summary of the main=C2=A0

<= p class=3D"MsoNormal">ideas of the papers.

=C2=A0

For the industry current activities for this area, I believe that you can= share them

as reference= s through our ITS mailing list rather than through a WI.=C2=A0

=C2=A0

<= p class=3D"MsoNormal">Could you join my team that are making efforts for a = list of such papers?

= =C2=A0

Thanks.

=C2=A0

<= p class=3D"MsoNormal">Best Regards,

Paul

=C2=A0

=C2=A0

On Thu, Apr 7, 20= 16 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr> wrote:

Dear ITSers, =C2=A0Dear Alex,

=C2=A0

Here are some comments on the updated c= harter:

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Can we keep a reference to IEEE 802.11p, co= nsidering it does not exist anymore? It is now fully integrated into IEEE 8= 02.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of course. =

=C2=A0

2)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Should we = really keep C-ACC (or Platooning) in the charter explicitly as use case, co= nsidering it is a seriously controversial aspect with some SDOs (ex. In Aut= omotive SDOs)? In the ISO presentation, Thierry mentions traffic efficiency= /infotainment applications, such as in-signage applications...

a.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 We might have to aim at less= controversial use cases to attract automotive industries<= /u>

=C2=A0

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 One potential WI I could think of (rather a basic one= ): definition of a vehicular wireless =E2=80=98link=E2=80=99 in an autom= otive context

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

4)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I would suggest to be more explicit in the foreseen challenges = of this WG, instead of mentioning general use case (which end up be controv= ersial)

a.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Example= : maintaining IPv6 connectivity in fast and asymmetric wireless links; also= under quickly changing topologies (actually suggested by Dick Roy on the c= hat room)

b.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Example: I= Pv6 addressing in link-local scope..

c.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Example: guaranteeing privacy in IPv6 moving networks = etc..

=C2=A0

5)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Before listing academic papers referring to IPv6 in vehicle= s, I would suggest to first try to list commercial products/solutions that = are in vehicles and are using IPv6, possibly suffering from a silo limitati= ons (ex. restricted to a single technology, single use case=E2=80=A6)

a.=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 I think we need to = get to products first, before academic visions

=C2=A0

My two cents..

=C2=A0

Bes= t Regards,

=C2=A0

J=C3=A9r=C3=B4me

=C2=A0

=C2=A0

=C2=A0

=

From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu
Sen= t: Wednesday 06 April 2016 23:45
To: its@ietf.org
Subject: [its] charter= ITS

= =C2=A0

ITSers,

Pleas= e see below the current charter.

- the two Problem Statements drafts= V2V and V2I joined, so there is less text in charter.
- added an Item o= n "List of Research papers..."

Erik: did I understand you = correctly that there should be some item on discussing whether link-local a= ddressing is sufficient, whether prefix exchange is necessary?

Dino:= should LISP be included in the gap analysis draft which includes C-ACC use= -case?=C2=A0 OR should we separate a dedicated I-D only with gap analysis i= ncluding ND, MIP, AODVv2, LISP?

Person from mediatek: is the 'ze= roconf' need in the vehicle-to-vehicle interface illustrated good enoug= h by the words "moving network to nearby moving network communications= "?=C2=A0 Or is it better to say "the 1-IP-hop between nearby movi= ng networks must be self-configured"?

Nabil, Sandra: is it ok t= o have a working group item "List of Research Papers for IP in V2V and= V2I communications"?

Other comments?

Alex

------= ------------------------------------------------------------

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ITS (nam= e to change)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Charter
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 April 6th, 201= 6
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://ietf.org/mailman/listi= nfo/its


Intelligent Transportation Systems (its)
--------= --------------------------------
Current Status: WG forming

Chair= s:
=C2=A0=C2=A0 TBD

Assigned Area Director:
=C2=A0=C2=A0 TBD
Mailing list
=C2=A0=C2=A0 Address: its@ietf.org
=C2=A0=C2=A0 To Subscribe: https://ww= w.ietf.org/mailman/listinfo/its
=C2=A0=C2=A0 Archive:
=C2=A0=C2= =A0 http://www.ietf.org/mail-archive/web/its/current/mail= list.html

Additional web page
=C2=A0=C2=A0 TBD

Charter= :

Goal
----
The goal of this group is to standardize IP-based = protocols for
establishing direct and secure connectivity between moving= networks,
some of which could be fixed permanently or temporarily.
<= br>Moving Network to Nearby Moving Network Communications
--------------= ----------------------------------------
The group is concerned with all= situations involving moving network to
nearby moving network communicat= ions.=C2=A0 For example: vehicle-to-vehicle
communications, nomadic user= wearing a PAN and communicating to a
homenet, vehicle-to-infrastructure= communications, wagon-to-wagon in a
train, or train-to-intersection sig= nalling.

Example from the automobile communications space
-------= -----------------------------------------
Automobiles and vehicles of al= l types are increasingly connected to
the Internet, either as vehicle-to= -vehicle, vehicle-to-infra or
vehicle-to-Internet.=C2=A0 Entertainment a= pps enhancing comfort, reliable
data exchanges for road safety, and auto= mated driving are features
coming in automobiles to hit the roads from n= ow to year 2020.
Highlighting increased safety as an immediate result of=
hyper-connectivity applied to vehicles, public authorities worldwideare increasingly mandating secure communication technology
requirements= in vehicles.

Emergency apps for new instrumented ambulances carry m= any benefits
both to the users and to society in general.

Why IP?=
-------
Today, there are several deployed Vehicle-to-Internet techno= logies,
including car tethering through driver's cellular smartphone= .
However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communica= tions are still being developed.=C2=A0 To improve on a situation
of link= -specific data exchanges, and enable independent application
sets to sha= re the same links, IP data exchanges are needed.=C2=A0 Enabling
IP commu= nication between vehicles (V2V), and between vehicles and the
immediate = infrastructure (V2I), will provide (0) ability to reach the
rest of the = world on the Internet (1) short and deterministic delays,
(2) fast forwa= rding through scalable paths of routers, (3) ease of
reuse of existing I= nternet applications in a vehicular environment.

Moving network to n= earby moving network communications involve link
layers such as: 802.11p= OCB (Outside the Context of a Basic Service
Set), 802.15.4 with 6lowpan= , 802.11ac, VLC (Visible Light
Communications), IrDA, LTE-D.=C2=A0 Only = the IP protocols are capable of
running on each of these links and estab= lish IP paths across them in
an interoperable manner.

Scenarios?<= br>----------
There are a few scenarios exhibiting the need to communica= te from one
moving network to another nearby moving network.

In t= he automobile space, the Cooperative Adaptive Cruise Control and
Platoon= ing features consider that vehicles close to each other
exchange data de= scribing their kinematic status.=C2=A0 At the cross-roads,
the moving ne= twork inside a vehicle exchanges data with the moving
network in the red= -light pole.

Several public safety scenarios involve moving networks= .=C2=A0 Distinct
organizations deploy different moving networks (in-vehi= cle, on-person)
at an incident scene.=C2=A0 These networks need to inter= operate in order to
more effectively understand and deal with the incide= nt scene.

In connected rail scenarios the moving network deployed in= trains
communicate with other moving networks at the cross-points.
<= br>What kind of solutions?
-----------------------
The current techni= cal solutions considered to achieve moving network
to nearby moving netw= ork communications are of two kinds: IP routing
protocols for n-hop path= management and 1-hop link-scoped IP protocol
enhancements.=C2=A0 The 1-= hop link-scoped protocols include the protocols
for route establishment = involving ICMP Router Advertisements.=C2=A0 The
n-hop path management pr= otocols include n-hop path establishment
protocols (e.g. Babel, OSPF) an= d n-hop path search protocols (most
notably AODV and derivates).

= In this proposed Working Group the focus is on 1-hop protocols, and
leve= rage from other Working Groups for the n-hop situations.

In some of = the moving network applications the window of opportunity
for exchanging= data with the immediate infrastructure may be very
short.=C2=A0 For exa= mple, a car driving near a road-side unit may have only
5s to exchange w= ith that RSU (depending on speed, RSU range and
number). (ephemeral conn= ections).

What kind of requirements?
--------------------------The requirements for mechanisms for moving network to nearby moving
ne= twork communications are focusing on low delays of the data paths,
reduc= ed number of messages for path establishment, application
friendly, resi= lience to attacks, compatibility with DHCP and Mobile
IP.

In addi= tion, some moving network to nearby moving network applications
involve = IP multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP mo= ving network to nearby moving netowrk mechanisms will need
to gracefully= support IP multicast.

Due to the inherent characteristics of safety= -related communications,
all new moving network to nearby moving network= mechanisms must afford
authenticity and confidentiality where necessary= .=C2=A0 Dynamically
establishing ephemeral communication paths between a= utomobiles in
public areas must offer privacy safeguards for the end use= rs
(passengers).

Establishing 1-hop IP V2V paths must not break t= he existing on-board
protocols and applications which communicate with t= he Internet,
possibly via multiple radios.

In a moving network de= ployed in an automobile, typically one exit
point connects the moving ne= twork to other moving networks.=C2=A0 However,
in a more general manner = (and to support reliability) any new
mechanism of moving network to near= by moving network communications
should support multi-homing: one router= to use multiple interfaces
towards outside the moving network, or multi= ple routers.

Current version of Internet protocols
--------------= -----------------------
The group will only work on IPv6 solutions.
<= br>What SDOs may need this work?
-----------------------------
The re= quirements and standards for moving network to nearby moving
network com= munications, often involving IPv6, and novel V2V and
V2Infra concepts, a= re developed mainly at ISO TC204 "Intelligent
Transport Systems&quo= t;, 3GPP, ETSI, NHTSA and IEEE.=C2=A0 For
Vehicle-to-Internet communicat= ions, 3GPP LTE and other cellular
technologies represent the long-range = connectivity method; for
Vehicle-to-Vehicle communications, LTE Direct i= s currently specified,
as well as OCB mode of IEEE 802.11.=C2=A0 Several= use-cases exhibit a need
for IPv6 data exchanges between vehicles: ETSI= 's Cooperative Adaptive
Cruise Control and Platooning.=C2=A0 The IEE= E developed a popular link for
short-range communications - IEEE 802.11p= "WAVE".=C2=A0 The NHTSA wrote a
set of requirements for V2V c= ommunications.

Work Items
----------
- use-cases for moving ne= twork to nearby moving network communications
- Problem Statement for mo= ving network to nearby moving network communications
=C2=A0 including V2= V, V2I and DNS.
- Security and Privacy Requirements for moving network t= o
=C2=A0 nearby moving network communications
- Solutions, which migh= t include new protocols or extensions to
=C2=A0 existing protocols.=C2= =A0 With MIB.
- IPv6-over foo, where foo is pertinent for moving network= to nearby
=C2=A0 moving network communications (e.g. 802.11 OCB, VLC, L= TE-D, 802.11ad)
- List of Research Papers in the V2V domain, identifying= which uses IP.

Timeline
--------
-


_______________________________________________
its mailing listits@ietf.org
https:/= /www.ietf.org/mailman/listinfo/its



=C2=A0

--

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaeh= oon (Paul) Jeong, Ph.D.
Assistant Professor
Department of SoftwareSungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,= =C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php

<= /div>


--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DMr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of So= ftware
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.= com,=C2=A0pauljeong@skku.edu
Personal Homepa= ge: http://iotlab.skku.edu/people-jaehoon-jeong.php
<= /div>
--001a114170a826ae5205306cf552-- From nobody Thu Apr 14 00:43:06 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BA612DF05 for ; Thu, 14 Apr 2016 00:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlqLcRcH3Ip7 for ; Thu, 14 Apr 2016 00:43:00 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id 9584F12DF10 for ; Thu, 14 Apr 2016 00:42:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,484,1454972400"; d="scan'208,217";a="3675728" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 14 Apr 2016 09:42:57 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 4EB24488; Thu, 14 Apr 2016 09:42:57 +0200 (CEST) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Mr. Jaehoon Paul Jeong'" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> In-Reply-To: Date: Thu, 14 Apr 2016 09:42:57 +0200 Organization: EURECOM Message-ID: <00eb01d19621$430b0d60$c9212820$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EC_01D19632.06989850" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt54qCPzaRhlgKe35lrbFRjfOAYQFS/geMAQE6Hj0B9Z2NrAFvPFpVoCKqFmA= Content-Language: en-us Archived-At: Cc: 'Alexandre Petrescu' , its@ietf.org Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 07:43:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EC_01D19632.06989850 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Paul, =20 Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of IP = V2V but not see the need (so far), I referred to the automotive SDOs = (led by automotive industries)=E2=80=A6, although there are always = =E2=80=98minority reports=E2=80=99 J=20 =20 Cheers, =20 J=C3=A9r=C3=B4me =20 From: Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com]=20 Sent: Thursday 14 April 2016 09:36 To: J=C3=A9r=C3=B4me H=C3=A4rri Cc: Alexandre Petrescu; its@ietf.org Subject: Re: [its] charter ITS =20 J=C3=A9r=C3=B4me, I missed that you are also an academic person. I got it :-) =20 I understand your points for industry activity related to vehicular = networking. Your observation seems true. =20 BTW, I will invite you to my team for the draft for a list of academic = papers for V2V and V2I by a personal message. =20 Thanks. =20 Paul =20 On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri = wrote: Hi Paul, =20 Thanks for your feedback. Do not get me wrong, I am an academic and with = my team, we also work on IP-based V2V and V2I, in particular related to = mobility management with DMM, but also in the context of vehicular IoT.=20 =20 I just have the feeling that people are perfectly aware of the fact that = IP can be used for V2V and V2I, but does not =E2=80=98need=E2=80=99 to = be used as other solutions already perfectly fit their need. Listing = papers will not change this awareness.=20 =20 So, as a complement to academic papers, it would help to be able to = pin-point which industrial activities are using or are strongly planning = (short term I mean) to use pure IPv6 system in vehicles.=20 =20 My feeling here is we have a different eco-system that the Automotive = industry (and automotive industry-related SDO)..more likely the IoT = industry=E2=80=A6and as such, we should not need to have the (direct) = involvement of automotive industry in the Charter. If we can make this = clear by an industry-based =E2=80=98survey=E2=80=99, that would help = make the case for the WG. Btw, you can count on me your draft..we can add some IP-based V2V and = V2I for mobility management and also IoT. =20 Cheers, =20 J=C3=A9r=C3=B4me =20 From: Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com]=20 Sent: Thursday 14 April 2016 03:22 To: J=C3=A9r=C3=B4me H=C3=A4rri Cc: Alexandre Petrescu; its@ietf.org Subject: Re: [its] charter ITS =20 Hi J=C3=A9r=C3=B4me, I have an opinion on your comment 5) below. =20 I think that a list of high-quality papers about IP-based V2V and V2I can teach very useful lessons to software designers of IP in V2V and V2I in the industry. Multiple people are working for this IP-based V2V and V2I=20 (including Sandra Cespedes and me) in academia and=20 more people(including Nabil Benamar) are willing to work for this area. =20 I think we need to utilize the list of such papers as the ground for our = ITS group through a WI. Note that the draft of the list will include the summary = of the main=20 ideas of the papers. =20 For the industry current activities for this area, I believe that you = can share them as references through our ITS mailing list rather than through a WI.=20 =20 Could you join my team that are making efforts for a list of such = papers? =20 Thanks. =20 Best Regards, Paul =20 =20 On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri = wrote: Dear ITSers, Dear Alex, =20 Here are some comments on the updated charter: 1) Can we keep a reference to IEEE 802.11p, considering it does not = exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB = mode (and 10Mhz @5.9Ghz) of course.=20 =20 2) Should we really keep C-ACC (or Platooning) in the charter = explicitly as use case, considering it is a seriously controversial = aspect with some SDOs (ex. In Automotive SDOs)? In the ISO presentation, = Thierry mentions traffic efficiency/infotainment applications, such as = in-signage applications... a. We might have to aim at less controversial use cases to attract = automotive industries =20 3) One potential WI I could think of (rather a basic one): = definition of a vehicular wireless =E2=80=98link=E2=80=99 in an = automotive context a. To me, this is a fundamental brick in the larger IETF WG ITS = house.. =20 4) I would suggest to be more explicit in the foreseen challenges = of this WG, instead of mentioning general use case (which end up be = controversial) a. Example: maintaining IPv6 connectivity in fast and asymmetric = wireless links; also under quickly changing topologies (actually = suggested by Dick Roy on the chat room) b. Example: IPv6 addressing in link-local scope.. c. Example: guaranteeing privacy in IPv6 moving networks etc.. =20 5) Before listing academic papers referring to IPv6 in vehicles, I = would suggest to first try to list commercial products/solutions that = are in vehicles and are using IPv6, possibly suffering from a silo = limitations (ex. restricted to a single technology, single use = case=E2=80=A6) a. I think we need to get to products first, before academic = visions =20 My two cents.. =20 Best Regards, =20 J=C3=A9r=C3=B4me =20 =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Wednesday 06 April 2016 23:45 To: its@ietf.org Subject: [its] charter ITS =20 ITSers, Please see below the current charter. - the two Problem Statements drafts V2V and V2I joined, so there is less = text in charter. - added an Item on "List of Research papers..." Erik: did I understand you correctly that there should be some item on = discussing whether link-local addressing is sufficient, whether prefix = exchange is necessary? Dino: should LISP be included in the gap analysis draft which includes = C-ACC use-case? OR should we separate a dedicated I-D only with gap = analysis including ND, MIP, AODVv2, LISP? Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle = interface illustrated good enough by the words "moving network to nearby = moving network communications"? Or is it better to say "the 1-IP-hop = between nearby moving networks must be self-configured"? Nabil, Sandra: is it ok to have a working group item "List of Research = Papers for IP in V2V and V2I communications"? Other comments? Alex ------------------------------------------------------------------ ITS (name to change) Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: WG forming Chairs: TBD Assigned Area Director: TBD Mailing list Address: its@ietf.org 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: Goal ---- The goal of this group is to standardize IP-based protocols for establishing direct and secure connectivity between moving networks, some of which could be fixed permanently or temporarily. Moving Network to Nearby Moving Network Communications ------------------------------------------------------ The group is concerned with all situations involving moving network to nearby moving network communications. For example: vehicle-to-vehicle communications, nomadic user wearing a PAN and communicating to a homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a train, or train-to-intersection signalling. Example from the automobile communications space ------------------------------------------------ Automobiles and vehicles of all types are increasingly connected to the Internet, either as vehicle-to-vehicle, vehicle-to-infra or vehicle-to-Internet. Entertainment apps enhancing comfort, reliable data exchanges for road safety, and automated driving are features coming in automobiles to hit the roads from now to year 2020. Highlighting increased safety as an immediate result of hyper-connectivity applied to vehicles, public authorities worldwide are increasingly mandating secure communication technology requirements in vehicles. Emergency apps for new instrumented ambulances carry many benefits both to the users and to society in general. Why IP? ------- Today, there are several deployed Vehicle-to-Internet technologies, including car tethering through driver's cellular smartphone. However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are still being developed. To improve on a situation of link-specific data exchanges, and enable independent application sets to share the same links, IP data exchanges are needed. Enabling IP communication between vehicles (V2V), and between vehicles and the immediate infrastructure (V2I), will provide (0) ability to reach the rest of the world on the Internet (1) short and deterministic delays, (2) fast forwarding through scalable paths of routers, (3) ease of reuse of existing Internet applications in a vehicular environment. Moving network to nearby moving network communications involve link layers such as: 802.11p OCB (Outside the Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light Communications), IrDA, LTE-D. Only the IP protocols are capable of running on each of these links and establish IP paths across them in an interoperable manner. Scenarios? ---------- There are a few scenarios exhibiting the need to communicate from one moving network to another nearby moving network. In the automobile space, the Cooperative Adaptive Cruise Control and Platooning features consider that vehicles close to each other exchange data describing their kinematic status. At the cross-roads, the moving network inside a vehicle exchanges data with the moving network in the red-light pole. Several public safety scenarios involve moving networks. Distinct organizations deploy different moving networks (in-vehicle, on-person) at an incident scene. These networks need to interoperate in order to more effectively understand and deal with the incident scene. In connected rail scenarios the moving network deployed in trains communicate with other moving networks at the cross-points. What kind of solutions? ----------------------- The current technical solutions considered to achieve moving network to nearby moving network communications are of two kinds: IP routing protocols for n-hop path management and 1-hop link-scoped IP protocol enhancements. The 1-hop link-scoped protocols include the protocols for route establishment involving ICMP Router Advertisements. The n-hop path management protocols include n-hop path establishment protocols (e.g. Babel, OSPF) and n-hop path search protocols (most notably AODV and derivates). In this proposed Working Group the focus is on 1-hop protocols, and leverage from other Working Groups for the n-hop situations. In some of the moving network applications the window of opportunity for exchanging data with the immediate infrastructure may be very short. For example, a car driving near a road-side unit may have only 5s to exchange with that RSU (depending on speed, RSU range and number). (ephemeral connections). What kind of requirements? -------------------------- The requirements for mechanisms for moving network to nearby moving network communications are focusing on low delays of the data paths, reduced number of messages for path establishment, application friendly, resilience to attacks, compatibility with DHCP and Mobile IP. In addition, some moving network to nearby moving network applications involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the 1-hop IP moving network to nearby moving netowrk mechanisms will need to gracefully support IP multicast. Due to the inherent characteristics of safety-related communications, all new moving network to nearby moving network mechanisms must afford authenticity and confidentiality where necessary. Dynamically establishing ephemeral communication paths between automobiles in public areas must offer privacy safeguards for the end users (passengers). Establishing 1-hop IP V2V paths must not break the existing on-board protocols and applications which communicate with the Internet, possibly via multiple radios. In a moving network deployed in an automobile, typically one exit point connects the moving network to other moving networks. However, in a more general manner (and to support reliability) any new mechanism of moving network to nearby moving network communications should support multi-homing: one router to use multiple interfaces towards outside the moving network, or multiple routers. Current version of Internet protocols ------------------------------------- The group will only work on IPv6 solutions. What SDOs may need this work? ----------------------------- The requirements and standards for moving network to nearby moving network communications, often involving IPv6, and novel V2V and V2Infra concepts, are developed mainly at ISO TC204 "Intelligent Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For Vehicle-to-Internet communications, 3GPP LTE and other cellular technologies represent the long-range connectivity method; for Vehicle-to-Vehicle communications, LTE Direct is currently specified, as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning. The IEEE developed a popular link for short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V communications. Work Items ---------- - use-cases for moving network to nearby moving network communications - Problem Statement for moving network to nearby moving network = communications including V2V, V2I and DNS. - Security and Privacy Requirements for moving network to nearby moving network communications - Solutions, which might include new protocols or extensions to existing protocols. With MIB. - IPv6-over foo, where foo is pertinent for moving network to nearby moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in the V2V domain, identifying which uses IP. Timeline -------- - _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, = pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php = =20 =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, = pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php = =20 ------=_NextPart_000_00EC_01D19632.06989850 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Paul,

 

Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of = IP V2V but not see the need (so far), I referred to the automotive SDOs = (led by automotive industries)=E2=80=A6, although there are always = =E2=80=98minority reports=E2=80=99 J

 

Cheers,

 

J=C3=A9r=C3=B4me

 

From:= = Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com]
Sent: = Thursday 14 April 2016 09:36
To: J=C3=A9r=C3=B4me = H=C3=A4rri
Cc: Alexandre Petrescu; = its@ietf.org
Subject: Re: [its] charter = ITS

 

J=C3=A9r=C3=B4me,

I missed that you are also an academic = person.

I got it = :-)

 

I = understand your points for industry activity related to vehicular = networking.

Your = observation seems true.

 

BTW, I will invite you to my team for the draft for a = list of academic papers for V2V and V2I

by a personal message.

 

Thanks.

 

Paul

 

On Thu, = Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr> = wrote:

Hi Paul,

 

Thanks for your feedback. Do not get me wrong, I am an academic and = with my team, we also work on IP-based V2V and V2I, in particular = related to mobility management with DMM, but also in the context of = vehicular IoT.

 

I just have the feeling that people are perfectly aware of the fact = that IP can be used for V2V and V2I, but does not = =E2=80=98need=E2=80=99 to be used as other solutions already = perfectly fit their need. Listing papers will not change this awareness. =

 

So, as a complement to academic papers, it would help to be able to = pin-point which industrial activities are using or are strongly planning = (short term I mean) to use pure IPv6 system in vehicles. =

 

My feeling here is we have a different eco-system that the Automotive = industry (and automotive industry-related SDO)..more likely the IoT = industry=E2=80=A6and as such, we should not need to have the (direct) = involvement of automotive industry in the Charter. If we can make this = clear by an industry-based =E2=80=98survey=E2=80=99, that would help = make the case for the WG.

Btw, you can count on me your draft..we can add some IP-based V2V and = V2I for mobility management and also IoT.

 

Cheers,

 

J=C3=A9r=C3=B4me

 

From:= = Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com]
Sent: Thursday = 14 April 2016 03:22
To: J=C3=A9r=C3=B4me = H=C3=A4rri
Cc: Alexandre Petrescu; its@ietf.org
Subject: Re: [its] charter = ITS

 <= /o:p>

Hi = J=C3=A9r=C3=B4me,

I have an = opinion on your comment 5) below.

 <= /o:p>

I think = that a list of high-quality papers about IP-based V2V and = V2I

can teach = very useful lessons to software designers of IP in V2V and = V2I

in the = industry.

Multiple = people are working for this IP-based V2V and = V2I 

(including = Sandra Cespedes and me) in academia = and 

more = people(including Nabil Benamar) are willing to work for this = area.

 <= /o:p>

I think we = need to utilize the list of such papers as the ground for our ITS = group

through a = WI. Note that the draft of the list will include the summary of the = main 

ideas of = the papers.

 <= /o:p>

For the = industry current activities for this area, I believe that you can share = them

as = references through our ITS mailing list rather than through a = WI. 

 <= /o:p>

Could you = join my team that are making efforts for a list of such = papers?

 <= /o:p>

Thanks.=

 <= /o:p>

Best = Regards,

Paul

 <= /o:p>

 <= /o:p>

On Thu, Apr = 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr> = wrote:

Dear ITSers,  Dear Alex,

 

Here are some comments on the updated = charter:

1)      = Can we keep a reference to IEEE 802.11p, considering it does not = exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB = mode (and 10Mhz @5.9Ghz) of course.

 

2)      = Should we really keep C-ACC (or Platooning) in the charter explicitly = as use case, considering it is a seriously controversial aspect with = some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry = mentions traffic efficiency/infotainment applications, such as = in-signage applications...

a.     &nb= sp; We might have to aim at less controversial use cases to attract = automotive industries

 

3)      = One potential WI I could think of (rather a basic one): definition = of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive = context

a.     &nb= sp; To me, this is  a fundamental brick in the larger IETF WG ITS = house..

 

4)      = I would suggest to be more explicit in the foreseen challenges of = this WG, instead of mentioning general use case (which end up be = controversial)

a.     &nb= sp; Example: maintaining IPv6 connectivity in fast and asymmetric = wireless links; also under quickly changing topologies (actually = suggested by Dick Roy on the chat room)

b.      = Example: IPv6 addressing in link-local = scope..

c.     &nb= sp; Example: guaranteeing privacy in IPv6 moving networks = etc..

 

5)      = Before listing academic papers referring to IPv6 in vehicles, I would = suggest to first try to list commercial products/solutions that are in = vehicles and are using IPv6, possibly suffering from a silo limitations = (ex. restricted to a single technology, single use = case=E2=80=A6)

a.     &nb= sp; I think we need to get to products first, before academic = visions

 

My two cents..

 

Best Regards,

 

J=C3=A9r=C3=B4me

 

 

 

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of = Alexandre Petrescu
Sent: Wednesday 06 April 2016 = 23:45
To: its@ietf.org
Subject: [its] charter = ITS

 <= /o:p>

ITSers,

Please see below the = current charter.

- the two Problem Statements drafts V2V and V2I = joined, so there is less text in charter.
- added an Item on = "List of Research papers..."

Erik: did I understand you = correctly that there should be some item on discussing whether = link-local addressing is sufficient, whether prefix exchange is = necessary?

Dino: should LISP be included in the gap analysis = draft which includes C-ACC use-case?  OR should we separate a = dedicated I-D only with gap analysis including ND, MIP, AODVv2, = LISP?

Person from mediatek: is the 'zeroconf' need in the = vehicle-to-vehicle interface illustrated good enough by the words = "moving network to nearby moving network = communications"?  Or is it better to say "the 1-IP-hop = between nearby moving networks must be = self-configured"?

Nabil, Sandra: is it ok to have a working = group item "List of Research Papers for IP in V2V and V2I = communications"?

Other = comments?

Alex

--------------------------------------------= ----------------------

       &= nbsp;     ITS (name to = change)
          &n= bsp;        = Charter
          &n= bsp;  April 6th, = 2016
         http://ietf.org/mailman/listinfo/its


Int= elligent Transportation Systems = (its)
----------------------------------------
Current Status: WG = forming

Chairs:
   TBD

Assigned Area = Director:
   TBD

Mailing list
   = Address: its@ietf.org
   To Subscribe: https://www.ietf.org/mailman/listinfo/its
 =   Archive:
   http://www.ietf.org/mail-archive/web/its/current/mailli= st.html

Additional web page
   = TBD

Charter:

Goal
----
The goal of this group is to = standardize IP-based protocols for
establishing direct and secure = connectivity between moving networks,
some of which could be fixed = permanently or temporarily.

Moving Network to Nearby Moving = Network = Communications
------------------------------------------------------<= br>The group is concerned with all situations involving moving network = to
nearby moving network communications.  For example: = vehicle-to-vehicle
communications, nomadic user wearing a PAN and = communicating to a
homenet, vehicle-to-infrastructure communications, = wagon-to-wagon in a
train, or train-to-intersection = signalling.

Example from the automobile communications = space
------------------------------------------------
Automobiles = and vehicles of all types are increasingly connected to
the Internet, = either as vehicle-to-vehicle, vehicle-to-infra = or
vehicle-to-Internet.  Entertainment apps enhancing comfort, = reliable
data exchanges for road safety, and automated driving are = features
coming in automobiles to hit the roads from now to year = 2020.
Highlighting increased safety as an immediate result = of
hyper-connectivity applied to vehicles, public authorities = worldwide
are increasingly mandating secure communication = technology
requirements in vehicles.

Emergency apps for new = instrumented ambulances carry many benefits
both to the users and to = society in general.

Why IP?
-------
Today, there are = several deployed Vehicle-to-Internet technologies,
including car = tethering through driver's cellular smartphone.
However, = Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communications are = still being developed.  To improve on a situation
of = link-specific data exchanges, and enable independent application
sets = to share the same links, IP data exchanges are needed.  = Enabling
IP communication between vehicles (V2V), and between = vehicles and the
immediate infrastructure (V2I), will provide (0) = ability to reach the
rest of the world on the Internet (1) short and = deterministic delays,
(2) fast forwarding through scalable paths of = routers, (3) ease of
reuse of existing Internet applications in a = vehicular environment.

Moving network to nearby moving network = communications involve link
layers such as: 802.11p OCB (Outside the = Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC = (Visible Light
Communications), IrDA, LTE-D.  Only the IP = protocols are capable of
running on each of these links and establish = IP paths across them in
an interoperable = manner.

Scenarios?
----------
There are a few scenarios = exhibiting the need to communicate from one
moving network to another = nearby moving network.

In the automobile space, the Cooperative = Adaptive Cruise Control and
Platooning features consider that = vehicles close to each other
exchange data describing their kinematic = status.  At the cross-roads,
the moving network inside a vehicle = exchanges data with the moving
network in the red-light = pole.

Several public safety scenarios involve moving = networks.  Distinct
organizations deploy different moving = networks (in-vehicle, on-person)
at an incident scene.  These = networks need to interoperate in order to
more effectively understand = and deal with the incident scene.

In connected rail scenarios the = moving network deployed in trains
communicate with other moving = networks at the cross-points.

What kind of = solutions?
-----------------------
The current technical solutions = considered to achieve moving network
to nearby moving network = communications are of two kinds: IP routing
protocols for n-hop path = management and 1-hop link-scoped IP protocol
enhancements.  The = 1-hop link-scoped protocols include the protocols
for route = establishment involving ICMP Router Advertisements.  The
n-hop = path management protocols include n-hop path establishment
protocols = (e.g. Babel, OSPF) and n-hop path search protocols (most
notably AODV = and derivates).

In this proposed Working Group the focus is on = 1-hop protocols, and
leverage from other Working Groups for the n-hop = situations.

In some of the moving network applications the window = of opportunity
for exchanging data with the immediate infrastructure = may be very
short.  For example, a car driving near a road-side = unit may have only
5s to exchange with that RSU (depending on speed, = RSU range and
number). (ephemeral connections).

What kind of = requirements?
--------------------------
The requirements for = mechanisms for moving network to nearby moving
network communications = are focusing on low delays of the data paths,
reduced number of = messages for path establishment, application
friendly, resilience to = attacks, compatibility with DHCP and Mobile
IP.

In addition, = some moving network to nearby moving network applications
involve IP = multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP = moving network to nearby moving netowrk mechanisms will need
to = gracefully support IP multicast.

Due to the inherent = characteristics of safety-related communications,
all new moving = network to nearby moving network mechanisms must afford
authenticity = and confidentiality where necessary.  Dynamically
establishing = ephemeral communication paths between automobiles in
public areas = must offer privacy safeguards for the end = users
(passengers).

Establishing 1-hop IP V2V paths must not = break the existing on-board
protocols and applications which = communicate with the Internet,
possibly via multiple = radios.

In a moving network deployed in an automobile, typically = one exit
point connects the moving network to other moving = networks.  However,
in a more general manner (and to support = reliability) any new
mechanism of moving network to nearby moving = network communications
should support multi-homing: one router to use = multiple interfaces
towards outside the moving network, or multiple = routers.

Current version of Internet = protocols
-------------------------------------
The group will = only work on IPv6 solutions.

What SDOs may need this = work?
-----------------------------
The requirements and standards = for moving network to nearby moving
network communications, often = involving IPv6, and novel V2V and
V2Infra concepts, are developed = mainly at ISO TC204 "Intelligent
Transport Systems", 3GPP, = ETSI, NHTSA and IEEE.  For
Vehicle-to-Internet communications, = 3GPP LTE and other cellular
technologies represent the long-range = connectivity method; for
Vehicle-to-Vehicle communications, LTE = Direct is currently specified,
as well as OCB mode of IEEE = 802.11.  Several use-cases exhibit a need
for IPv6 data = exchanges between vehicles: ETSI's Cooperative Adaptive
Cruise = Control and Platooning.  The IEEE developed a popular link = for
short-range communications - IEEE 802.11p "WAVE".  = The NHTSA wrote a
set of requirements for V2V = communications.

Work Items
----------
- use-cases for = moving network to nearby moving network communications
- Problem = Statement for moving network to nearby moving network = communications
  including V2V, V2I and DNS.
- Security and = Privacy Requirements for moving network to
  nearby moving = network communications
- Solutions, which might include new protocols = or extensions to
  existing protocols.  With MIB.
- = IPv6-over foo, where foo is pertinent for moving network to = nearby
  moving network communications (e.g. 802.11 OCB, VLC, = LTE-D, 802.11ad)
- List of Research Papers in the V2V domain, = identifying which uses = IP.

Timeline
--------
-


______________= _________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its



 <= /o:p>

-- =

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of = Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: = jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php



 

-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant = Professor
Department of Software
Sungkyunkwan = University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php

------=_NextPart_000_00EC_01D19632.06989850-- From nobody Thu Apr 14 00:48:40 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6209112DDAF for ; Thu, 14 Apr 2016 00:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNr3uuxZG6Bg for ; Thu, 14 Apr 2016 00:48:34 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4136812DD25 for ; Thu, 14 Apr 2016 00:48:34 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id d68so95848866ywe.1 for ; Thu, 14 Apr 2016 00:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w5bUGBu9aWX2AB+S16VpsOohoArKCH47qkUbf34yATA=; b=tkcnZVHw+Ihhq38bwnNeb33ti8enRPYUdnIQPrqoAnsmb84/+dLw6tX3kX9L1WIyvq t+uBZ4D0O3x9xt7YsQDIkboF7G+ABDT1ZydAmCgq0l8ZR7eLpom28NAsHyTgKO3PeVef H+TctJkziNLkHSs+JioCvE8qkSp6F5M1Ox+YhqxzmcY2E892l4ZFIzH/u6pgkxl94KDZ C2wW5SjS3xG72WMMmBPgr9t4EUzbBNPMNG35gArOd/3qAScOdsHPbijvF5xKZok/Xozk 6xQ24dhLZbuDfJnCl5AtSsuidaMmdRAzkHIhlVZaqxXDrTS9Wm/URba3E84pqybr12dQ fUlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w5bUGBu9aWX2AB+S16VpsOohoArKCH47qkUbf34yATA=; b=PBJ9qdyUTi0tzymrT4jQlG/fC7lNvkRicb0c1VYrUUVrypSEI8/l4CdQgqBRHr07Ox me6isHHa/QSHg957HkaKq091mF/A8wTpbeNCX0k5ZJlfoLcK4isPIk223PiTlzEJ/07o cMr+Ud7jMii0p3FZ5bcwb6HFq0u4Inryaovfcy+Hv2N4SfB3iMMnKOxHihCz8lLCMG2R LZ/OllGZLIfcL5iM6GqGAi28krOB3mvelgYPPS343WP4aN5SbNBjmOlYpu+T09Mlv577 m6aBKk2NC0u//A8dC4FisIKXRHkKT1itP/70ns/sQs6/1UMPyUTL3mB5dexOd/fSry26 KUnA== X-Gm-Message-State: AOPr4FXKarz96NZRpGtShlvXA5Q9wW1vjRv5/FlACTJP6dooHKbfPArCQ7pYt+1HAwpYhUlyn7tI0xfvPyRUIQ== X-Received: by 10.129.120.8 with SMTP id t8mr7420412ywc.204.1460620113485; Thu, 14 Apr 2016 00:48:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.4.22 with HTTP; Thu, 14 Apr 2016 00:48:03 -0700 (PDT) In-Reply-To: <00eb01d19621$430b0d60$c9212820$@eurecom.fr> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> From: "Mr. Jaehoon Paul Jeong" Date: Thu, 14 Apr 2016 16:48:03 +0900 Message-ID: To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= Content-Type: multipart/alternative; boundary=94eb2c0b980604283705306d1f4b Archived-At: Cc: Alexandre Petrescu , its@ietf.org Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 07:48:38 -0000 --94eb2c0b980604283705306d1f4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable J=C3=A9r=C3=B4me, Thanks for your clarification. Paul On Thu, Apr 14, 2016 at 4:42 PM, J=C3=A9r=C3=B4me H=C3=A4rri wrote: > Paul, > > > > Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of IP V2= V but not see the > need (so far), I referred to the automotive SDOs (led by automotive > industries)=E2=80=A6, although there are always =E2=80=98minority reports= =E2=80=99 J > > > > Cheers, > > > > J=C3=A9r=C3=B4me > > > > *From:* Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] > *Sent:* Thursday 14 April 2016 09:36 > > *To:* J=C3=A9r=C3=B4me H=C3=A4rri > *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [its] charter ITS > > > > J=C3=A9r=C3=B4me, > > I missed that you are also an academic person. > > I got it :-) > > > > I understand your points for industry activity related to vehicular > networking. > > Your observation seems true. > > > > BTW, I will invite you to my team for the draft for a list of academic > papers for V2V and V2I > > by a personal message. > > > > Thanks. > > > > Paul > > > > On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri > wrote: > > Hi Paul, > > > > Thanks for your feedback. Do not get me wrong, I am an academic and with > my team, we also work on IP-based V2V and V2I, in particular related to > mobility management with DMM, but also in the context of vehicular IoT. > > > > I just have the feeling that people are perfectly aware of the fact that > IP *can* be used for V2V and V2I, but does not =E2=80=98*need*=E2=80=99 t= o be used as > other solutions already perfectly fit their need. Listing papers will not > change this awareness. > > > > So, as a complement to academic papers, it would help to be able to > pin-point which industrial activities are using or are strongly planning > (short term I mean) to use pure IPv6 system in vehicles. > > > > My feeling here is we have a different eco-system that the Automotive > industry (and automotive industry-related SDO)..more likely the IoT > industry=E2=80=A6and as such, we should not need to have the (direct) inv= olvement > of automotive industry in the Charter. If we can make this clear by an > industry-based =E2=80=98survey=E2=80=99, that would help make the case fo= r the WG. > > Btw, you can count on me your draft..we can add some IP-based V2V and V2I > for mobility management and also IoT. > > > > Cheers, > > > > J=C3=A9r=C3=B4me > > > > *From:* Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] > *Sent:* Thursday 14 April 2016 03:22 > *To:* J=C3=A9r=C3=B4me H=C3=A4rri > *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [its] charter ITS > > > > Hi J=C3=A9r=C3=B4me, > > I have an opinion on your comment 5) below. > > > > I think that a list of high-quality papers about IP-based V2V and V2I > > can teach very useful lessons to software designers of IP in V2V and V2I > > in the industry. > > Multiple people are working for this IP-based V2V and V2I > > (including Sandra Cespedes and me) in academia and > > more people(including Nabil Benamar) are willing to work for this area. > > > > I think we need to utilize the list of such papers as the ground for our > ITS group > > through a WI. Note that the draft of the list will include the summary of > the main > > ideas of the papers. > > > > For the industry current activities for this area, I believe that you can > share them > > as references through our ITS mailing list rather than through a WI. > > > > Could you join my team that are making efforts for a list of such papers? > > > > Thanks. > > > > Best Regards, > > Paul > > > > > > On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri > wrote: > > Dear ITSers, Dear Alex, > > > > Here are some comments on the updated charter: > > 1) Can we keep a reference to IEEE 802.11p, considering it does not > exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mo= de > (and 10Mhz @5.9Ghz) of course. > > > > 2) Should we really keep C-ACC (or Platooning) in the charter > explicitly as use case, considering it is a seriously controversial aspec= t > with some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry > mentions traffic efficiency/infotainment applications, such as in-signage > applications... > > a. We might have to aim at less controversial use cases to attract > automotive industries > > > > 3) One potential WI I could think of (rather a basic one): *definiti= on > of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive context* > > a. To me, this is a fundamental brick in the larger IETF WG ITS > house.. > > > > 4) I would suggest to be more explicit in the foreseen challenges of > this WG, instead of mentioning general use case (which end up be > controversial) > > a. Example: maintaining IPv6 connectivity in fast and asymmetric > wireless links; also under quickly changing topologies (actually suggeste= d > by Dick Roy on the chat room) > > b. Example: IPv6 addressing in link-local scope.. > > c. Example: guaranteeing privacy in IPv6 moving networks etc.. > > > > 5) Before listing academic papers referring to IPv6 in vehicles, I > would suggest to first try to list commercial products/solutions that are > in vehicles and are using IPv6, possibly suffering from a silo limitation= s > (ex. restricted to a single technology, single use case=E2=80=A6) > > a. I think we need to get to products first, before academic vision= s > > > > My two cents.. > > > > Best Regards, > > > > J=C3=A9r=C3=B4me > > > > > > > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre > Petrescu > *Sent:* Wednesday 06 April 2016 23:45 > *To:* its@ietf.org > *Subject:* [its] charter ITS > > > > ITSers, > > Please see below the current charter. > > - the two Problem Statements drafts V2V and V2I joined, so there is less > text in charter. > - added an Item on "List of Research papers..." > > Erik: did I understand you correctly that there should be some item on > discussing whether link-local addressing is sufficient, whether prefix > exchange is necessary? > > Dino: should LISP be included in the gap analysis draft which includes > C-ACC use-case? OR should we separate a dedicated I-D only with gap > analysis including ND, MIP, AODVv2, LISP? > > Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle > interface illustrated good enough by the words "moving network to nearby > moving network communications"? Or is it better to say "the 1-IP-hop > between nearby moving networks must be self-configured"? > > Nabil, Sandra: is it ok to have a working group item "List of Research > Papers for IP in V2V and V2I communications"? > > Other comments? > > Alex > > ------------------------------------------------------------------ > > ITS (name to change) > Charter > April 6th, 2016 > http://ietf.org/mailman/listinfo/its > > > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming > > Chairs: > TBD > > Assigned Area Director: > TBD > > Mailing list > Address: its@ietf.org > 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: > > Goal > ---- > The goal of this group is to standardize IP-based protocols for > establishing direct and secure connectivity between moving networks, > some of which could be fixed permanently or temporarily. > > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving network to > nearby moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > train, or train-to-intersection signalling. > > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to > the Internet, either as vehicle-to-vehicle, vehicle-to-infra or > vehicle-to-Internet. Entertainment apps enhancing comfort, reliable > data exchanges for road safety, and automated driving are features > coming in automobiles to hit the roads from now to year 2020. > Highlighting increased safety as an immediate result of > hyper-connectivity applied to vehicles, public authorities worldwide > are increasingly mandating secure communication technology > requirements in vehicles. > > Emergency apps for new instrumented ambulances carry many benefits > both to the users and to society in general. > > Why IP? > ------- > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. > However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure > communications are still being developed. To improve on a situation > of link-specific data exchanges, and enable independent application > sets to share the same links, IP data exchanges are needed. Enabling > IP communication between vehicles (V2V), and between vehicles and the > immediate infrastructure (V2I), will provide (0) ability to reach the > rest of the world on the Internet (1) short and deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) ease of > reuse of existing Internet applications in a vehicular environment. > > Moving network to nearby moving network communications involve link > layers such as: 802.11p OCB (Outside the Context of a Basic Service > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light > Communications), IrDA, LTE-D. Only the IP protocols are capable of > running on each of these links and establish IP paths across them in > an interoperable manner. > > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate from one > moving network to another nearby moving network. > > In the automobile space, the Cooperative Adaptive Cruise Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the cross-roads, > the moving network inside a vehicle exchanges data with the moving > network in the red-light pole. > > Several public safety scenarios involve moving networks. Distinct > organizations deploy different moving networks (in-vehicle, on-person) > at an incident scene. These networks need to interoperate in order to > more effectively understand and deal with the incident scene. > > In connected rail scenarios the moving network deployed in trains > communicate with other moving networks at the cross-points. > > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol > enhancements. The 1-hop link-scoped protocols include the protocols > for route establishment involving ICMP Router Advertisements. The > n-hop path management protocols include n-hop path establishment > protocols (e.g. Babel, OSPF) and n-hop path search protocols (most > notably AODV and derivates). > > In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations. > > In some of the moving network applications the window of opportunity > for exchanging data with the immediate infrastructure may be very > short. For example, a car driving near a road-side unit may have only > 5s to exchange with that RSU (depending on speed, RSU range and > number). (ephemeral connections). > > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to nearby moving > network communications are focusing on low delays of the data paths, > reduced number of messages for path establishment, application > friendly, resilience to attacks, compatibility with DHCP and Mobile > IP. > > In addition, some moving network to nearby moving network applications > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the > 1-hop IP moving network to nearby moving netowrk mechanisms will need > to gracefully support IP multicast. > > Due to the inherent characteristics of safety-related communications, > all new moving network to nearby moving network mechanisms must afford > authenticity and confidentiality where necessary. Dynamically > establishing ephemeral communication paths between automobiles in > public areas must offer privacy safeguards for the end users > (passengers). > > Establishing 1-hop IP V2V paths must not break the existing on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. > > In a moving network deployed in an automobile, typically one exit > point connects the moving network to other moving networks. However, > in a more general manner (and to support reliability) any new > mechanism of moving network to nearby moving network communications > should support multi-homing: one router to use multiple interfaces > towards outside the moving network, or multiple routers. > > Current version of Internet protocols > ------------------------------------- > The group will only work on IPv6 solutions. > > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to nearby moving > network communications, often involving IPv6, and novel V2V and > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For > Vehicle-to-Internet communications, 3GPP LTE and other cellular > technologies represent the long-range connectivity method; for > Vehicle-to-Vehicle communications, LTE Direct is currently specified, > as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need > for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive > Cruise Control and Platooning. The IEEE developed a popular link for > short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a > set of requirements for V2V communications. > > Work Items > ---------- > - use-cases for moving network to nearby moving network communications > - Problem Statement for moving network to nearby moving network > communications > including V2V, V2I and DNS. > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Solutions, which might include new protocols or extensions to > existing protocols. With MIB. > - IPv6-over foo, where foo is pertinent for moving network to nearby > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) > - List of Research Papers in the V2V domain, identifying which uses IP. > > Timeline > -------- > - > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --94eb2c0b980604283705306d1f4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
J=C3=A9r=C3=B4me,
Thanks for your clarification.

Paul

On Thu, Apr 14, 2016 at 4:42 PM, J=C3=A9r=C3=B4me H= =C3=A4rri <jerome.haerri@eurecom.fr> wrote:

Paul,=

=C2=A0<= u>

Thanks. = Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of IP V2V but not = see the need (so far), I referred to the automotive SDOs (led by automotive= industries)=E2=80=A6, although there are always =E2=80=98minority reports= =E2=80=99 J

=C2=A0<= /p>

Cheers,<= /span>

=C2=A0

J=C3=A9r= =C3=B4me

=C2=A0

From: Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] =
Sent: Thursday 14 April 2016 09:36


To: J=C3=A9r=C3=B4me H=C3=A4rri
Cc: Alexandre Petr= escu; its@ietf.orgSubject: Re: [its] charter ITS

=C2=A0

J=C3=A9r=C3=B4me,

I missed that you are also an academic person.

I got it :-)

=C2=A0

I understand your points for industry activity related to vehicular netwo= rking.

Your observation = seems true.

=C2= =A0

BTW, I will invite you to m= y team for the draft for a list of academic papers for V2V and V2I

by a personal message.=

=C2=A0

Thanks.

=C2=A0

Paul<= /u>

=C2=A0<= /p>

On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3= =B4me H=C3=A4rri <jerome.haerri@eurecom.fr> wrote:

=

Hi Paul,=

=C2=A0<= /u>

Thanks for = your feedback. Do not get me wrong, I am an academic and with my team, we a= lso work on IP-based V2V and V2I, in particular related to mobility managem= ent with DMM, but also in the context of vehicular IoT.

=C2=A0

I just have t= he feeling that people are perfectly aware of the fact that IP can b= e used for V2V and V2I, but does not =E2=80=98need=E2=80=99 to be us= ed as other solutions already perfectly fit their need. Listing papers will= not change this awareness.

=C2=A0

So, as a complement to academic papers, i= t would help to be able to pin-point which industrial activities are using = or are strongly planning (short term I mean) to use pure IPv6 system in veh= icles.

=C2=A0

My feeling here is we have a different eco-system that the Aut= omotive industry (and automotive industry-related SDO)..more likely the IoT= industry=E2=80=A6and as such, we should not need to have the (direct) invo= lvement of automotive industry in the Charter. If we can make this clear by= an industry-based =E2=80=98survey=E2=80=99, that would help make the case = for the WG.

Btw, you can count on me your draft..we can add some IP-based V2= V and V2I for mobility management and also IoT.

=C2=A0<= /p>

Cheers,<= u>

=C2=A0

J=C3=A9r= =C3=B4me

=C2=A0

From: Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] =
Sent: Thursday 14 April 2016 03:22
To: J=C3=A9r=C3=B4m= e H=C3=A4rri
Cc: Alexandre Petrescu; its@ietf.org
Subject: Re: [its] charter= ITS

=C2=A0

Hi J=C3=A9r=C3=B4me,

I have an opinion on your comment = 5) below.

=C2=A0<= u>

I think that a list of high-qua= lity papers about IP-based V2V and V2I

can teach very useful lessons to software designers of IP in= V2V and V2I

in the indu= stry.

Multiple people ar= e working for this IP-based V2V and V2I=C2=A0

<= p class=3D"MsoNormal">(including Sandra Cespedes and me) in academia and=C2= =A0

more people(includin= g Nabil Benamar) are willing to work for this area.

=

=C2=A0

I think we need to utilize the list of such papers as the ground= for our ITS group

throu= gh a WI. Note that the draft of the list will include the summary of the ma= in=C2=A0

ideas of the pa= pers.

=C2=A0

For the industry current activities= for this area, I believe that you can share them

as references through our ITS mailing list rather= than through a WI.=C2=A0

=C2=A0

Could you join = my team that are making efforts for a list of such papers?

=C2=A0

Thanks.

=C2=A0

Best Regards,

Paul

=C2=A0

=C2=A0

On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eu= recom.fr> wrote:

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">Dear ITSers, =C2=A0Dear Alex,

=C2=A0=

Here are some = comments on the updated charter:

1)=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Can we keep a re= ference to IEEE 802.11p, considering it does not exist anymore? It is now f= ully integrated into IEEE 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of co= urse.

=C2=A0<= u>

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Should we really keep C-ACC (or Platooning) in the charter= explicitly as use case, considering it is a seriously controversial aspect= with some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry = mentions traffic efficiency/infotainment applications, such as in-signage a= pplications...

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 W= e might have to aim at less controversial use cases to attract automotive i= ndustries

=C2=A0

3)=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 One potential WI I could = think of (rather a basic one): definition of a vehicular wireless =E2=80= =98link=E2=80=99 in an automotive context

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 To me, this is=C2=A0 a fundamental brick in = the larger IETF WG ITS house..

=C2=A0

4)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 I would suggest to be more explici= t in the foreseen challenges of this WG, instead of mentioning general use = case (which end up be controversial)

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Example: maintaining IPv6 connectivity in fast and asy= mmetric wireless links; also under quickly changing topologies (actually su= ggested by Dick Roy on the chat room)

b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Example: IPv6 addressing in link-local scope..

c.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Example: guaranteeing privac= y in IPv6 moving networks etc..

=C2=A0

5)<= /span>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Before listing academic papers = referring to IPv6 in vehicles, I would suggest to first try to list commerc= ial products/solutions that are in vehicles and are using IPv6, possibly su= ffering from a silo limitations (ex. restricted to a single technology, sin= gle use case=E2=80=A6)

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I think we need to get to products first, before academic visions

=C2= =A0

My two cents..

=C2=A0

Best Regards,

=C2=A0

J=C3=A9r=C3=B4me=

=C2=A0<= /u>

=C2=A0

=C2= =A0

From: its [mailto:its-bounces@ietf.org] On Behalf Of = Alexandre Petrescu
Sent: Wednesday 06 April 2016 23:45
To:<= /b> its@ietf.org
<= b>Subject: [its] charter ITS

<= div>

=C2=A0

ITSers,

Please see below the current charter.

- the tw= o Problem Statements drafts V2V and V2I joined, so there is less text in ch= arter.
- added an Item on "List of Research papers..."

= Erik: did I understand you correctly that there should be some item on disc= ussing whether link-local addressing is sufficient, whether prefix exchange= is necessary?

Dino: should LISP be included in the gap analysis dra= ft which includes C-ACC use-case?=C2=A0 OR should we separate a dedicated I= -D only with gap analysis including ND, MIP, AODVv2, LISP?

Person fr= om mediatek: is the 'zeroconf' need in the vehicle-to-vehicle inter= face illustrated good enough by the words "moving network to nearby mo= ving network communications"?=C2=A0 Or is it better to say "the 1= -IP-hop between nearby moving networks must be self-configured"?
Nabil, Sandra: is it ok to have a working group item "List of Resear= ch Papers for IP in V2V and V2I communications"?

Other comments= ?

Alex

------------------------------------------------------= ------------

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 ITS (name to change)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Charter
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 April 6th, 2016
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 h= ttp://ietf.org/mailman/listinfo/its


Intelligent Transportati= on Systems (its)
----------------------------------------
Current Sta= tus: WG forming

Chairs:
=C2=A0=C2=A0 TBD

Assigned Area Dir= ector:
=C2=A0=C2=A0 TBD

Mailing list
=C2=A0=C2=A0 Address: its@ietf.org
=C2=A0= =C2=A0 To Subscribe: https://www.ietf.org/mailman/listinfo/its
=C2=A0= =C2=A0 Archive:
=C2=A0=C2=A0 http://www.ietf.org/mail-= archive/web/its/current/maillist.html

Additional web page
=C2= =A0=C2=A0 TBD

Charter:

Goal
----
The goal of this group= is to standardize IP-based protocols for
establishing direct and secure= connectivity between moving networks,
some of which could be fixed perm= anently or temporarily.

Moving Network to Nearby Moving Network Comm= unications
------------------------------------------------------
The= group is concerned with all situations involving moving network to
near= by moving network communications.=C2=A0 For example: vehicle-to-vehicle
= communications, nomadic user wearing a PAN and communicating to a
homene= t, vehicle-to-infrastructure communications, wagon-to-wagon in a
train, = or train-to-intersection signalling.

Example from the automobile com= munications space
------------------------------------------------
Au= tomobiles and vehicles of all types are increasingly connected to
the In= ternet, either as vehicle-to-vehicle, vehicle-to-infra or
vehicle-to-Int= ernet.=C2=A0 Entertainment apps enhancing comfort, reliable
data exchang= es for road safety, and automated driving are features
coming in automob= iles to hit the roads from now to year 2020.
Highlighting increased safe= ty as an immediate result of
hyper-connectivity applied to vehicles, pub= lic authorities worldwide
are increasingly mandating secure communicatio= n technology
requirements in vehicles.

Emergency apps for new ins= trumented ambulances carry many benefits
both to the users and to societ= y in general.

Why IP?
-------
Today, there are several deploye= d Vehicle-to-Internet technologies,
including car tethering through driv= er's cellular smartphone.
However, Vehicle-to-Vehicle and Vehicle-to= -Infrastructure
communications are still being developed.=C2=A0 To impro= ve on a situation
of link-specific data exchanges, and enable independen= t application
sets to share the same links, IP data exchanges are needed= .=C2=A0 Enabling
IP communication between vehicles (V2V), and between ve= hicles and the
immediate infrastructure (V2I), will provide (0) ability = to reach the
rest of the world on the Internet (1) short and determinist= ic delays,
(2) fast forwarding through scalable paths of routers, (3) ea= se of
reuse of existing Internet applications in a vehicular environment= .

Moving network to nearby moving network communications involve lin= k
layers such as: 802.11p OCB (Outside the Context of a Basic ServiceSet), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light
Communication= s), IrDA, LTE-D.=C2=A0 Only the IP protocols are capable of
running on e= ach of these links and establish IP paths across them in
an interoperabl= e manner.

Scenarios?
----------
There are a few scenarios exhi= biting the need to communicate from one
moving network to another nearby= moving network.

In the automobile space, the Cooperative Adaptive C= ruise Control and
Platooning features consider that vehicles close to ea= ch other
exchange data describing their kinematic status.=C2=A0 At the c= ross-roads,
the moving network inside a vehicle exchanges data with the = moving
network in the red-light pole.

Several public safety scena= rios involve moving networks.=C2=A0 Distinct
organizations deploy differ= ent moving networks (in-vehicle, on-person)
at an incident scene.=C2=A0 = These networks need to interoperate in order to
more effectively underst= and and deal with the incident scene.

In connected rail scenarios th= e moving network deployed in trains
communicate with other moving networ= ks at the cross-points.

What kind of solutions?
-----------------= ------
The current technical solutions considered to achieve moving netw= ork
to nearby moving network communications are of two kinds: IP routing=
protocols for n-hop path management and 1-hop link-scoped IP protocolenhancements.=C2=A0 The 1-hop link-scoped protocols include the protocols=
for route establishment involving ICMP Router Advertisements.=C2=A0 The=
n-hop path management protocols include n-hop path establishment
pro= tocols (e.g. Babel, OSPF) and n-hop path search protocols (most
notably = AODV and derivates).

In this proposed Working Group the focus is on = 1-hop protocols, and
leverage from other Working Groups for the n-hop si= tuations.

In some of the moving network applications the window of o= pportunity
for exchanging data with the immediate infrastructure may be = very
short.=C2=A0 For example, a car driving near a road-side unit may h= ave only
5s to exchange with that RSU (depending on speed, RSU range and=
number). (ephemeral connections).

What kind of requirements?
= --------------------------
The requirements for mechanisms for moving ne= twork to nearby moving
network communications are focusing on low delays= of the data paths,
reduced number of messages for path establishment, a= pplication
friendly, resilience to attacks, compatibility with DHCP and = Mobile
IP.

In addition, some moving network to nearby moving netw= ork applications
involve IP multicast mechanisms (e.g. virtual siren); t= hus C-ACC the
1-hop IP moving network to nearby moving netowrk mechanism= s will need
to gracefully support IP multicast.

Due to the inhere= nt characteristics of safety-related communications,
all new moving netw= ork to nearby moving network mechanisms must afford
authenticity and con= fidentiality where necessary.=C2=A0 Dynamically
establishing ephemeral c= ommunication paths between automobiles in
public areas must offer privac= y safeguards for the end users
(passengers).

Establishing 1-hop I= P V2V paths must not break the existing on-board
protocols and applicati= ons which communicate with the Internet,
possibly via multiple radios.
In a moving network deployed in an automobile, typically one exit
= point connects the moving network to other moving networks.=C2=A0 However,<= br>in a more general manner (and to support reliability) any new
mechani= sm of moving network to nearby moving network communications
should supp= ort multi-homing: one router to use multiple interfaces
towards outside = the moving network, or multiple routers.

Current version of Internet= protocols
-------------------------------------
The group will only = work on IPv6 solutions.

What SDOs may need this work?
-----------= ------------------
The requirements and standards for moving network to = nearby moving
network communications, often involving IPv6, and novel V2= V and
V2Infra concepts, are developed mainly at ISO TC204 "Intellig= ent
Transport Systems", 3GPP, ETSI, NHTSA and IEEE.=C2=A0 For
Ve= hicle-to-Internet communications, 3GPP LTE and other cellular
technologi= es represent the long-range connectivity method; for
Vehicle-to-Vehicle = communications, LTE Direct is currently specified,
as well as OCB mode o= f IEEE 802.11.=C2=A0 Several use-cases exhibit a need
for IPv6 data exch= anges between vehicles: ETSI's Cooperative Adaptive
Cruise Control a= nd Platooning.=C2=A0 The IEEE developed a popular link for
short-range c= ommunications - IEEE 802.11p "WAVE".=C2=A0 The NHTSA wrote a
s= et of requirements for V2V communications.

Work Items
----------<= br>- use-cases for moving network to nearby moving network communications- Problem Statement for moving network to nearby moving network communica= tions
=C2=A0 including V2V, V2I and DNS.
- Security and Privacy Requi= rements for moving network to
=C2=A0 nearby moving network communication= s
- Solutions, which might include new protocols or extensions to
=C2= =A0 existing protocols.=C2=A0 With MIB.
- IPv6-over foo, where foo is pe= rtinent for moving network to nearby
=C2=A0 moving network communication= s (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)
- List of Research Papers in t= he V2V domain, identifying which uses IP.

Timeline
--------
-<= /span>


____________________________________________= ___
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its<= /u>



=C2=A0

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
D= epartment of Software
Sungkyunkwan University
Office: +82-31-299-4957=
Email: jaeh= oon.paul@gmail.com,=C2=A0pauljeong@skku.eduPersonal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php=



<= /p>

=C2=A0

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant ProfessorDepartment of Software
Sungkyunkwan University
Office: +82-31-299-4= 957
Email: j= aehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu<= br>Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php




--
--94eb2c0b980604283705306d1f4b-- From nobody Thu Apr 14 01:06:29 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A35712DB98 for ; Thu, 14 Apr 2016 01:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwIVoazfZAoy for ; Thu, 14 Apr 2016 01:06:25 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4694612DAD8 for ; Thu, 14 Apr 2016 01:06:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3E86JRb018955; Thu, 14 Apr 2016 10:06:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 606FE20595F; Thu, 14 Apr 2016 10:07:39 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 50E62205848; Thu, 14 Apr 2016 10:07:39 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3E86IMs023078; Thu, 14 Apr 2016 10:06:19 +0200 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Mr. Jaehoon Paul Jeong'" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> From: Alexandre Petrescu Message-ID: <570F4F7A.8010109@gmail.com> Date: Thu, 14 Apr 2016 10:06:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <00eb01d19621$430b0d60$c9212820$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: its@ietf.org Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 08:06:29 -0000 Le 14/04/2016 09:42, Jérôme Härri a écrit : > Paul, > > Thanks. Btw, when I mentioned ‘people’ are aware of IP V2V but not see > the need (so far), I referred to the automotive SDOs (led by automotive > industries)…, although there are always ‘minority reports’ J Jérôme, Along the automotive SDO discussion. Which other SDO is not sure about using IP for C-ACC but maybe for other use-cases.? Alex > > Cheers, > > Jérôme > > *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] > *Sent:* Thursday 14 April 2016 09:36 > *To:* Jérôme Härri > *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [its] charter ITS > > Jérôme, > > I missed that you are also an academic person. > > I got it :-) > > I understand your points for industry activity related to vehicular > networking. > > Your observation seems true. > > BTW, I will invite you to my team for the draft for a list of academic > papers for V2V and V2I > > by a personal message. > > Thanks. > > Paul > > On Thu, Apr 14, 2016 at 4:09 PM, Jérôme Härri > wrote: > > Hi Paul, > > Thanks for your feedback. Do not get me wrong, I am an academic and with > my team, we also work on IP-based V2V and V2I, in particular related to > mobility management with DMM, but also in the context of vehicular IoT. > > I just have the feeling that people are perfectly aware of the fact that > IP _can_ be used for V2V and V2I, but does not ‘_need_’ to be used as > other solutions already perfectly fit their need. Listing papers will > not change this awareness. > > So, as a complement to academic papers, it would help to be able to > pin-point which industrial activities are using or are strongly planning > (short term I mean) to use pure IPv6 system in vehicles. > > My feeling here is we have a different eco-system that the Automotive > industry (and automotive industry-related SDO)..more likely the IoT > industry…and as such, we should not need to have the (direct) > involvement of automotive industry in the Charter. If we can make this > clear by an industry-based ‘survey’, that would help make the case for > the WG. > > Btw, you can count on me your draft..we can add some IP-based V2V and > V2I for mobility management and also IoT. > > Cheers, > > Jérôme > > *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com > ] > *Sent:* Thursday 14 April 2016 03:22 > *To:* Jérôme Härri > *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [its] charter ITS > > Hi Jérôme, > > I have an opinion on your comment 5) below. > > I think that a list of high-quality papers about IP-based V2V and V2I > > can teach very useful lessons to software designers of IP in V2V and V2I > > in the industry. > > Multiple people are working for this IP-based V2V and V2I > > (including Sandra Cespedes and me) in academia and > > more people(including Nabil Benamar) are willing to work for this area. > > I think we need to utilize the list of such papers as the ground for our > ITS group > > through a WI. Note that the draft of the list will include the summary > of the main > > ideas of the papers. > > For the industry current activities for this area, I believe that you > can share them > > as references through our ITS mailing list rather than through a WI. > > Could you join my team that are making efforts for a list of such papers? > > Thanks. > > Best Regards, > > Paul > > On Thu, Apr 7, 2016 at 8:11 AM, Jérôme Härri > wrote: > > Dear ITSers, Dear Alex, > > Here are some comments on the updated charter: > > 1)Can we keep a reference to IEEE 802.11p, considering it does not exist > anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mode > (and 10Mhz @5.9Ghz) of course. > > 2)Should we really keep C-ACC (or Platooning) in the charter explicitly > as use case, considering it is a seriously controversial aspect with > some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry > mentions traffic efficiency/infotainment applications, such as > in-signage applications... > > a.We might have to aim at less controversial use cases to attract > automotive industries > > 3)One potential WI I could think of (rather a basic one): _definition of > a vehicular wireless ‘link’ in an automotive context_ > > a.To me, this is a fundamental brick in the larger IETF WG ITS house.. > > 4)I would suggest to be more explicit in the foreseen challenges of this > WG, instead of mentioning general use case (which end up be controversial) > > a.Example: maintaining IPv6 connectivity in fast and asymmetric wireless > links; also under quickly changing topologies (actually suggested by > Dick Roy on the chat room) > > b.Example: IPv6 addressing in link-local scope.. > > c.Example: guaranteeing privacy in IPv6 moving networks etc.. > > 5)Before listing academic papers referring to IPv6 in vehicles, I would > suggest to first try to list commercial products/solutions that are in > vehicles and are using IPv6, possibly suffering from a silo limitations > (ex. restricted to a single technology, single use case…) > > a.I think we need to get to products first, before academic visions > > My two cents.. > > Best Regards, > > Jérôme > > *From:*its [mailto:its-bounces@ietf.org ] > *On Behalf Of *Alexandre Petrescu > *Sent:* Wednesday 06 April 2016 23:45 > *To:* its@ietf.org > *Subject:* [its] charter ITS > > ITSers, > > Please see below the current charter. > > - the two Problem Statements drafts V2V and V2I joined, so there is less > text in charter. > - added an Item on "List of Research papers..." > > Erik: did I understand you correctly that there should be some item on > discussing whether link-local addressing is sufficient, whether prefix > exchange is necessary? > > Dino: should LISP be included in the gap analysis draft which includes > C-ACC use-case? OR should we separate a dedicated I-D only with gap > analysis including ND, MIP, AODVv2, LISP? > > Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle > interface illustrated good enough by the words "moving network to nearby > moving network communications"? Or is it better to say "the 1-IP-hop > between nearby moving networks must be self-configured"? > > Nabil, Sandra: is it ok to have a working group item "List of Research > Papers for IP in V2V and V2I communications"? > > Other comments? > > Alex > > ------------------------------------------------------------------ > > ITS (name to change) > Charter > April 6th, 2016 > http://ietf.org/mailman/listinfo/its > > > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming > > Chairs: > TBD > > Assigned Area Director: > TBD > > Mailing list > Address: its@ietf.org > 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: > > Goal > ---- > The goal of this group is to standardize IP-based protocols for > establishing direct and secure connectivity between moving networks, > some of which could be fixed permanently or temporarily. > > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving network to > nearby moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > train, or train-to-intersection signalling. > > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to > the Internet, either as vehicle-to-vehicle, vehicle-to-infra or > vehicle-to-Internet. Entertainment apps enhancing comfort, reliable > data exchanges for road safety, and automated driving are features > coming in automobiles to hit the roads from now to year 2020. > Highlighting increased safety as an immediate result of > hyper-connectivity applied to vehicles, public authorities worldwide > are increasingly mandating secure communication technology > requirements in vehicles. > > Emergency apps for new instrumented ambulances carry many benefits > both to the users and to society in general. > > Why IP? > ------- > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. > However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure > communications are still being developed. To improve on a situation > of link-specific data exchanges, and enable independent application > sets to share the same links, IP data exchanges are needed. Enabling > IP communication between vehicles (V2V), and between vehicles and the > immediate infrastructure (V2I), will provide (0) ability to reach the > rest of the world on the Internet (1) short and deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) ease of > reuse of existing Internet applications in a vehicular environment. > > Moving network to nearby moving network communications involve link > layers such as: 802.11p OCB (Outside the Context of a Basic Service > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light > Communications), IrDA, LTE-D. Only the IP protocols are capable of > running on each of these links and establish IP paths across them in > an interoperable manner. > > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate from one > moving network to another nearby moving network. > > In the automobile space, the Cooperative Adaptive Cruise Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the cross-roads, > the moving network inside a vehicle exchanges data with the moving > network in the red-light pole. > > Several public safety scenarios involve moving networks. Distinct > organizations deploy different moving networks (in-vehicle, on-person) > at an incident scene. These networks need to interoperate in order to > more effectively understand and deal with the incident scene. > > In connected rail scenarios the moving network deployed in trains > communicate with other moving networks at the cross-points. > > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol > enhancements. The 1-hop link-scoped protocols include the protocols > for route establishment involving ICMP Router Advertisements. The > n-hop path management protocols include n-hop path establishment > protocols (e.g. Babel, OSPF) and n-hop path search protocols (most > notably AODV and derivates). > > In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations. > > In some of the moving network applications the window of opportunity > for exchanging data with the immediate infrastructure may be very > short. For example, a car driving near a road-side unit may have only > 5s to exchange with that RSU (depending on speed, RSU range and > number). (ephemeral connections). > > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to nearby moving > network communications are focusing on low delays of the data paths, > reduced number of messages for path establishment, application > friendly, resilience to attacks, compatibility with DHCP and Mobile > IP. > > In addition, some moving network to nearby moving network applications > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the > 1-hop IP moving network to nearby moving netowrk mechanisms will need > to gracefully support IP multicast. > > Due to the inherent characteristics of safety-related communications, > all new moving network to nearby moving network mechanisms must afford > authenticity and confidentiality where necessary. Dynamically > establishing ephemeral communication paths between automobiles in > public areas must offer privacy safeguards for the end users > (passengers). > > Establishing 1-hop IP V2V paths must not break the existing on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. > > In a moving network deployed in an automobile, typically one exit > point connects the moving network to other moving networks. However, > in a more general manner (and to support reliability) any new > mechanism of moving network to nearby moving network communications > should support multi-homing: one router to use multiple interfaces > towards outside the moving network, or multiple routers. > > Current version of Internet protocols > ------------------------------------- > The group will only work on IPv6 solutions. > > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to nearby moving > network communications, often involving IPv6, and novel V2V and > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For > Vehicle-to-Internet communications, 3GPP LTE and other cellular > technologies represent the long-range connectivity method; for > Vehicle-to-Vehicle communications, LTE Direct is currently specified, > as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need > for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive > Cruise Control and Platooning. The IEEE developed a popular link for > short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a > set of requirements for V2V communications. > > Work Items > ---------- > - use-cases for moving network to nearby moving network communications > - Problem Statement for moving network to nearby moving network > communications > including V2V, V2I and DNS. > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Solutions, which might include new protocols or extensions to > existing protocols. With MIB. > - IPv6-over foo, where foo is pertinent for moving network to nearby > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) > - List of Research Papers in the V2V domain, identifying which uses IP. > > Timeline > -------- > - > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com , > pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com , > pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > From nobody Thu Apr 14 01:42:30 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3109512E3A5 for ; Thu, 14 Apr 2016 01:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 705uRs7lUR3a for ; Thu, 14 Apr 2016 01:42:23 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6468E12E3EF for ; Thu, 14 Apr 2016 01:42:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3E8gKNY001167 for ; Thu, 14 Apr 2016 10:42:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 67CEF20597E for ; Thu, 14 Apr 2016 10:43:40 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5D609205917 for ; Thu, 14 Apr 2016 10:43:40 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3E8gJPs002940 for ; Thu, 14 Apr 2016 10:42:20 +0200 To: "its@ietf.org" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> From: Alexandre Petrescu Message-ID: <570F57EB.4060606@gmail.com> Date: Thu, 14 Apr 2016 10:42:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <00eb01d19621$430b0d60$c9212820$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 08:42:29 -0000 ITSers, We work on a more rigorous ITS charter text. Now we propose four work items: 1. "Problem statement for IP in V2V and V2I" including "IP addressing architecture for V2V and V2I" and including "Gap Analysis: IP protocols suited and gaps" and including "Use-cases for IP in V2V and V2I moving network to nearby moving or fixed network" 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], including connectivity in fast and asymmetric conditions, coverage area vs speed diagrams, below-IP congestion management. 4. "List of papers and _products_ using IP in V2V and V2I" What do you think? Please respond by next Monday, April 18th. Alex and Dapeng [*] a typical IP-over-foo document is, for example, RFC2464 "Transmission of IPv6 Packets over Ethernet Networks", where "foo" is instantiated as "Ethernet". Other IPv6-over-foo documents are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and more. Le 14/04/2016 09:42, Jérôme Härri a écrit : > Paul, > > Thanks. Btw, when I mentioned ‘people’ are aware of IP V2V but not see > the need (so far), I referred to the automotive SDOs (led by automotive > industries)…, although there are always ‘minority reports’ J > > Cheers, > > Jérôme > > *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] > *Sent:* Thursday 14 April 2016 09:36 > *To:* Jérôme Härri > *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [its] charter ITS > > Jérôme, > > I missed that you are also an academic person. > > I got it :-) > > I understand your points for industry activity related to vehicular > networking. > > Your observation seems true. > > BTW, I will invite you to my team for the draft for a list of academic > papers for V2V and V2I > > by a personal message. > > Thanks. > > Paul > > On Thu, Apr 14, 2016 at 4:09 PM, Jérôme Härri > wrote: > > Hi Paul, > > Thanks for your feedback. Do not get me wrong, I am an academic and with > my team, we also work on IP-based V2V and V2I, in particular related to > mobility management with DMM, but also in the context of vehicular IoT. > > I just have the feeling that people are perfectly aware of the fact that > IP _can_ be used for V2V and V2I, but does not ‘_need_’ to be used as > other solutions already perfectly fit their need. Listing papers will > not change this awareness. > > So, as a complement to academic papers, it would help to be able to > pin-point which industrial activities are using or are strongly planning > (short term I mean) to use pure IPv6 system in vehicles. > > My feeling here is we have a different eco-system that the Automotive > industry (and automotive industry-related SDO)..more likely the IoT > industry…and as such, we should not need to have the (direct) > involvement of automotive industry in the Charter. If we can make this > clear by an industry-based ‘survey’, that would help make the case for > the WG. > > Btw, you can count on me your draft..we can add some IP-based V2V and > V2I for mobility management and also IoT. > > Cheers, > > Jérôme > > *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com > ] > *Sent:* Thursday 14 April 2016 03:22 > *To:* Jérôme Härri > *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [its] charter ITS > > Hi Jérôme, > > I have an opinion on your comment 5) below. > > I think that a list of high-quality papers about IP-based V2V and V2I > > can teach very useful lessons to software designers of IP in V2V and V2I > > in the industry. > > Multiple people are working for this IP-based V2V and V2I > > (including Sandra Cespedes and me) in academia and > > more people(including Nabil Benamar) are willing to work for this area. > > I think we need to utilize the list of such papers as the ground for our > ITS group > > through a WI. Note that the draft of the list will include the summary > of the main > > ideas of the papers. > > For the industry current activities for this area, I believe that you > can share them > > as references through our ITS mailing list rather than through a WI. > > Could you join my team that are making efforts for a list of such papers? > > Thanks. > > Best Regards, > > Paul > > On Thu, Apr 7, 2016 at 8:11 AM, Jérôme Härri > wrote: > > Dear ITSers, Dear Alex, > > Here are some comments on the updated charter: > > 1)Can we keep a reference to IEEE 802.11p, considering it does not exist > anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mode > (and 10Mhz @5.9Ghz) of course. > > 2)Should we really keep C-ACC (or Platooning) in the charter explicitly > as use case, considering it is a seriously controversial aspect with > some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry > mentions traffic efficiency/infotainment applications, such as > in-signage applications... > > a.We might have to aim at less controversial use cases to attract > automotive industries > > 3)One potential WI I could think of (rather a basic one): _definition of > a vehicular wireless ‘link’ in an automotive context_ > > a.To me, this is a fundamental brick in the larger IETF WG ITS house.. > > 4)I would suggest to be more explicit in the foreseen challenges of this > WG, instead of mentioning general use case (which end up be controversial) > > a.Example: maintaining IPv6 connectivity in fast and asymmetric wireless > links; also under quickly changing topologies (actually suggested by > Dick Roy on the chat room) > > b.Example: IPv6 addressing in link-local scope.. > > c.Example: guaranteeing privacy in IPv6 moving networks etc.. > > 5)Before listing academic papers referring to IPv6 in vehicles, I would > suggest to first try to list commercial products/solutions that are in > vehicles and are using IPv6, possibly suffering from a silo limitations > (ex. restricted to a single technology, single use case…) > > a.I think we need to get to products first, before academic visions > > My two cents.. > > Best Regards, > > Jérôme > > *From:*its [mailto:its-bounces@ietf.org ] > *On Behalf Of *Alexandre Petrescu > *Sent:* Wednesday 06 April 2016 23:45 > *To:* its@ietf.org > *Subject:* [its] charter ITS > > ITSers, > > Please see below the current charter. > > - the two Problem Statements drafts V2V and V2I joined, so there is less > text in charter. > - added an Item on "List of Research papers..." > > Erik: did I understand you correctly that there should be some item on > discussing whether link-local addressing is sufficient, whether prefix > exchange is necessary? > > Dino: should LISP be included in the gap analysis draft which includes > C-ACC use-case? OR should we separate a dedicated I-D only with gap > analysis including ND, MIP, AODVv2, LISP? > > Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle > interface illustrated good enough by the words "moving network to nearby > moving network communications"? Or is it better to say "the 1-IP-hop > between nearby moving networks must be self-configured"? > > Nabil, Sandra: is it ok to have a working group item "List of Research > Papers for IP in V2V and V2I communications"? > > Other comments? > > Alex > > ------------------------------------------------------------------ > > ITS (name to change) > Charter > April 6th, 2016 > http://ietf.org/mailman/listinfo/its > > > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming > > Chairs: > TBD > > Assigned Area Director: > TBD > > Mailing list > Address: its@ietf.org > 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: > > Goal > ---- > The goal of this group is to standardize IP-based protocols for > establishing direct and secure connectivity between moving networks, > some of which could be fixed permanently or temporarily. > > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving network to > nearby moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > train, or train-to-intersection signalling. > > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to > the Internet, either as vehicle-to-vehicle, vehicle-to-infra or > vehicle-to-Internet. Entertainment apps enhancing comfort, reliable > data exchanges for road safety, and automated driving are features > coming in automobiles to hit the roads from now to year 2020. > Highlighting increased safety as an immediate result of > hyper-connectivity applied to vehicles, public authorities worldwide > are increasingly mandating secure communication technology > requirements in vehicles. > > Emergency apps for new instrumented ambulances carry many benefits > both to the users and to society in general. > > Why IP? > ------- > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. > However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure > communications are still being developed. To improve on a situation > of link-specific data exchanges, and enable independent application > sets to share the same links, IP data exchanges are needed. Enabling > IP communication between vehicles (V2V), and between vehicles and the > immediate infrastructure (V2I), will provide (0) ability to reach the > rest of the world on the Internet (1) short and deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) ease of > reuse of existing Internet applications in a vehicular environment. > > Moving network to nearby moving network communications involve link > layers such as: 802.11p OCB (Outside the Context of a Basic Service > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light > Communications), IrDA, LTE-D. Only the IP protocols are capable of > running on each of these links and establish IP paths across them in > an interoperable manner. > > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate from one > moving network to another nearby moving network. > > In the automobile space, the Cooperative Adaptive Cruise Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the cross-roads, > the moving network inside a vehicle exchanges data with the moving > network in the red-light pole. > > Several public safety scenarios involve moving networks. Distinct > organizations deploy different moving networks (in-vehicle, on-person) > at an incident scene. These networks need to interoperate in order to > more effectively understand and deal with the incident scene. > > In connected rail scenarios the moving network deployed in trains > communicate with other moving networks at the cross-points. > > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol > enhancements. The 1-hop link-scoped protocols include the protocols > for route establishment involving ICMP Router Advertisements. The > n-hop path management protocols include n-hop path establishment > protocols (e.g. Babel, OSPF) and n-hop path search protocols (most > notably AODV and derivates). > > In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations. > > In some of the moving network applications the window of opportunity > for exchanging data with the immediate infrastructure may be very > short. For example, a car driving near a road-side unit may have only > 5s to exchange with that RSU (depending on speed, RSU range and > number). (ephemeral connections). > > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to nearby moving > network communications are focusing on low delays of the data paths, > reduced number of messages for path establishment, application > friendly, resilience to attacks, compatibility with DHCP and Mobile > IP. > > In addition, some moving network to nearby moving network applications > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the > 1-hop IP moving network to nearby moving netowrk mechanisms will need > to gracefully support IP multicast. > > Due to the inherent characteristics of safety-related communications, > all new moving network to nearby moving network mechanisms must afford > authenticity and confidentiality where necessary. Dynamically > establishing ephemeral communication paths between automobiles in > public areas must offer privacy safeguards for the end users > (passengers). > > Establishing 1-hop IP V2V paths must not break the existing on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. > > In a moving network deployed in an automobile, typically one exit > point connects the moving network to other moving networks. However, > in a more general manner (and to support reliability) any new > mechanism of moving network to nearby moving network communications > should support multi-homing: one router to use multiple interfaces > towards outside the moving network, or multiple routers. > > Current version of Internet protocols > ------------------------------------- > The group will only work on IPv6 solutions. > > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to nearby moving > network communications, often involving IPv6, and novel V2V and > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For > Vehicle-to-Internet communications, 3GPP LTE and other cellular > technologies represent the long-range connectivity method; for > Vehicle-to-Vehicle communications, LTE Direct is currently specified, > as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need > for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive > Cruise Control and Platooning. The IEEE developed a popular link for > short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a > set of requirements for V2V communications. > > Work Items > ---------- > - use-cases for moving network to nearby moving network communications > - Problem Statement for moving network to nearby moving network > communications > including V2V, V2I and DNS. > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Solutions, which might include new protocols or extensions to > existing protocols. With MIB. > - IPv6-over foo, where foo is pertinent for moving network to nearby > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) > - List of Research Papers in the V2V domain, identifying which uses IP. > > Timeline > -------- > - > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com , > pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com , > pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > From nobody Thu Apr 14 02:34:58 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D98012D139 for ; Thu, 14 Apr 2016 02:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGunMtnV2qua for ; Thu, 14 Apr 2016 02:34:53 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id AFEEC12D0F2 for ; Thu, 14 Apr 2016 02:34:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,484,1454972400"; d="scan'208";a="3676107" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 14 Apr 2016 11:34:51 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 1EE7CBA6; Thu, 14 Apr 2016 11:34:51 +0200 (CEST) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , "'Mr. Jaehoon Paul Jeong'" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F4F7A.8010109@gmail.com> In-Reply-To: <570F4F7A.8010109@gmail.com> Date: Thu, 14 Apr 2016 11:34:50 +0200 Organization: EURECOM Message-ID: <002101d19630$e4a65e40$adf31ac0$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt54qCPzaRhlgKe35lrbFRjfOAYQFS/geMAQE6Hj0B9Z2NrAFvPFpVAgXLDlYCApPD9KAChpuQ Content-Language: en-us Archived-At: Cc: its@ietf.org Subject: Re: [its] charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 09:34:56 -0000 Hi Alex, So far, CAR 2 CAR and ETSI ITS, both mentioned that can do without.=20 Best, J=C3=A9r=C3=B4me -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Thursday 14 April 2016 10:06 To: J=C3=A9r=C3=B4me H=C3=A4rri; 'Mr. Jaehoon Paul Jeong' Cc: its@ietf.org Subject: Re: [its] charter ITS Le 14/04/2016 09:42, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : > Paul, > > Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of IP = V2V but not see=20 > the need (so far), I referred to the automotive SDOs (led by=20 > automotive industries)=E2=80=A6, although there are always = =E2=80=98minority reports=E2=80=99=20 > J J=C3=A9r=C3=B4me, Along the automotive SDO discussion. Which other SDO is not sure about using IP for C-ACC but maybe for other = use-cases.? Alex > > Cheers, > > J=C3=A9r=C3=B4me > > *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] > *Sent:* Thursday 14 April 2016 09:36 > *To:* J=C3=A9r=C3=B4me H=C3=A4rri > *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [its] charter ITS > > J=C3=A9r=C3=B4me, > > I missed that you are also an academic person. > > I got it :-) > > I understand your points for industry activity related to vehicular=20 > networking. > > Your observation seems true. > > BTW, I will invite you to my team for the draft for a list of academic = > papers for V2V and V2I > > by a personal message. > > Thanks. > > Paul > > On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri=20 > > wrote: > > Hi Paul, > > Thanks for your feedback. Do not get me wrong, I am an academic and=20 > with my team, we also work on IP-based V2V and V2I, in particular=20 > related to mobility management with DMM, but also in the context of = vehicular IoT. > > I just have the feeling that people are perfectly aware of the fact=20 > that IP _can_ be used for V2V and V2I, but does not = =E2=80=98_need_=E2=80=99 to be=20 > used as other solutions already perfectly fit their need. Listing=20 > papers will not change this awareness. > > So, as a complement to academic papers, it would help to be able to=20 > pin-point which industrial activities are using or are strongly=20 > planning (short term I mean) to use pure IPv6 system in vehicles. > > My feeling here is we have a different eco-system that the Automotive=20 > industry (and automotive industry-related SDO)..more likely the IoT=20 > industry=E2=80=A6and as such, we should not need to have the (direct)=20 > involvement of automotive industry in the Charter. If we can make this = > clear by an industry-based =E2=80=98survey=E2=80=99, that would help = make the case for=20 > the WG. > > Btw, you can count on me your draft..we can add some IP-based V2V and=20 > V2I for mobility management and also IoT. > > Cheers, > > J=C3=A9r=C3=B4me > > *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com=20 > ] > *Sent:* Thursday 14 April 2016 03:22 > *To:* J=C3=A9r=C3=B4me H=C3=A4rri > *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [its] charter ITS > > Hi J=C3=A9r=C3=B4me, > > I have an opinion on your comment 5) below. > > I think that a list of high-quality papers about IP-based V2V and V2I > > can teach very useful lessons to software designers of IP in V2V and=20 > V2I > > in the industry. > > Multiple people are working for this IP-based V2V and V2I > > (including Sandra Cespedes and me) in academia and > > more people(including Nabil Benamar) are willing to work for this = area. > > I think we need to utilize the list of such papers as the ground for=20 > our ITS group > > through a WI. Note that the draft of the list will include the summary = > of the main > > ideas of the papers. > > For the industry current activities for this area, I believe that you=20 > can share them > > as references through our ITS mailing list rather than through a WI. > > Could you join my team that are making efforts for a list of such = papers? > > Thanks. > > Best Regards, > > Paul > > On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri = > wrote: > > Dear ITSers, Dear Alex, > > Here are some comments on the updated charter: > > 1)Can we keep a reference to IEEE 802.11p, considering it does not=20 > exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB = > mode (and 10Mhz @5.9Ghz) of course. > > 2)Should we really keep C-ACC (or Platooning) in the charter=20 > explicitly as use case, considering it is a seriously controversial=20 > aspect with some SDOs (ex. In Automotive SDOs)? In the ISO=20 > presentation, Thierry mentions traffic efficiency/infotainment=20 > applications, such as in-signage applications... > > a.We might have to aim at less controversial use cases to attract=20 > automotive industries > > 3)One potential WI I could think of (rather a basic one): _definition=20 > of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive = context_ > > a.To me, this is a fundamental brick in the larger IETF WG ITS = house.. > > 4)I would suggest to be more explicit in the foreseen challenges of=20 > this WG, instead of mentioning general use case (which end up be=20 > controversial) > > a.Example: maintaining IPv6 connectivity in fast and asymmetric=20 > wireless links; also under quickly changing topologies (actually=20 > suggested by Dick Roy on the chat room) > > b.Example: IPv6 addressing in link-local scope.. > > c.Example: guaranteeing privacy in IPv6 moving networks etc.. > > 5)Before listing academic papers referring to IPv6 in vehicles, I=20 > would suggest to first try to list commercial products/solutions that=20 > are in vehicles and are using IPv6, possibly suffering from a silo=20 > limitations (ex. restricted to a single technology, single use = case=E2=80=A6) > > a.I think we need to get to products first, before academic visions > > My two cents.. > > Best Regards, > > J=C3=A9r=C3=B4me > > *From:*its [mailto:its-bounces@ietf.org ] = > *On Behalf Of *Alexandre Petrescu > *Sent:* Wednesday 06 April 2016 23:45 > *To:* its@ietf.org > *Subject:* [its] charter ITS > > ITSers, > > Please see below the current charter. > > - the two Problem Statements drafts V2V and V2I joined, so there is=20 > less text in charter. > - added an Item on "List of Research papers..." > > Erik: did I understand you correctly that there should be some item on = > discussing whether link-local addressing is sufficient, whether prefix = > exchange is necessary? > > Dino: should LISP be included in the gap analysis draft which includes = > C-ACC use-case? OR should we separate a dedicated I-D only with gap=20 > analysis including ND, MIP, AODVv2, LISP? > > Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle = > interface illustrated good enough by the words "moving network to=20 > nearby moving network communications"? Or is it better to say "the=20 > 1-IP-hop between nearby moving networks must be self-configured"? > > Nabil, Sandra: is it ok to have a working group item "List of Research = > Papers for IP in V2V and V2I communications"? > > Other comments? > > Alex > > ------------------------------------------------------------------ > > ITS (name to change) > Charter > April 6th, 2016 > http://ietf.org/mailman/listinfo/its > > > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming > > Chairs: > TBD > > Assigned Area Director: > TBD > > Mailing list > Address: its@ietf.org > 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: > > Goal > ---- > The goal of this group is to standardize IP-based protocols for=20 > establishing direct and secure connectivity between moving networks,=20 > some of which could be fixed permanently or temporarily. > > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving network to = > nearby moving network communications. For example: vehicle-to-vehicle = > communications, nomadic user wearing a PAN and communicating to a=20 > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a = > train, or train-to-intersection signalling. > > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to=20 > the Internet, either as vehicle-to-vehicle, vehicle-to-infra or=20 > vehicle-to-Internet. Entertainment apps enhancing comfort, reliable=20 > data exchanges for road safety, and automated driving are features=20 > coming in automobiles to hit the roads from now to year 2020. > Highlighting increased safety as an immediate result of=20 > hyper-connectivity applied to vehicles, public authorities worldwide=20 > are increasingly mandating secure communication technology=20 > requirements in vehicles. > > Emergency apps for new instrumented ambulances carry many benefits=20 > both to the users and to society in general. > > Why IP? > ------- > Today, there are several deployed Vehicle-to-Internet technologies,=20 > including car tethering through driver's cellular smartphone. > However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure=20 > communications are still being developed. To improve on a situation=20 > of link-specific data exchanges, and enable independent application=20 > sets to share the same links, IP data exchanges are needed. Enabling=20 > IP communication between vehicles (V2V), and between vehicles and the=20 > immediate infrastructure (V2I), will provide (0) ability to reach the=20 > rest of the world on the Internet (1) short and deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) ease of=20 > reuse of existing Internet applications in a vehicular environment. > > Moving network to nearby moving network communications involve link=20 > layers such as: 802.11p OCB (Outside the Context of a Basic Service=20 > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light=20 > Communications), IrDA, LTE-D. Only the IP protocols are capable of=20 > running on each of these links and establish IP paths across them in=20 > an interoperable manner. > > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate from one=20 > moving network to another nearby moving network. > > In the automobile space, the Cooperative Adaptive Cruise Control and=20 > Platooning features consider that vehicles close to each other=20 > exchange data describing their kinematic status. At the cross-roads,=20 > the moving network inside a vehicle exchanges data with the moving=20 > network in the red-light pole. > > Several public safety scenarios involve moving networks. Distinct=20 > organizations deploy different moving networks (in-vehicle, on-person) = > at an incident scene. These networks need to interoperate in order to = > more effectively understand and deal with the incident scene. > > In connected rail scenarios the moving network deployed in trains=20 > communicate with other moving networks at the cross-points. > > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network=20 > to nearby moving network communications are of two kinds: IP routing=20 > protocols for n-hop path management and 1-hop link-scoped IP protocol=20 > enhancements. The 1-hop link-scoped protocols include the protocols=20 > for route establishment involving ICMP Router Advertisements. The=20 > n-hop path management protocols include n-hop path establishment=20 > protocols (e.g. Babel, OSPF) and n-hop path search protocols (most=20 > notably AODV and derivates). > > In this proposed Working Group the focus is on 1-hop protocols, and=20 > leverage from other Working Groups for the n-hop situations. > > In some of the moving network applications the window of opportunity=20 > for exchanging data with the immediate infrastructure may be very=20 > short. For example, a car driving near a road-side unit may have only = > 5s to exchange with that RSU (depending on speed, RSU range and=20 > number). (ephemeral connections). > > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to nearby moving=20 > network communications are focusing on low delays of the data paths,=20 > reduced number of messages for path establishment, application=20 > friendly, resilience to attacks, compatibility with DHCP and Mobile=20 > IP. > > In addition, some moving network to nearby moving network applications = > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the=20 > 1-hop IP moving network to nearby moving netowrk mechanisms will need=20 > to gracefully support IP multicast. > > Due to the inherent characteristics of safety-related communications,=20 > all new moving network to nearby moving network mechanisms must afford = > authenticity and confidentiality where necessary. Dynamically=20 > establishing ephemeral communication paths between automobiles in=20 > public areas must offer privacy safeguards for the end users=20 > (passengers). > > Establishing 1-hop IP V2V paths must not break the existing on-board=20 > protocols and applications which communicate with the Internet,=20 > possibly via multiple radios. > > In a moving network deployed in an automobile, typically one exit=20 > point connects the moving network to other moving networks. However,=20 > in a more general manner (and to support reliability) any new=20 > mechanism of moving network to nearby moving network communications=20 > should support multi-homing: one router to use multiple interfaces=20 > towards outside the moving network, or multiple routers. > > Current version of Internet protocols > ------------------------------------- > The group will only work on IPv6 solutions. > > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to nearby moving=20 > network communications, often involving IPv6, and novel V2V and=20 > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent=20 > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For=20 > Vehicle-to-Internet communications, 3GPP LTE and other cellular=20 > technologies represent the long-range connectivity method; for=20 > Vehicle-to-Vehicle communications, LTE Direct is currently specified,=20 > as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need=20 > for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive=20 > Cruise Control and Platooning. The IEEE developed a popular link for=20 > short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a=20 > set of requirements for V2V communications. > > Work Items > ---------- > - use-cases for moving network to nearby moving network communications > - Problem Statement for moving network to nearby moving network=20 > communications > including V2V, V2I and DNS. > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Solutions, which might include new protocols or extensions to > existing protocols. With MIB. > - IPv6-over foo, where foo is pertinent for moving network to nearby > moving network communications (e.g. 802.11 OCB, VLC, LTE-D,=20 > 802.11ad) > - List of Research Papers in the V2V domain, identifying which uses = IP. > > Timeline > -------- > - > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > -- > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com ,=20 > pauljeong@skku.edu Personal Homepage:=20 > http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > -- > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com ,=20 > pauljeong@skku.edu Personal Homepage:=20 > http://iotlab.skku.edu/people-jaehoon-jeong.php > > From nobody Thu Apr 14 02:47:04 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7079812DE0F for ; Thu, 14 Apr 2016 02:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl_2DYbp5sLE for ; Thu, 14 Apr 2016 02:47:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 652BF12DE33 for ; Thu, 14 Apr 2016 02:46:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMD55234; Thu, 14 Apr 2016 09:46:56 +0000 (GMT) Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 14 Apr 2016 10:46:49 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.243]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Thu, 14 Apr 2016 17:46:42 +0800 From: "Huangjing (A)" To: Alexandre Petrescu Thread-Topic: [its] charter ITS - proposed work items Thread-Index: AQHRlimjCOuG32IJiEClxJDarEfoGJ+JNmGA Date: Thu, 14 Apr 2016 09:46:42 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BCB4786BE0@SZXEMA501-MBX.china.huawei.com> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> In-Reply-To: <570F57EB.4060606@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.116.136] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.570F6711.00EA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.243, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7e6f0418c8f8c619a0f33173f063a827 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 09:47:03 -0000 SGksIEFsZXgsDQoNCkNvbW1lbnRzIGJlbG93Lg0KDQpKYW1lcw0KDQo+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj5Gcm9tOiBpdHMgW21haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFsZXhhbmRyZSBQZXRyZXNjdQ0KPlNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNCwg MjAxNiA0OjQyIFBNDQo+VG86IGl0c0BpZXRmLm9yZw0KPlN1YmplY3Q6IFtpdHNdIGNoYXJ0ZXIg SVRTIC0gcHJvcG9zZWQgd29yayBpdGVtcw0KPg0KPklUU2VycywNCj4NCj5XZSB3b3JrIG9uIGEg bW9yZSByaWdvcm91cyBJVFMgY2hhcnRlciB0ZXh0Lg0KPg0KPk5vdyB3ZSBwcm9wb3NlIGZvdXIg d29yayBpdGVtczoNCj4NCj4xLiAiUHJvYmxlbSBzdGF0ZW1lbnQgZm9yIElQIGluIFYyViBhbmQg VjJJIg0KPiAgICBpbmNsdWRpbmcgIklQIGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJlIGZvciBWMlYg YW5kIFYySSINCj4gICAgYW5kIGluY2x1ZGluZyAiR2FwIEFuYWx5c2lzOiBJUCBwcm90b2NvbHMg c3VpdGVkIGFuZCBnYXBzIg0KPiAgICBhbmQgaW5jbHVkaW5nICJVc2UtY2FzZXMgZm9yIElQIGlu IFYyViBhbmQgVjJJIG1vdmluZyBuZXR3b3JrIHRvDQo+ICAgICAgICAgICAgICAgICAgIG5lYXJi eSBtb3Zpbmcgb3IgZml4ZWQgbmV0d29yayINCj4NCj4yLiAiVGhyZWF0IEFuYWx5c2lzIGZvciBJ UCBwcmVmaXggZXhjaGFuZ2VzIGluIFYyViBhbmQgVjJJIGNvbnRleHQiDQo+DQo+My4gIklQIG92 ZXIgRFNSQyAoODAyLjExLU9DQikiIHR5cGljYWwgSVAtb3Zlci1mb28gZG9jdW1lbnRbKl0sDQo+ ICAgIGluY2x1ZGluZyBjb25uZWN0aXZpdHkgaW4gZmFzdCBhbmQgYXN5bW1ldHJpYyBjb25kaXRp b25zLCBjb3ZlcmFnZQ0KPiAgICBhcmVhIHZzIHNwZWVkIGRpYWdyYW1zLCBiZWxvdy1JUCBjb25n ZXN0aW9uIG1hbmFnZW1lbnQuDQo+DQo+NC4gIkxpc3Qgb2YgcGFwZXJzIGFuZCBfcHJvZHVjdHNf IHVzaW5nIElQIGluIFYyViBhbmQgVjJJIg0KDQpJdCBtYXkgYmUgdXNlZnVsIHRvIGZ1cnRoZXIg ZGlzdGluZ3Vpc2ggd2hpY2ggdXNlIGNhc2VzIGFyZSAxLWhvcCBjb25uZWN0aW9uIGFuZCB3aGlj aCBhcmUgbXVsdGktaG9wIGNvbm5lY3Rpb24uDQpNeSBwZXJjZXB0aW9uIGlzLCB0aGUgZGlzY3Vz c2lvbiBpbiB0aGUgbGlzdCBhbmQgYXQgdGhlIElFVEYgbWVldGluZyBpbnZvbHZlZCBxdWl0ZSBz b21lIGlzc3VlcyB0aGF0IGFyZSBtdWx0aS1ob3AgcmVsYXRlZCwgc3VjaCBhcyBtb2JpbGl0eSwg YWRkcmVzcyBhbGxvY2F0aW9uIGFuZCBtYW5hZ2VtZW50LCByb3V0aW5nIGFsZ29yaXRobSwgZXRj Lg0KSWYgdGhpcyBncm91cCBvbmx5IGZvY3VzIG9uIDEtaG9wLCB3ZSBwcm9iYWJseSBkbyBub3Qg aGF2ZSB0byBjYXJlIGFib3V0IHRoZXNlIGlzc3VlczsgYnV0IGlmIG11bHRpLWhvcCBzY2VuYXJp b3MgaGF2ZSB0byBiZSBjb25zaWRlcmVkIChtYXliZSBpbiB0aGUgZnV0dXJlKSwgdGhlbiB3ZSBt YXkgaGF2ZSB0byB0aGluayBhYm91dCB0aGVtLg0KVGhlIHBhcGVycyBhbmQgX3Byb2R1Y3RzXyBN SUdIVCBiZSBhYmxlIHRvIGdpdmUgdXMgc29tZSBoaW50cyBvbiBob3AocykgcmVsYXRlZCBpc3N1 ZXMuDQoNCj4NCj5XaGF0IGRvIHlvdSB0aGluaz8NCj4NCj5QbGVhc2UgcmVzcG9uZCBieSBuZXh0 IE1vbmRheSwgQXByaWwgMTh0aC4NCj4NCj5BbGV4IGFuZCBEYXBlbmcNCj5bKl0gYSB0eXBpY2Fs IElQLW92ZXItZm9vIGRvY3VtZW50IGlzLCBmb3IgZXhhbXBsZSwgUkZDMjQ2NA0KPiAgICAgIlRy YW5zbWlzc2lvbiBvZiBJUHY2IFBhY2tldHMgb3ZlciBFdGhlcm5ldCBOZXR3b3JrcyIsIHdoZXJl DQo+ICAgICAiZm9vIiBpcyBpbnN0YW50aWF0ZWQgYXMgIkV0aGVybmV0Ii4gIE90aGVyIElQdjYt b3Zlci1mb28gZG9jdW1lbnRzDQo+ICAgICBhcmUgUkZDNDk0NCAiSVB2NiBvdmVyIDgwMi4xNS40 IiBSRkM1MDcyICJJUHY2IG92ZXIgUFBQIiBhbmQgbW9yZS4NCj4NCj5MZSAxNC8wNC8yMDE2IDA5 OjQyLCBKw6lyw7RtZSBIw6RycmkgYSDDqWNyaXQgOg0KPj4gUGF1bCwNCj4+DQo+PiBUaGFua3Mu IEJ0dywgd2hlbiBJIG1lbnRpb25lZCDigJhwZW9wbGXigJkgYXJlIGF3YXJlIG9mIElQIFYyViBi dXQgbm90IHNlZQ0KPj4gdGhlIG5lZWQgKHNvIGZhciksIEkgcmVmZXJyZWQgdG8gdGhlIGF1dG9t b3RpdmUgU0RPcyAobGVkIGJ5DQo+PiBhdXRvbW90aXZlIGluZHVzdHJpZXMp4oCmLCBhbHRob3Vn aCB0aGVyZSBhcmUgYWx3YXlzIOKAmG1pbm9yaXR5IHJlcG9ydHPigJkNCj4+IEoNCj4+DQo+PiBD aGVlcnMsDQo+Pg0KPj4gSsOpcsO0bWUNCj4+DQo+PiAqRnJvbToqTXIuIEphZWhvb24gUGF1bCBK ZW9uZyBbbWFpbHRvOmphZWhvb24ucGF1bEBnbWFpbC5jb21dDQo+PiAqU2VudDoqIFRodXJzZGF5 IDE0IEFwcmlsIDIwMTYgMDk6MzYNCj4+ICpUbzoqIErDqXLDtG1lIEjDpHJyaQ0KPj4gKkNjOiog QWxleGFuZHJlIFBldHJlc2N1OyBpdHNAaWV0Zi5vcmcNCj4+ICpTdWJqZWN0OiogUmU6IFtpdHNd IGNoYXJ0ZXIgSVRTDQo+Pg0KPj4gSsOpcsO0bWUsDQo+Pg0KPj4gSSBtaXNzZWQgdGhhdCB5b3Ug YXJlIGFsc28gYW4gYWNhZGVtaWMgcGVyc29uLg0KPj4NCj4+IEkgZ290IGl0IDotKQ0KPj4NCj4+ IEkgdW5kZXJzdGFuZCB5b3VyIHBvaW50cyBmb3IgaW5kdXN0cnkgYWN0aXZpdHkgcmVsYXRlZCB0 byB2ZWhpY3VsYXINCj4+IG5ldHdvcmtpbmcuDQo+Pg0KPj4gWW91ciBvYnNlcnZhdGlvbiBzZWVt cyB0cnVlLg0KPj4NCj4+IEJUVywgSSB3aWxsIGludml0ZSB5b3UgdG8gbXkgdGVhbSBmb3IgdGhl IGRyYWZ0IGZvciBhIGxpc3Qgb2YgYWNhZGVtaWMNCj4+IHBhcGVycyBmb3IgVjJWIGFuZCBWMkkN Cj4+DQo+PiBieSBhIHBlcnNvbmFsIG1lc3NhZ2UuDQo+Pg0KPj4gVGhhbmtzLg0KPj4NCj4+IFBh dWwNCj4+DQo+PiBPbiBUaHUsIEFwciAxNCwgMjAxNiBhdCA0OjA5IFBNLCBKw6lyw7RtZSBIw6Ry cmkNCj4+IDxqZXJvbWUuaGFlcnJpQGV1cmVjb20uZnIgPG1haWx0bzpqZXJvbWUuaGFlcnJpQGV1 cmVjb20uZnI+PiB3cm90ZToNCj4+DQo+PiBIaSBQYXVsLA0KPj4NCj4+IFRoYW5rcyBmb3IgeW91 ciBmZWVkYmFjay4gRG8gbm90IGdldCBtZSB3cm9uZywgSSBhbSBhbiBhY2FkZW1pYyBhbmQNCj4+ IHdpdGggbXkgdGVhbSwgd2UgYWxzbyB3b3JrIG9uIElQLWJhc2VkIFYyViBhbmQgVjJJLCBpbiBw YXJ0aWN1bGFyDQo+PiByZWxhdGVkIHRvIG1vYmlsaXR5IG1hbmFnZW1lbnQgd2l0aCBETU0sIGJ1 dCBhbHNvIGluIHRoZSBjb250ZXh0IG9mDQo+dmVoaWN1bGFyIElvVC4NCj4+DQo+PiBJIGp1c3Qg aGF2ZSB0aGUgZmVlbGluZyB0aGF0IHBlb3BsZSBhcmUgcGVyZmVjdGx5IGF3YXJlIG9mIHRoZSBm YWN0DQo+PiB0aGF0IElQIF9jYW5fIGJlIHVzZWQgZm9yIFYyViBhbmQgVjJJLCBidXQgZG9lcyBu b3Qg4oCYX25lZWRf4oCZIHRvIGJlDQo+PiB1c2VkIGFzIG90aGVyIHNvbHV0aW9ucyBhbHJlYWR5 IHBlcmZlY3RseSBmaXQgdGhlaXIgbmVlZC4gTGlzdGluZw0KPj4gcGFwZXJzIHdpbGwgbm90IGNo YW5nZSB0aGlzIGF3YXJlbmVzcy4NCj4+DQo+PiBTbywgYXMgYSBjb21wbGVtZW50IHRvIGFjYWRl bWljIHBhcGVycywgaXQgd291bGQgaGVscCB0byBiZSBhYmxlIHRvDQo+PiBwaW4tcG9pbnQgd2hp Y2ggaW5kdXN0cmlhbCBhY3Rpdml0aWVzIGFyZSB1c2luZyBvciBhcmUgc3Ryb25nbHkNCj4+IHBs YW5uaW5nIChzaG9ydCB0ZXJtIEkgbWVhbikgdG8gdXNlIHB1cmUgSVB2NiBzeXN0ZW0gaW4gdmVo aWNsZXMuDQo+Pg0KPj4gTXkgZmVlbGluZyBoZXJlIGlzIHdlIGhhdmUgYSBkaWZmZXJlbnQgZWNv LXN5c3RlbSB0aGF0IHRoZSBBdXRvbW90aXZlDQo+PiBpbmR1c3RyeSAoYW5kIGF1dG9tb3RpdmUg aW5kdXN0cnktcmVsYXRlZCBTRE8pLi5tb3JlIGxpa2VseSB0aGUgSW9UDQo+PiBpbmR1c3RyeeKA pmFuZCBhcyBzdWNoLCB3ZSBzaG91bGQgbm90IG5lZWQgdG8gaGF2ZSB0aGUgKGRpcmVjdCkNCj4+ IGludm9sdmVtZW50IG9mIGF1dG9tb3RpdmUgaW5kdXN0cnkgaW4gdGhlIENoYXJ0ZXIuIElmIHdl IGNhbiBtYWtlIHRoaXMNCj4+IGNsZWFyIGJ5IGFuIGluZHVzdHJ5LWJhc2VkIOKAmHN1cnZleeKA mSwgdGhhdCB3b3VsZCBoZWxwIG1ha2UgdGhlIGNhc2UgZm9yDQo+PiB0aGUgV0cuDQo+Pg0KPj4g QnR3LCB5b3UgY2FuIGNvdW50IG9uIG1lIHlvdXIgZHJhZnQuLndlIGNhbiBhZGQgc29tZSBJUC1i YXNlZCBWMlYgYW5kDQo+PiBWMkkgZm9yIG1vYmlsaXR5IG1hbmFnZW1lbnQgYW5kIGFsc28gSW9U Lg0KPj4NCj4+IENoZWVycywNCj4+DQo+PiBKw6lyw7RtZQ0KPj4NCj4+ICpGcm9tOipNci4gSmFl aG9vbiBQYXVsIEplb25nIFttYWlsdG86amFlaG9vbi5wYXVsQGdtYWlsLmNvbQ0KPj4gPG1haWx0 bzpqYWVob29uLnBhdWxAZ21haWwuY29tPl0NCj4+ICpTZW50OiogVGh1cnNkYXkgMTQgQXByaWwg MjAxNiAwMzoyMg0KPj4gKlRvOiogSsOpcsO0bWUgSMOkcnJpDQo+PiAqQ2M6KiBBbGV4YW5kcmUg UGV0cmVzY3U7IGl0c0BpZXRmLm9yZyA8bWFpbHRvOml0c0BpZXRmLm9yZz4NCj4+ICpTdWJqZWN0 OiogUmU6IFtpdHNdIGNoYXJ0ZXIgSVRTDQo+Pg0KPj4gSGkgSsOpcsO0bWUsDQo+Pg0KPj4gSSBo YXZlIGFuIG9waW5pb24gb24geW91ciBjb21tZW50IDUpIGJlbG93Lg0KPj4NCj4+IEkgdGhpbmsg dGhhdCBhIGxpc3Qgb2YgaGlnaC1xdWFsaXR5IHBhcGVycyBhYm91dCBJUC1iYXNlZCBWMlYgYW5k IFYySQ0KPj4NCj4+IGNhbiB0ZWFjaCB2ZXJ5IHVzZWZ1bCBsZXNzb25zIHRvIHNvZnR3YXJlIGRl c2lnbmVycyBvZiBJUCBpbiBWMlYgYW5kDQo+PiBWMkkNCj4+DQo+PiBpbiB0aGUgaW5kdXN0cnku DQo+Pg0KPj4gTXVsdGlwbGUgcGVvcGxlIGFyZSB3b3JraW5nIGZvciB0aGlzIElQLWJhc2VkIFYy ViBhbmQgVjJJDQo+Pg0KPj4gKGluY2x1ZGluZyBTYW5kcmEgQ2VzcGVkZXMgYW5kIG1lKSBpbiBh Y2FkZW1pYSBhbmQNCj4+DQo+PiBtb3JlIHBlb3BsZShpbmNsdWRpbmcgTmFiaWwgQmVuYW1hcikg YXJlIHdpbGxpbmcgdG8gd29yayBmb3IgdGhpcyBhcmVhLg0KPj4NCj4+IEkgdGhpbmsgd2UgbmVl ZCB0byB1dGlsaXplIHRoZSBsaXN0IG9mIHN1Y2ggcGFwZXJzIGFzIHRoZSBncm91bmQgZm9yDQo+ PiBvdXIgSVRTIGdyb3VwDQo+Pg0KPj4gdGhyb3VnaCBhIFdJLiBOb3RlIHRoYXQgdGhlIGRyYWZ0 IG9mIHRoZSBsaXN0IHdpbGwgaW5jbHVkZSB0aGUgc3VtbWFyeQ0KPj4gb2YgdGhlIG1haW4NCj4+ DQo+PiBpZGVhcyBvZiB0aGUgcGFwZXJzLg0KPj4NCj4+IEZvciB0aGUgaW5kdXN0cnkgY3VycmVu dCBhY3Rpdml0aWVzIGZvciB0aGlzIGFyZWEsIEkgYmVsaWV2ZSB0aGF0IHlvdQ0KPj4gY2FuIHNo YXJlIHRoZW0NCj4+DQo+PiBhcyByZWZlcmVuY2VzIHRocm91Z2ggb3VyIElUUyBtYWlsaW5nIGxp c3QgcmF0aGVyIHRoYW4gdGhyb3VnaCBhIFdJLg0KPj4NCj4+IENvdWxkIHlvdSBqb2luIG15IHRl YW0gdGhhdCBhcmUgbWFraW5nIGVmZm9ydHMgZm9yIGEgbGlzdCBvZiBzdWNoIHBhcGVycz8NCj4+ DQo+PiBUaGFua3MuDQo+Pg0KPj4gQmVzdCBSZWdhcmRzLA0KPj4NCj4+IFBhdWwNCj4+DQo+PiBP biBUaHUsIEFwciA3LCAyMDE2IGF0IDg6MTEgQU0sIErDqXLDtG1lIEjDpHJyaSA8amVyb21lLmhh ZXJyaUBldXJlY29tLmZyDQo+PiA8bWFpbHRvOmplcm9tZS5oYWVycmlAZXVyZWNvbS5mcj4+IHdy b3RlOg0KPj4NCj4+IERlYXIgSVRTZXJzLCAgRGVhciBBbGV4LA0KPj4NCj4+IEhlcmUgYXJlIHNv bWUgY29tbWVudHMgb24gdGhlIHVwZGF0ZWQgY2hhcnRlcjoNCj4+DQo+PiAxKUNhbiB3ZSBrZWVw IGEgcmVmZXJlbmNlIHRvIElFRUUgODAyLjExcCwgY29uc2lkZXJpbmcgaXQgZG9lcyBub3QNCj4+ IGV4aXN0IGFueW1vcmU/IEl0IGlzIG5vdyBmdWxseSBpbnRlZ3JhdGVkIGludG8gSUVFRSA4MDIu MTEtMjAxMiBhcyBPQ0INCj4+IG1vZGUgKGFuZCAxME1oeiBANS45R2h6KSBvZiBjb3Vyc2UuDQo+ Pg0KPj4gMilTaG91bGQgd2UgcmVhbGx5IGtlZXAgQy1BQ0MgKG9yIFBsYXRvb25pbmcpIGluIHRo ZSBjaGFydGVyDQo+PiBleHBsaWNpdGx5IGFzIHVzZSBjYXNlLCBjb25zaWRlcmluZyBpdCBpcyBh IHNlcmlvdXNseSBjb250cm92ZXJzaWFsDQo+PiBhc3BlY3Qgd2l0aCBzb21lIFNET3MgKGV4LiBJ biBBdXRvbW90aXZlIFNET3MpPyBJbiB0aGUgSVNPDQo+PiBwcmVzZW50YXRpb24sIFRoaWVycnkg bWVudGlvbnMgdHJhZmZpYyBlZmZpY2llbmN5L2luZm90YWlubWVudA0KPj4gYXBwbGljYXRpb25z LCBzdWNoIGFzIGluLXNpZ25hZ2UgYXBwbGljYXRpb25zLi4uDQo+Pg0KPj4gYS5XZSBtaWdodCBo YXZlIHRvIGFpbSBhdCBsZXNzIGNvbnRyb3ZlcnNpYWwgdXNlIGNhc2VzIHRvIGF0dHJhY3QNCj4+ IGF1dG9tb3RpdmUgaW5kdXN0cmllcw0KPj4NCj4+IDMpT25lIHBvdGVudGlhbCBXSSBJIGNvdWxk IHRoaW5rIG9mIChyYXRoZXIgYSBiYXNpYyBvbmUpOiBfZGVmaW5pdGlvbg0KPj4gb2YgYSB2ZWhp Y3VsYXIgd2lyZWxlc3Mg4oCYbGlua+KAmSBpbiBhbiBhdXRvbW90aXZlIGNvbnRleHRfDQo+Pg0K Pj4gYS5UbyBtZSwgdGhpcyBpcyAgYSBmdW5kYW1lbnRhbCBicmljayBpbiB0aGUgbGFyZ2VyIElF VEYgV0cgSVRTIGhvdXNlLi4NCj4+DQo+PiA0KUkgd291bGQgc3VnZ2VzdCB0byBiZSBtb3JlIGV4 cGxpY2l0IGluIHRoZSBmb3Jlc2VlbiBjaGFsbGVuZ2VzIG9mDQo+PiB0aGlzIFdHLCBpbnN0ZWFk IG9mIG1lbnRpb25pbmcgZ2VuZXJhbCB1c2UgY2FzZSAod2hpY2ggZW5kIHVwIGJlDQo+PiBjb250 cm92ZXJzaWFsKQ0KPj4NCj4+IGEuRXhhbXBsZTogbWFpbnRhaW5pbmcgSVB2NiBjb25uZWN0aXZp dHkgaW4gZmFzdCBhbmQgYXN5bW1ldHJpYw0KPj4gd2lyZWxlc3MgbGlua3M7IGFsc28gdW5kZXIg cXVpY2tseSBjaGFuZ2luZyB0b3BvbG9naWVzIChhY3R1YWxseQ0KPj4gc3VnZ2VzdGVkIGJ5IERp Y2sgUm95IG9uIHRoZSBjaGF0IHJvb20pDQo+Pg0KPj4gYi5FeGFtcGxlOiBJUHY2IGFkZHJlc3Np bmcgaW4gbGluay1sb2NhbCBzY29wZS4uDQo+Pg0KPj4gYy5FeGFtcGxlOiBndWFyYW50ZWVpbmcg cHJpdmFjeSBpbiBJUHY2IG1vdmluZyBuZXR3b3JrcyBldGMuLg0KPj4NCj4+IDUpQmVmb3JlIGxp c3RpbmcgYWNhZGVtaWMgcGFwZXJzIHJlZmVycmluZyB0byBJUHY2IGluIHZlaGljbGVzLCBJDQo+ PiB3b3VsZCBzdWdnZXN0IHRvIGZpcnN0IHRyeSB0byBsaXN0IGNvbW1lcmNpYWwgcHJvZHVjdHMv c29sdXRpb25zIHRoYXQNCj4+IGFyZSBpbiB2ZWhpY2xlcyBhbmQgYXJlIHVzaW5nIElQdjYsIHBv c3NpYmx5IHN1ZmZlcmluZyBmcm9tIGEgc2lsbw0KPj4gbGltaXRhdGlvbnMgKGV4LiByZXN0cmlj dGVkIHRvIGEgc2luZ2xlIHRlY2hub2xvZ3ksIHNpbmdsZSB1c2UgY2FzZeKApikNCj4+DQo+PiBh LkkgdGhpbmsgd2UgbmVlZCB0byBnZXQgdG8gcHJvZHVjdHMgZmlyc3QsIGJlZm9yZSBhY2FkZW1p YyB2aXNpb25zDQo+Pg0KPj4gTXkgdHdvIGNlbnRzLi4NCj4+DQo+PiBCZXN0IFJlZ2FyZHMsDQo+ Pg0KPj4gSsOpcsO0bWUNCj4+DQo+PiAqRnJvbToqaXRzIFttYWlsdG86aXRzLWJvdW5jZXNAaWV0 Zi5vcmcgPG1haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZz5dDQo+PiAqT24gQmVoYWxmIE9mICpB bGV4YW5kcmUgUGV0cmVzY3UNCj4+ICpTZW50OiogV2VkbmVzZGF5IDA2IEFwcmlsIDIwMTYgMjM6 NDUNCj4+ICpUbzoqIGl0c0BpZXRmLm9yZyA8bWFpbHRvOml0c0BpZXRmLm9yZz4NCj4+ICpTdWJq ZWN0OiogW2l0c10gY2hhcnRlciBJVFMNCj4+DQo+PiBJVFNlcnMsDQo+Pg0KPj4gUGxlYXNlIHNl ZSBiZWxvdyB0aGUgY3VycmVudCBjaGFydGVyLg0KPj4NCj4+IC0gdGhlIHR3byBQcm9ibGVtIFN0 YXRlbWVudHMgZHJhZnRzIFYyViBhbmQgVjJJIGpvaW5lZCwgc28gdGhlcmUgaXMNCj4+IGxlc3Mg dGV4dCBpbiBjaGFydGVyLg0KPj4gLSBhZGRlZCBhbiBJdGVtIG9uICJMaXN0IG9mIFJlc2VhcmNo IHBhcGVycy4uLiINCj4+DQo+PiBFcmlrOiBkaWQgSSB1bmRlcnN0YW5kIHlvdSBjb3JyZWN0bHkg dGhhdCB0aGVyZSBzaG91bGQgYmUgc29tZSBpdGVtIG9uDQo+PiBkaXNjdXNzaW5nIHdoZXRoZXIg bGluay1sb2NhbCBhZGRyZXNzaW5nIGlzIHN1ZmZpY2llbnQsIHdoZXRoZXIgcHJlZml4DQo+PiBl eGNoYW5nZSBpcyBuZWNlc3Nhcnk/DQo+Pg0KPj4gRGlubzogc2hvdWxkIExJU1AgYmUgaW5jbHVk ZWQgaW4gdGhlIGdhcCBhbmFseXNpcyBkcmFmdCB3aGljaCBpbmNsdWRlcw0KPj4gQy1BQ0MgdXNl LWNhc2U/ICBPUiBzaG91bGQgd2Ugc2VwYXJhdGUgYSBkZWRpY2F0ZWQgSS1EIG9ubHkgd2l0aCBn YXANCj4+IGFuYWx5c2lzIGluY2x1ZGluZyBORCwgTUlQLCBBT0RWdjIsIExJU1A/DQo+Pg0KPj4g UGVyc29uIGZyb20gbWVkaWF0ZWs6IGlzIHRoZSAnemVyb2NvbmYnIG5lZWQgaW4gdGhlIHZlaGlj bGUtdG8tdmVoaWNsZQ0KPj4gaW50ZXJmYWNlIGlsbHVzdHJhdGVkIGdvb2QgZW5vdWdoIGJ5IHRo ZSB3b3JkcyAibW92aW5nIG5ldHdvcmsgdG8NCj4+IG5lYXJieSBtb3ZpbmcgbmV0d29yayBjb21t dW5pY2F0aW9ucyI/ICBPciBpcyBpdCBiZXR0ZXIgdG8gc2F5ICJ0aGUNCj4+IDEtSVAtaG9wIGJl dHdlZW4gbmVhcmJ5IG1vdmluZyBuZXR3b3JrcyBtdXN0IGJlIHNlbGYtY29uZmlndXJlZCI/DQo+ Pg0KPj4gTmFiaWwsIFNhbmRyYTogaXMgaXQgb2sgdG8gaGF2ZSBhIHdvcmtpbmcgZ3JvdXAgaXRl bSAiTGlzdCBvZiBSZXNlYXJjaA0KPj4gUGFwZXJzIGZvciBJUCBpbiBWMlYgYW5kIFYySSBjb21t dW5pY2F0aW9ucyI/DQo+Pg0KPj4gT3RoZXIgY29tbWVudHM/DQo+Pg0KPj4gQWxleA0KPj4NCj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4NCj4+ICAgICAgICAgICAgICAgSVRTIChuYW1lIHRvIGNoYW5nZSkNCj4+ ICAgICAgICAgICAgICAgICAgICAgQ2hhcnRlcg0KPj4gICAgICAgICAgICAgICBBcHJpbCA2dGgs IDIwMTYNCj4+IGh0dHA6Ly9pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPj4NCj4+DQo+ PiBJbnRlbGxpZ2VudCBUcmFuc3BvcnRhdGlvbiBTeXN0ZW1zIChpdHMpDQo+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBDdXJyZW50IFN0YXR1czogV0cgZm9y bWluZw0KPj4NCj4+IENoYWlyczoNCj4+ICAgICBUQkQNCj4+DQo+PiBBc3NpZ25lZCBBcmVhIERp cmVjdG9yOg0KPj4gICAgIFRCRA0KPj4NCj4+IE1haWxpbmcgbGlzdA0KPj4gICAgIEFkZHJlc3M6 IGl0c0BpZXRmLm9yZyA8bWFpbHRvOml0c0BpZXRmLm9yZz4NCj4+ICAgICBUbyBTdWJzY3JpYmU6 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+PiAgICAgQXJjaGl2 ZToNCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pdHMvY3VycmVudC9t YWlsbGlzdC5odG1sDQo+Pg0KPj4gQWRkaXRpb25hbCB3ZWIgcGFnZQ0KPj4gICAgIFRCRA0KPj4N Cj4+IENoYXJ0ZXI6DQo+Pg0KPj4gR29hbA0KPj4gLS0tLQ0KPj4gVGhlIGdvYWwgb2YgdGhpcyBn cm91cCBpcyB0byBzdGFuZGFyZGl6ZSBJUC1iYXNlZCBwcm90b2NvbHMgZm9yDQo+PiBlc3RhYmxp c2hpbmcgZGlyZWN0IGFuZCBzZWN1cmUgY29ubmVjdGl2aXR5IGJldHdlZW4gbW92aW5nIG5ldHdv cmtzLA0KPj4gc29tZSBvZiB3aGljaCBjb3VsZCBiZSBmaXhlZCBwZXJtYW5lbnRseSBvciB0ZW1w b3JhcmlseS4NCj4+DQo+PiBNb3ZpbmcgTmV0d29yayB0byBOZWFyYnkgTW92aW5nIE5ldHdvcmsg Q29tbXVuaWNhdGlvbnMNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPj4gVGhlIGdyb3VwIGlzIGNvbmNlcm5lZCB3aXRoIGFsbCBzaXR1 YXRpb25zIGludm9sdmluZyBtb3ZpbmcgbmV0d29yayB0bw0KPj4gbmVhcmJ5IG1vdmluZyBuZXR3 b3JrIGNvbW11bmljYXRpb25zLiAgRm9yIGV4YW1wbGU6IHZlaGljbGUtdG8tdmVoaWNsZQ0KPj4g Y29tbXVuaWNhdGlvbnMsIG5vbWFkaWMgdXNlciB3ZWFyaW5nIGEgUEFOIGFuZCBjb21tdW5pY2F0 aW5nIHRvIGENCj4+IGhvbWVuZXQsIHZlaGljbGUtdG8taW5mcmFzdHJ1Y3R1cmUgY29tbXVuaWNh dGlvbnMsIHdhZ29uLXRvLXdhZ29uIGluIGENCj4+IHRyYWluLCBvciB0cmFpbi10by1pbnRlcnNl Y3Rpb24gc2lnbmFsbGluZy4NCj4+DQo+PiBFeGFtcGxlIGZyb20gdGhlIGF1dG9tb2JpbGUgY29t bXVuaWNhdGlvbnMgc3BhY2UNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPj4gQXV0b21vYmlsZXMgYW5kIHZlaGljbGVzIG9mIGFsbCB0eXBlcyBh cmUgaW5jcmVhc2luZ2x5IGNvbm5lY3RlZCB0bw0KPj4gdGhlIEludGVybmV0LCBlaXRoZXIgYXMg dmVoaWNsZS10by12ZWhpY2xlLCB2ZWhpY2xlLXRvLWluZnJhIG9yDQo+PiB2ZWhpY2xlLXRvLUlu dGVybmV0LiAgRW50ZXJ0YWlubWVudCBhcHBzIGVuaGFuY2luZyBjb21mb3J0LCByZWxpYWJsZQ0K Pj4gZGF0YSBleGNoYW5nZXMgZm9yIHJvYWQgc2FmZXR5LCBhbmQgYXV0b21hdGVkIGRyaXZpbmcg YXJlIGZlYXR1cmVzDQo+PiBjb21pbmcgaW4gYXV0b21vYmlsZXMgdG8gaGl0IHRoZSByb2FkcyBm cm9tIG5vdyB0byB5ZWFyIDIwMjAuDQo+PiBIaWdobGlnaHRpbmcgaW5jcmVhc2VkIHNhZmV0eSBh cyBhbiBpbW1lZGlhdGUgcmVzdWx0IG9mDQo+PiBoeXBlci1jb25uZWN0aXZpdHkgYXBwbGllZCB0 byB2ZWhpY2xlcywgcHVibGljIGF1dGhvcml0aWVzIHdvcmxkd2lkZQ0KPj4gYXJlIGluY3JlYXNp bmdseSBtYW5kYXRpbmcgc2VjdXJlIGNvbW11bmljYXRpb24gdGVjaG5vbG9neQ0KPj4gcmVxdWly ZW1lbnRzIGluIHZlaGljbGVzLg0KPj4NCj4+IEVtZXJnZW5jeSBhcHBzIGZvciBuZXcgaW5zdHJ1 bWVudGVkIGFtYnVsYW5jZXMgY2FycnkgbWFueSBiZW5lZml0cw0KPj4gYm90aCB0byB0aGUgdXNl cnMgYW5kIHRvIHNvY2lldHkgaW4gZ2VuZXJhbC4NCj4+DQo+PiBXaHkgSVA/DQo+PiAtLS0tLS0t DQo+PiBUb2RheSwgdGhlcmUgYXJlIHNldmVyYWwgZGVwbG95ZWQgVmVoaWNsZS10by1JbnRlcm5l dCB0ZWNobm9sb2dpZXMsDQo+PiBpbmNsdWRpbmcgY2FyIHRldGhlcmluZyB0aHJvdWdoIGRyaXZl cidzIGNlbGx1bGFyIHNtYXJ0cGhvbmUuDQo+PiBIb3dldmVyLCBWZWhpY2xlLXRvLVZlaGljbGUg YW5kIFZlaGljbGUtdG8tSW5mcmFzdHJ1Y3R1cmUNCj4+IGNvbW11bmljYXRpb25zIGFyZSBzdGls bCBiZWluZyBkZXZlbG9wZWQuICBUbyBpbXByb3ZlIG9uIGEgc2l0dWF0aW9uDQo+PiBvZiBsaW5r LXNwZWNpZmljIGRhdGEgZXhjaGFuZ2VzLCBhbmQgZW5hYmxlIGluZGVwZW5kZW50IGFwcGxpY2F0 aW9uDQo+PiBzZXRzIHRvIHNoYXJlIHRoZSBzYW1lIGxpbmtzLCBJUCBkYXRhIGV4Y2hhbmdlcyBh cmUgbmVlZGVkLiAgRW5hYmxpbmcNCj4+IElQIGNvbW11bmljYXRpb24gYmV0d2VlbiB2ZWhpY2xl cyAoVjJWKSwgYW5kIGJldHdlZW4gdmVoaWNsZXMgYW5kIHRoZQ0KPj4gaW1tZWRpYXRlIGluZnJh c3RydWN0dXJlIChWMkkpLCB3aWxsIHByb3ZpZGUgKDApIGFiaWxpdHkgdG8gcmVhY2ggdGhlDQo+ PiByZXN0IG9mIHRoZSB3b3JsZCBvbiB0aGUgSW50ZXJuZXQgKDEpIHNob3J0IGFuZCBkZXRlcm1p bmlzdGljIGRlbGF5cywNCj4+ICgyKSBmYXN0IGZvcndhcmRpbmcgdGhyb3VnaCBzY2FsYWJsZSBw YXRocyBvZiByb3V0ZXJzLCAoMykgZWFzZSBvZg0KPj4gcmV1c2Ugb2YgZXhpc3RpbmcgSW50ZXJu ZXQgYXBwbGljYXRpb25zIGluIGEgdmVoaWN1bGFyIGVudmlyb25tZW50Lg0KPj4NCj4+IE1vdmlu ZyBuZXR3b3JrIHRvIG5lYXJieSBtb3ZpbmcgbmV0d29yayBjb21tdW5pY2F0aW9ucyBpbnZvbHZl IGxpbmsNCj4+IGxheWVycyBzdWNoIGFzOiA4MDIuMTFwIE9DQiAoT3V0c2lkZSB0aGUgQ29udGV4 dCBvZiBhIEJhc2ljIFNlcnZpY2UNCj4+IFNldCksIDgwMi4xNS40IHdpdGggNmxvd3BhbiwgODAy LjExYWMsIFZMQyAoVmlzaWJsZSBMaWdodA0KPj4gQ29tbXVuaWNhdGlvbnMpLCBJckRBLCBMVEUt RC4gIE9ubHkgdGhlIElQIHByb3RvY29scyBhcmUgY2FwYWJsZSBvZg0KPj4gcnVubmluZyBvbiBl YWNoIG9mIHRoZXNlIGxpbmtzIGFuZCBlc3RhYmxpc2ggSVAgcGF0aHMgYWNyb3NzIHRoZW0gaW4N Cj4+IGFuIGludGVyb3BlcmFibGUgbWFubmVyLg0KPj4NCj4+IFNjZW5hcmlvcz8NCj4+IC0tLS0t LS0tLS0NCj4+IFRoZXJlIGFyZSBhIGZldyBzY2VuYXJpb3MgZXhoaWJpdGluZyB0aGUgbmVlZCB0 byBjb21tdW5pY2F0ZSBmcm9tIG9uZQ0KPj4gbW92aW5nIG5ldHdvcmsgdG8gYW5vdGhlciBuZWFy YnkgbW92aW5nIG5ldHdvcmsuDQo+Pg0KPj4gSW4gdGhlIGF1dG9tb2JpbGUgc3BhY2UsIHRoZSBD b29wZXJhdGl2ZSBBZGFwdGl2ZSBDcnVpc2UgQ29udHJvbCBhbmQNCj4+IFBsYXRvb25pbmcgZmVh dHVyZXMgY29uc2lkZXIgdGhhdCB2ZWhpY2xlcyBjbG9zZSB0byBlYWNoIG90aGVyDQo+PiBleGNo YW5nZSBkYXRhIGRlc2NyaWJpbmcgdGhlaXIga2luZW1hdGljIHN0YXR1cy4gIEF0IHRoZSBjcm9z cy1yb2FkcywNCj4+IHRoZSBtb3ZpbmcgbmV0d29yayBpbnNpZGUgYSB2ZWhpY2xlIGV4Y2hhbmdl cyBkYXRhIHdpdGggdGhlIG1vdmluZw0KPj4gbmV0d29yayBpbiB0aGUgcmVkLWxpZ2h0IHBvbGUu DQo+Pg0KPj4gU2V2ZXJhbCBwdWJsaWMgc2FmZXR5IHNjZW5hcmlvcyBpbnZvbHZlIG1vdmluZyBu ZXR3b3Jrcy4gIERpc3RpbmN0DQo+PiBvcmdhbml6YXRpb25zIGRlcGxveSBkaWZmZXJlbnQgbW92 aW5nIG5ldHdvcmtzIChpbi12ZWhpY2xlLCBvbi1wZXJzb24pDQo+PiBhdCBhbiBpbmNpZGVudCBz Y2VuZS4gIFRoZXNlIG5ldHdvcmtzIG5lZWQgdG8gaW50ZXJvcGVyYXRlIGluIG9yZGVyIHRvDQo+ PiBtb3JlIGVmZmVjdGl2ZWx5IHVuZGVyc3RhbmQgYW5kIGRlYWwgd2l0aCB0aGUgaW5jaWRlbnQg c2NlbmUuDQo+Pg0KPj4gSW4gY29ubmVjdGVkIHJhaWwgc2NlbmFyaW9zIHRoZSBtb3ZpbmcgbmV0 d29yayBkZXBsb3llZCBpbiB0cmFpbnMNCj4+IGNvbW11bmljYXRlIHdpdGggb3RoZXIgbW92aW5n IG5ldHdvcmtzIGF0IHRoZSBjcm9zcy1wb2ludHMuDQo+Pg0KPj4gV2hhdCBraW5kIG9mIHNvbHV0 aW9ucz8NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBUaGUgY3VycmVudCB0ZWNobmlj YWwgc29sdXRpb25zIGNvbnNpZGVyZWQgdG8gYWNoaWV2ZSBtb3ZpbmcgbmV0d29yaw0KPj4gdG8g bmVhcmJ5IG1vdmluZyBuZXR3b3JrIGNvbW11bmljYXRpb25zIGFyZSBvZiB0d28ga2luZHM6IElQ IHJvdXRpbmcNCj4+IHByb3RvY29scyBmb3Igbi1ob3AgcGF0aCBtYW5hZ2VtZW50IGFuZCAxLWhv cCBsaW5rLXNjb3BlZCBJUCBwcm90b2NvbA0KPj4gZW5oYW5jZW1lbnRzLiAgVGhlIDEtaG9wIGxp bmstc2NvcGVkIHByb3RvY29scyBpbmNsdWRlIHRoZSBwcm90b2NvbHMNCj4+IGZvciByb3V0ZSBl c3RhYmxpc2htZW50IGludm9sdmluZyBJQ01QIFJvdXRlciBBZHZlcnRpc2VtZW50cy4gIFRoZQ0K Pj4gbi1ob3AgcGF0aCBtYW5hZ2VtZW50IHByb3RvY29scyBpbmNsdWRlIG4taG9wIHBhdGggZXN0 YWJsaXNobWVudA0KPj4gcHJvdG9jb2xzIChlLmcuIEJhYmVsLCBPU1BGKSBhbmQgbi1ob3AgcGF0 aCBzZWFyY2ggcHJvdG9jb2xzIChtb3N0DQo+PiBub3RhYmx5IEFPRFYgYW5kIGRlcml2YXRlcyku DQo+Pg0KPj4gSW4gdGhpcyBwcm9wb3NlZCBXb3JraW5nIEdyb3VwIHRoZSBmb2N1cyBpcyBvbiAx LWhvcCBwcm90b2NvbHMsIGFuZA0KPj4gbGV2ZXJhZ2UgZnJvbSBvdGhlciBXb3JraW5nIEdyb3Vw cyBmb3IgdGhlIG4taG9wIHNpdHVhdGlvbnMuDQo+Pg0KPj4gSW4gc29tZSBvZiB0aGUgbW92aW5n IG5ldHdvcmsgYXBwbGljYXRpb25zIHRoZSB3aW5kb3cgb2Ygb3Bwb3J0dW5pdHkNCj4+IGZvciBl eGNoYW5naW5nIGRhdGEgd2l0aCB0aGUgaW1tZWRpYXRlIGluZnJhc3RydWN0dXJlIG1heSBiZSB2 ZXJ5DQo+PiBzaG9ydC4gIEZvciBleGFtcGxlLCBhIGNhciBkcml2aW5nIG5lYXIgYSByb2FkLXNp ZGUgdW5pdCBtYXkgaGF2ZSBvbmx5DQo+PiA1cyB0byBleGNoYW5nZSB3aXRoIHRoYXQgUlNVIChk ZXBlbmRpbmcgb24gc3BlZWQsIFJTVSByYW5nZSBhbmQNCj4+IG51bWJlcikuIChlcGhlbWVyYWwg Y29ubmVjdGlvbnMpLg0KPj4NCj4+IFdoYXQga2luZCBvZiByZXF1aXJlbWVudHM/DQo+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gVGhlIHJlcXVpcmVtZW50cyBmb3IgbWVjaGFuaXNt cyBmb3IgbW92aW5nIG5ldHdvcmsgdG8gbmVhcmJ5IG1vdmluZw0KPj4gbmV0d29yayBjb21tdW5p Y2F0aW9ucyBhcmUgZm9jdXNpbmcgb24gbG93IGRlbGF5cyBvZiB0aGUgZGF0YSBwYXRocywNCj4+ IHJlZHVjZWQgbnVtYmVyIG9mIG1lc3NhZ2VzIGZvciBwYXRoIGVzdGFibGlzaG1lbnQsIGFwcGxp Y2F0aW9uDQo+PiBmcmllbmRseSwgcmVzaWxpZW5jZSB0byBhdHRhY2tzLCBjb21wYXRpYmlsaXR5 IHdpdGggREhDUCBhbmQgTW9iaWxlDQo+PiBJUC4NCj4+DQo+PiBJbiBhZGRpdGlvbiwgc29tZSBt b3ZpbmcgbmV0d29yayB0byBuZWFyYnkgbW92aW5nIG5ldHdvcmsgYXBwbGljYXRpb25zDQo+PiBp bnZvbHZlIElQIG11bHRpY2FzdCBtZWNoYW5pc21zIChlLmcuIHZpcnR1YWwgc2lyZW4pOyB0aHVz IEMtQUNDIHRoZQ0KPj4gMS1ob3AgSVAgbW92aW5nIG5ldHdvcmsgdG8gbmVhcmJ5IG1vdmluZyBu ZXRvd3JrIG1lY2hhbmlzbXMgd2lsbCBuZWVkDQo+PiB0byBncmFjZWZ1bGx5IHN1cHBvcnQgSVAg bXVsdGljYXN0Lg0KPj4NCj4+IER1ZSB0byB0aGUgaW5oZXJlbnQgY2hhcmFjdGVyaXN0aWNzIG9m IHNhZmV0eS1yZWxhdGVkIGNvbW11bmljYXRpb25zLA0KPj4gYWxsIG5ldyBtb3ZpbmcgbmV0d29y ayB0byBuZWFyYnkgbW92aW5nIG5ldHdvcmsgbWVjaGFuaXNtcyBtdXN0IGFmZm9yZA0KPj4gYXV0 aGVudGljaXR5IGFuZCBjb25maWRlbnRpYWxpdHkgd2hlcmUgbmVjZXNzYXJ5LiAgRHluYW1pY2Fs bHkNCj4+IGVzdGFibGlzaGluZyBlcGhlbWVyYWwgY29tbXVuaWNhdGlvbiBwYXRocyBiZXR3ZWVu IGF1dG9tb2JpbGVzIGluDQo+PiBwdWJsaWMgYXJlYXMgbXVzdCBvZmZlciBwcml2YWN5IHNhZmVn dWFyZHMgZm9yIHRoZSBlbmQgdXNlcnMNCj4+IChwYXNzZW5nZXJzKS4NCj4+DQo+PiBFc3RhYmxp c2hpbmcgMS1ob3AgSVAgVjJWIHBhdGhzIG11c3Qgbm90IGJyZWFrIHRoZSBleGlzdGluZyBvbi1i b2FyZA0KPj4gcHJvdG9jb2xzIGFuZCBhcHBsaWNhdGlvbnMgd2hpY2ggY29tbXVuaWNhdGUgd2l0 aCB0aGUgSW50ZXJuZXQsDQo+PiBwb3NzaWJseSB2aWEgbXVsdGlwbGUgcmFkaW9zLg0KPj4NCj4+ IEluIGEgbW92aW5nIG5ldHdvcmsgZGVwbG95ZWQgaW4gYW4gYXV0b21vYmlsZSwgdHlwaWNhbGx5 IG9uZSBleGl0DQo+PiBwb2ludCBjb25uZWN0cyB0aGUgbW92aW5nIG5ldHdvcmsgdG8gb3RoZXIg bW92aW5nIG5ldHdvcmtzLiAgSG93ZXZlciwNCj4+IGluIGEgbW9yZSBnZW5lcmFsIG1hbm5lciAo YW5kIHRvIHN1cHBvcnQgcmVsaWFiaWxpdHkpIGFueSBuZXcNCj4+IG1lY2hhbmlzbSBvZiBtb3Zp bmcgbmV0d29yayB0byBuZWFyYnkgbW92aW5nIG5ldHdvcmsgY29tbXVuaWNhdGlvbnMNCj4+IHNo b3VsZCBzdXBwb3J0IG11bHRpLWhvbWluZzogb25lIHJvdXRlciB0byB1c2UgbXVsdGlwbGUgaW50 ZXJmYWNlcw0KPj4gdG93YXJkcyBvdXRzaWRlIHRoZSBtb3ZpbmcgbmV0d29yaywgb3IgbXVsdGlw bGUgcm91dGVycy4NCj4+DQo+PiBDdXJyZW50IHZlcnNpb24gb2YgSW50ZXJuZXQgcHJvdG9jb2xz DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBUaGUgZ3JvdXAg d2lsbCBvbmx5IHdvcmsgb24gSVB2NiBzb2x1dGlvbnMuDQo+Pg0KPj4gV2hhdCBTRE9zIG1heSBu ZWVkIHRoaXMgd29yaz8NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBUaGUg cmVxdWlyZW1lbnRzIGFuZCBzdGFuZGFyZHMgZm9yIG1vdmluZyBuZXR3b3JrIHRvIG5lYXJieSBt b3ZpbmcNCj4+IG5ldHdvcmsgY29tbXVuaWNhdGlvbnMsIG9mdGVuIGludm9sdmluZyBJUHY2LCBh bmQgbm92ZWwgVjJWIGFuZA0KPj4gVjJJbmZyYSBjb25jZXB0cywgYXJlIGRldmVsb3BlZCBtYWlu bHkgYXQgSVNPIFRDMjA0ICJJbnRlbGxpZ2VudA0KPj4gVHJhbnNwb3J0IFN5c3RlbXMiLCAzR1BQ LCBFVFNJLCBOSFRTQSBhbmQgSUVFRS4gIEZvcg0KPj4gVmVoaWNsZS10by1JbnRlcm5ldCBjb21t dW5pY2F0aW9ucywgM0dQUCBMVEUgYW5kIG90aGVyIGNlbGx1bGFyDQo+PiB0ZWNobm9sb2dpZXMg cmVwcmVzZW50IHRoZSBsb25nLXJhbmdlIGNvbm5lY3Rpdml0eSBtZXRob2Q7IGZvcg0KPj4gVmVo aWNsZS10by1WZWhpY2xlIGNvbW11bmljYXRpb25zLCBMVEUgRGlyZWN0IGlzIGN1cnJlbnRseSBz cGVjaWZpZWQsDQo+PiBhcyB3ZWxsIGFzIE9DQiBtb2RlIG9mIElFRUUgODAyLjExLiAgU2V2ZXJh bCB1c2UtY2FzZXMgZXhoaWJpdCBhIG5lZWQNCj4+IGZvciBJUHY2IGRhdGEgZXhjaGFuZ2VzIGJl dHdlZW4gdmVoaWNsZXM6IEVUU0kncyBDb29wZXJhdGl2ZSBBZGFwdGl2ZQ0KPj4gQ3J1aXNlIENv bnRyb2wgYW5kIFBsYXRvb25pbmcuICBUaGUgSUVFRSBkZXZlbG9wZWQgYSBwb3B1bGFyIGxpbmsg Zm9yDQo+PiBzaG9ydC1yYW5nZSBjb21tdW5pY2F0aW9ucyAtIElFRUUgODAyLjExcCAiV0FWRSIu ICBUaGUgTkhUU0Egd3JvdGUgYQ0KPj4gc2V0IG9mIHJlcXVpcmVtZW50cyBmb3IgVjJWIGNvbW11 bmljYXRpb25zLg0KPj4NCj4+IFdvcmsgSXRlbXMNCj4+IC0tLS0tLS0tLS0NCj4+IC0gdXNlLWNh c2VzIGZvciBtb3ZpbmcgbmV0d29yayB0byBuZWFyYnkgbW92aW5nIG5ldHdvcmsgY29tbXVuaWNh dGlvbnMNCj4+IC0gUHJvYmxlbSBTdGF0ZW1lbnQgZm9yIG1vdmluZyBuZXR3b3JrIHRvIG5lYXJi eSBtb3ZpbmcgbmV0d29yaw0KPj4gY29tbXVuaWNhdGlvbnMNCj4+ICAgIGluY2x1ZGluZyBWMlYs IFYySSBhbmQgRE5TLg0KPj4gLSBTZWN1cml0eSBhbmQgUHJpdmFjeSBSZXF1aXJlbWVudHMgZm9y IG1vdmluZyBuZXR3b3JrIHRvDQo+PiAgICBuZWFyYnkgbW92aW5nIG5ldHdvcmsgY29tbXVuaWNh dGlvbnMNCj4+IC0gU29sdXRpb25zLCB3aGljaCBtaWdodCBpbmNsdWRlIG5ldyBwcm90b2NvbHMg b3IgZXh0ZW5zaW9ucyB0bw0KPj4gICAgZXhpc3RpbmcgcHJvdG9jb2xzLiAgV2l0aCBNSUIuDQo+ PiAtIElQdjYtb3ZlciBmb28sIHdoZXJlIGZvbyBpcyBwZXJ0aW5lbnQgZm9yIG1vdmluZyBuZXR3 b3JrIHRvIG5lYXJieQ0KPj4gICAgbW92aW5nIG5ldHdvcmsgY29tbXVuaWNhdGlvbnMgKGUuZy4g ODAyLjExIE9DQiwgVkxDLCBMVEUtRCwNCj4+IDgwMi4xMWFkKQ0KPj4gLSBMaXN0IG9mIFJlc2Vh cmNoIFBhcGVycyBpbiB0aGUgVjJWIGRvbWFpbiwgaWRlbnRpZnlpbmcgd2hpY2ggdXNlcyBJUC4N Cj4+DQo+PiBUaW1lbGluZQ0KPj4gLS0tLS0tLS0NCj4+IC0NCj4+DQo+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGl0cyBtYWlsaW5nIGxp c3QNCj4+IGl0c0BpZXRmLm9yZyA8bWFpbHRvOml0c0BpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pg0KPj4NCj4+DQo+PiAtLQ0KPj4NCj4+ ID09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4gTXIuIEphZWhvb24gKFBhdWwpIEplb25n LCBQaC5ELg0KPj4gQXNzaXN0YW50IFByb2Zlc3Nvcg0KPj4gRGVwYXJ0bWVudCBvZiBTb2Z0d2Fy ZQ0KPj4gU3VuZ2t5dW5rd2FuIFVuaXZlcnNpdHkNCj4+IE9mZmljZTogKzgyLTMxLTI5OS00OTU3 DQo+PiBFbWFpbDogamFlaG9vbi5wYXVsQGdtYWlsLmNvbSA8bWFpbHRvOmphZWhvb24ucGF1bEBn bWFpbC5jb20+LA0KPj4gcGF1bGplb25nQHNra3UuZWR1IDxtYWlsdG86cGF1bGplb25nQHNra3Uu ZWR1PiBQZXJzb25hbCBIb21lcGFnZToNCj4+IGh0dHA6Ly9pb3RsYWIuc2trdS5lZHUvcGVvcGxl LWphZWhvb24tamVvbmcucGhwDQo+PiA8aHR0cDovL2Nwc2xhYi5za2t1LmVkdS9wZW9wbGUtamFl aG9vbi1qZW9uZy5waHA+DQo+Pg0KPj4NCj4+DQo+PiAtLQ0KPj4NCj4+ID09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KPj4gTXIuIEphZWhvb24gKFBhdWwpIEplb25nLCBQaC5ELg0KPj4gQXNz aXN0YW50IFByb2Zlc3Nvcg0KPj4gRGVwYXJ0bWVudCBvZiBTb2Z0d2FyZQ0KPj4gU3VuZ2t5dW5r d2FuIFVuaXZlcnNpdHkNCj4+IE9mZmljZTogKzgyLTMxLTI5OS00OTU3DQo+PiBFbWFpbDogamFl aG9vbi5wYXVsQGdtYWlsLmNvbSA8bWFpbHRvOmphZWhvb24ucGF1bEBnbWFpbC5jb20+LA0KPj4g cGF1bGplb25nQHNra3UuZWR1IDxtYWlsdG86cGF1bGplb25nQHNra3UuZWR1PiBQZXJzb25hbCBI b21lcGFnZToNCj4+IGh0dHA6Ly9pb3RsYWIuc2trdS5lZHUvcGVvcGxlLWphZWhvb24tamVvbmcu cGhwDQo+PiA8aHR0cDovL2Nwc2xhYi5za2t1LmVkdS9wZW9wbGUtamFlaG9vbi1qZW9uZy5waHA+ DQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+aXRzIG1haWxpbmcgbGlzdA0KPml0c0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXRzDQo= From nobody Sat Apr 16 08:06:04 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DF512E1A2 for ; Sat, 16 Apr 2016 08:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTyCV9_bAoVE for ; Sat, 16 Apr 2016 08:06:01 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF3012DC17 for ; Sat, 16 Apr 2016 08:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1455; q=dns/txt; s=iport; t=1460819161; x=1462028761; h=from:to:subject:date:message-id:mime-version; bh=MYhCLM7fTlZcXnHYHNysaFkyZ71+Kg9jgwv2Axqa4jw=; b=OBKmDIBvzEHn4aBiKtBPZby7917FrC5xEWPou/e/UVi13+AXiiViofyI P3C7oPVh5+eG+ri2tNsD4mIzCfbyfdbqeJBiDAhUVUT87ZfzBs8SXyVRb GZn2AvNP0fyF/jliZOdHknAQ86Lbdxu3RFDjv+j0fufkNcEyom4pHCEYS A=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAgD6UxJX/4gNJK1cgzhTgQO4CIIPD?= =?us-ascii?q?oFxIocTOBQBAQEBAQEBZRwLhEgjaAFKAjQnBCGIGw6bZI9dkWMBAQEBAQEEAQE?= =?us-ascii?q?BAQEBAQEBAQ4EBIYhgXWKFSuCKwWTHoRwAYEtgXeBZm2IFoFRAY0/jyoBHgFDg?= =?us-ascii?q?2iJOX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,492,1454976000"; d="asc'?scan'208";a="261584876" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Apr 2016 15:06:01 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3GF607P024398 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 16 Apr 2016 15:06:00 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 16 Apr 2016 11:06:00 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Sat, 16 Apr 2016 11:05:59 -0400 From: "Carlos Pignataro (cpignata)" To: "its@ietf.org" Thread-Topic: Liaison statement: Liaison from ISO/TC204 to IETF Thread-Index: AQHRl/F83pFhiLGCYkmwx4RkWxUsSA== Date: Sat, 16 Apr 2016 15:05:59 +0000 Message-ID: <6CE69D10-658F-4E46-ACCB-4ED46BA5577E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.252.57] Content-Type: multipart/signed; boundary="Apple-Mail=_8234E204-F5F0-4E8A-ACD4-0F2C2AAF0F20"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: [its] Liaison statement: Liaison from ISO/TC204 to IETF X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 15:06:03 -0000 --Apple-Mail=_8234E204-F5F0-4E8A-ACD4-0F2C2AAF0F20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 ITS, FYI: Liaison from ISO/TC204 to IETF https://datatracker.ietf.org/liaison/1468/ Thanks! =E2=80=94 Carlos. --Apple-Mail=_8234E204-F5F0-4E8A-ACD4-0F2C2AAF0F20 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXElTWAAoJEIXgpQGOZny91pEP/iFXR0dsG8drch+NVHrLenT/ 3hJ6U3b5mqLQLqSWRbifGpllHsvwh/hh5EKz4obY0u2gp4+D9YH33dOGHma/X4Dy 2zfJgZ+Wm/kKixf8sNFPa9kxaaz9RTaIQHDoug1oK2DGGgxC6dH02t5iNfcD8CM3 yJPFWEjgVhBe5+kDQklzyw2z5+3zzNJVREGs6y/z5VEd9tpb6shIgm7Ffpmpp5TI CT9HFqPNEPWn5Ng3jiHye2u8IInpTOujhWWvYW/6gz3UTltJ2+Ce7oJ0ct22YrLp 5qztPsuKcg2nILXEkdcxKYa72dLTIzbjlACFo95sA5cX0+yVEEfsGpEamCA09R47 f4/ktfSPXFAl4G2fZgRCHQWCIkbyWPbHNcu5ZuOP0GknXpW2x+kLT/DOOwDsAp2A xwvIF8vjBi8y+etVkYUCb+n4a/PMQUjnQI8o+vjGR3GxxPKARspUXCosBGPOeJDY OPpYxuiztGwhyR6XTUYd8XaB5KUeoR44IljQTATiAge5BIuANsPFKyNyY6OyEAJA 3ZcdHej8aFqI0YVlrNY+tFYXcT1jg3p3+XDNbItdMIpvEFPUyi4BwdaefEhsAXQj dZSzSZusII0O2YuwsqNAPjNUANykdHOEK/VdemyQIyYhrqeYk12pbCnBkj85B3Wa gCn6KGbfuk0Co44ocTKc =0U93 -----END PGP SIGNATURE----- --Apple-Mail=_8234E204-F5F0-4E8A-ACD4-0F2C2AAF0F20-- From nobody Sun Apr 17 05:07:50 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFC712DD47 for ; Sun, 17 Apr 2016 05:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFgBOxCJ_RzL for ; Sun, 17 Apr 2016 05:07:46 -0700 (PDT) Received: from mail-pa0-x241.google.com (mail-pa0-x241.google.com [IPv6:2607:f8b0:400e:c03::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93F312DD3D for ; Sun, 17 Apr 2016 05:07:45 -0700 (PDT) Received: by mail-pa0-x241.google.com with SMTP id zy2so13874061pac.2 for ; Sun, 17 Apr 2016 05:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ia5s/B7BSFhpJoUT0IazYlWBcosya7CH9G7YLpsb2vM=; b=W8/tSV4HdipzgmG5P9g1ES6bBhe42wkf7BRbabLoK/tyOLtOwbfaAr9L8PiT8WgY5P kzXDR+PqDc3gAwGJVvVs74OtI4OQgRNZvkEu0SRaMJjP5kmbCzc/iMWXtNAChUPSapnm bfEUFvGseGfe5UxojQBcY8ZL+VYBaEgNzKgFfGWBu5FyLENGjFAsUddcGNP3+lXY9ZPW ABbu3FBKutVAgJDJEm54F+mw8tiKmiFx5JviZuUUbqdNnGDigyLDBaWRKw7xlYd7Y6p6 JSgjokoBcs9dld3aSa8k82992b97qC0bj6SBbw1ffRVxUYzDcb6By/KI1+fYXGiCkoqe /63g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ia5s/B7BSFhpJoUT0IazYlWBcosya7CH9G7YLpsb2vM=; b=eF1J+BYt0JTzrOxgJanGMmbTZqgRosSf4vXRKVtnVChux44h5n2iIkmp3BvlWWee6A toHFjvklZE+7bi4sOD7h7yZpxYA+EwwFh4LiWIfR7CcFtEwGMK/6panJAf6GNN0hQKB1 mF26QG1OgU/zM+W/Rls8IIMbhyWi/ENN2r4NTSfz7sWae6GQHtlQSnfpr4fm8AcmlKAD tlRqyaDI2n0IGvyhHWXLNz6PQVyJhYBpCoNCyebMEcVD5mADdNY9FHb00xow0KOBlJji UoCTLxfBvFlXp2gWk2rhe2s1Vt9QqJQ9GL1lqQ5ILa+E5Cfa7BOn9ybyeoPA912IQHfB zK3A== X-Gm-Message-State: AOPr4FXNqcyLQSphrhVB5pyRvSrTZrORQ7AJ7mYLSPWyB8ELrllAheK5wBWhTUbLmc5plg== X-Received: by 10.66.194.196 with SMTP id hy4mr13067812pac.43.1460894865397; Sun, 17 Apr 2016 05:07:45 -0700 (PDT) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id r65sm76608736pfa.27.2016.04.17.05.07.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 17 Apr 2016 05:07:44 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Jong-Hyouk Lee In-Reply-To: <570F57EB.4060606@gmail.com> Date: Sun, 17 Apr 2016 21:07:40 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 12:07:49 -0000 Hi Alex Just to clarify. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 14, 2016, at 5:42 PM, Alexandre Petrescu = wrote: >=20 > ITSers, >=20 > We work on a more rigorous ITS charter text. >=20 > Now we propose four work items: >=20 > 1. "Problem statement for IP in V2V and V2I" > including "IP addressing architecture for V2V and V2I" > and including "Gap Analysis: IP protocols suited and gaps" > and including "Use-cases for IP in V2V and V2I moving network to > nearby moving or fixed network=E2=80=9D Are you intending to have one document that includes those three parts? >=20 > 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context=E2=80= =9D Is this mean that this group first go for this and later considers a = general security document (e.g., security requirements for ITS) ? Cheers. >=20 > 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], > including connectivity in fast and asymmetric conditions, coverage > area vs speed diagrams, below-IP congestion management. >=20 > 4. "List of papers and _products_ using IP in V2V and V2I" >=20 > What do you think? >=20 > Please respond by next Monday, April 18th. >=20 > Alex and Dapeng > [*] a typical IP-over-foo document is, for example, RFC2464 > "Transmission of IPv6 Packets over Ethernet Networks", where > "foo" is instantiated as "Ethernet". Other IPv6-over-foo documents > are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and more. >=20 > Le 14/04/2016 09:42, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : >> Paul, >>=20 >> Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of = IP V2V but not see >> the need (so far), I referred to the automotive SDOs (led by = automotive >> industries)=E2=80=A6, although there are always =E2=80=98minority = reports=E2=80=99 J >>=20 >> Cheers, >>=20 >> J=C3=A9r=C3=B4me >>=20 >> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] >> *Sent:* Thursday 14 April 2016 09:36 >> *To:* J=C3=A9r=C3=B4me H=C3=A4rri >> *Cc:* Alexandre Petrescu; its@ietf.org >> *Subject:* Re: [its] charter ITS >>=20 >> J=C3=A9r=C3=B4me, >>=20 >> I missed that you are also an academic person. >>=20 >> I got it :-) >>=20 >> I understand your points for industry activity related to vehicular >> networking. >>=20 >> Your observation seems true. >>=20 >> BTW, I will invite you to my team for the draft for a list of = academic >> papers for V2V and V2I >>=20 >> by a personal message. >>=20 >> Thanks. >>=20 >> Paul >>=20 >> On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri = > > wrote: >>=20 >> Hi Paul, >>=20 >> Thanks for your feedback. Do not get me wrong, I am an academic and = with >> my team, we also work on IP-based V2V and V2I, in particular related = to >> mobility management with DMM, but also in the context of vehicular = IoT. >>=20 >> I just have the feeling that people are perfectly aware of the fact = that >> IP _can_ be used for V2V and V2I, but does not =E2=80=98_need_=E2=80=99= to be used as >> other solutions already perfectly fit their need. Listing papers will >> not change this awareness. >>=20 >> So, as a complement to academic papers, it would help to be able to >> pin-point which industrial activities are using or are strongly = planning >> (short term I mean) to use pure IPv6 system in vehicles. >>=20 >> My feeling here is we have a different eco-system that the Automotive >> industry (and automotive industry-related SDO)..more likely the IoT >> industry=E2=80=A6and as such, we should not need to have the (direct) >> involvement of automotive industry in the Charter. If we can make = this >> clear by an industry-based =E2=80=98survey=E2=80=99, that would help = make the case for >> the WG. >>=20 >> Btw, you can count on me your draft..we can add some IP-based V2V and >> V2I for mobility management and also IoT. >>=20 >> Cheers, >>=20 >> J=C3=A9r=C3=B4me >>=20 >> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com >> ] >> *Sent:* Thursday 14 April 2016 03:22 >> *To:* J=C3=A9r=C3=B4me H=C3=A4rri >> *Cc:* Alexandre Petrescu; its@ietf.org >> *Subject:* Re: [its] charter ITS >>=20 >> Hi J=C3=A9r=C3=B4me, >>=20 >> I have an opinion on your comment 5) below. >>=20 >> I think that a list of high-quality papers about IP-based V2V and V2I >>=20 >> can teach very useful lessons to software designers of IP in V2V and = V2I >>=20 >> in the industry. >>=20 >> Multiple people are working for this IP-based V2V and V2I >>=20 >> (including Sandra Cespedes and me) in academia and >>=20 >> more people(including Nabil Benamar) are willing to work for this = area. >>=20 >> I think we need to utilize the list of such papers as the ground for = our >> ITS group >>=20 >> through a WI. Note that the draft of the list will include the = summary >> of the main >>=20 >> ideas of the papers. >>=20 >> For the industry current activities for this area, I believe that you >> can share them >>=20 >> as references through our ITS mailing list rather than through a WI. >>=20 >> Could you join my team that are making efforts for a list of such = papers? >>=20 >> Thanks. >>=20 >> Best Regards, >>=20 >> Paul >>=20 >> On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri = > > wrote: >>=20 >> Dear ITSers, Dear Alex, >>=20 >> Here are some comments on the updated charter: >>=20 >> 1)Can we keep a reference to IEEE 802.11p, considering it does not = exist >> anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mode >> (and 10Mhz @5.9Ghz) of course. >>=20 >> 2)Should we really keep C-ACC (or Platooning) in the charter = explicitly >> as use case, considering it is a seriously controversial aspect with >> some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry >> mentions traffic efficiency/infotainment applications, such as >> in-signage applications... >>=20 >> a.We might have to aim at less controversial use cases to attract >> automotive industries >>=20 >> 3)One potential WI I could think of (rather a basic one): _definition = of >> a vehicular wireless =E2=80=98link=E2=80=99 in an automotive context_ >>=20 >> a.To me, this is a fundamental brick in the larger IETF WG ITS = house.. >>=20 >> 4)I would suggest to be more explicit in the foreseen challenges of = this >> WG, instead of mentioning general use case (which end up be = controversial) >>=20 >> a.Example: maintaining IPv6 connectivity in fast and asymmetric = wireless >> links; also under quickly changing topologies (actually suggested by >> Dick Roy on the chat room) >>=20 >> b.Example: IPv6 addressing in link-local scope.. >>=20 >> c.Example: guaranteeing privacy in IPv6 moving networks etc.. >>=20 >> 5)Before listing academic papers referring to IPv6 in vehicles, I = would >> suggest to first try to list commercial products/solutions that are = in >> vehicles and are using IPv6, possibly suffering from a silo = limitations >> (ex. restricted to a single technology, single use case=E2=80=A6) >>=20 >> a.I think we need to get to products first, before academic visions >>=20 >> My two cents.. >>=20 >> Best Regards, >>=20 >> J=C3=A9r=C3=B4me >>=20 >> *From:*its [mailto:its-bounces@ietf.org = ] >> *On Behalf Of *Alexandre Petrescu >> *Sent:* Wednesday 06 April 2016 23:45 >> *To:* its@ietf.org >> *Subject:* [its] charter ITS >>=20 >> ITSers, >>=20 >> Please see below the current charter. >>=20 >> - the two Problem Statements drafts V2V and V2I joined, so there is = less >> text in charter. >> - added an Item on "List of Research papers..." >>=20 >> Erik: did I understand you correctly that there should be some item = on >> discussing whether link-local addressing is sufficient, whether = prefix >> exchange is necessary? >>=20 >> Dino: should LISP be included in the gap analysis draft which = includes >> C-ACC use-case? OR should we separate a dedicated I-D only with gap >> analysis including ND, MIP, AODVv2, LISP? >>=20 >> Person from mediatek: is the 'zeroconf' need in the = vehicle-to-vehicle >> interface illustrated good enough by the words "moving network to = nearby >> moving network communications"? Or is it better to say "the 1-IP-hop >> between nearby moving networks must be self-configured"? >>=20 >> Nabil, Sandra: is it ok to have a working group item "List of = Research >> Papers for IP in V2V and V2I communications"? >>=20 >> Other comments? >>=20 >> Alex >>=20 >> ------------------------------------------------------------------ >>=20 >> ITS (name to change) >> Charter >> April 6th, 2016 >> http://ietf.org/mailman/listinfo/its >>=20 >>=20 >> Intelligent Transportation Systems (its) >> ---------------------------------------- >> Current Status: WG forming >>=20 >> Chairs: >> TBD >>=20 >> Assigned Area Director: >> TBD >>=20 >> Mailing list >> Address: its@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/its >> Archive: >> http://www.ietf.org/mail-archive/web/its/current/maillist.html >>=20 >> Additional web page >> TBD >>=20 >> Charter: >>=20 >> Goal >> ---- >> The goal of this group is to standardize IP-based protocols for >> establishing direct and secure connectivity between moving networks, >> some of which could be fixed permanently or temporarily. >>=20 >> Moving Network to Nearby Moving Network Communications >> ------------------------------------------------------ >> The group is concerned with all situations involving moving network = to >> nearby moving network communications. For example: = vehicle-to-vehicle >> communications, nomadic user wearing a PAN and communicating to a >> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in = a >> train, or train-to-intersection signalling. >>=20 >> Example from the automobile communications space >> ------------------------------------------------ >> Automobiles and vehicles of all types are increasingly connected to >> the Internet, either as vehicle-to-vehicle, vehicle-to-infra or >> vehicle-to-Internet. Entertainment apps enhancing comfort, reliable >> data exchanges for road safety, and automated driving are features >> coming in automobiles to hit the roads from now to year 2020. >> Highlighting increased safety as an immediate result of >> hyper-connectivity applied to vehicles, public authorities worldwide >> are increasingly mandating secure communication technology >> requirements in vehicles. >>=20 >> Emergency apps for new instrumented ambulances carry many benefits >> both to the users and to society in general. >>=20 >> Why IP? >> ------- >> Today, there are several deployed Vehicle-to-Internet technologies, >> including car tethering through driver's cellular smartphone. >> However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure >> communications are still being developed. To improve on a situation >> of link-specific data exchanges, and enable independent application >> sets to share the same links, IP data exchanges are needed. Enabling >> IP communication between vehicles (V2V), and between vehicles and the >> immediate infrastructure (V2I), will provide (0) ability to reach the >> rest of the world on the Internet (1) short and deterministic delays, >> (2) fast forwarding through scalable paths of routers, (3) ease of >> reuse of existing Internet applications in a vehicular environment. >>=20 >> Moving network to nearby moving network communications involve link >> layers such as: 802.11p OCB (Outside the Context of a Basic Service >> Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light >> Communications), IrDA, LTE-D. Only the IP protocols are capable of >> running on each of these links and establish IP paths across them in >> an interoperable manner. >>=20 >> Scenarios? >> ---------- >> There are a few scenarios exhibiting the need to communicate from one >> moving network to another nearby moving network. >>=20 >> In the automobile space, the Cooperative Adaptive Cruise Control and >> Platooning features consider that vehicles close to each other >> exchange data describing their kinematic status. At the cross-roads, >> the moving network inside a vehicle exchanges data with the moving >> network in the red-light pole. >>=20 >> Several public safety scenarios involve moving networks. Distinct >> organizations deploy different moving networks (in-vehicle, = on-person) >> at an incident scene. These networks need to interoperate in order = to >> more effectively understand and deal with the incident scene. >>=20 >> In connected rail scenarios the moving network deployed in trains >> communicate with other moving networks at the cross-points. >>=20 >> What kind of solutions? >> ----------------------- >> The current technical solutions considered to achieve moving network >> to nearby moving network communications are of two kinds: IP routing >> protocols for n-hop path management and 1-hop link-scoped IP protocol >> enhancements. The 1-hop link-scoped protocols include the protocols >> for route establishment involving ICMP Router Advertisements. The >> n-hop path management protocols include n-hop path establishment >> protocols (e.g. Babel, OSPF) and n-hop path search protocols (most >> notably AODV and derivates). >>=20 >> In this proposed Working Group the focus is on 1-hop protocols, and >> leverage from other Working Groups for the n-hop situations. >>=20 >> In some of the moving network applications the window of opportunity >> for exchanging data with the immediate infrastructure may be very >> short. For example, a car driving near a road-side unit may have = only >> 5s to exchange with that RSU (depending on speed, RSU range and >> number). (ephemeral connections). >>=20 >> What kind of requirements? >> -------------------------- >> The requirements for mechanisms for moving network to nearby moving >> network communications are focusing on low delays of the data paths, >> reduced number of messages for path establishment, application >> friendly, resilience to attacks, compatibility with DHCP and Mobile >> IP. >>=20 >> In addition, some moving network to nearby moving network = applications >> involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the >> 1-hop IP moving network to nearby moving netowrk mechanisms will need >> to gracefully support IP multicast. >>=20 >> Due to the inherent characteristics of safety-related communications, >> all new moving network to nearby moving network mechanisms must = afford >> authenticity and confidentiality where necessary. Dynamically >> establishing ephemeral communication paths between automobiles in >> public areas must offer privacy safeguards for the end users >> (passengers). >>=20 >> Establishing 1-hop IP V2V paths must not break the existing on-board >> protocols and applications which communicate with the Internet, >> possibly via multiple radios. >>=20 >> In a moving network deployed in an automobile, typically one exit >> point connects the moving network to other moving networks. However, >> in a more general manner (and to support reliability) any new >> mechanism of moving network to nearby moving network communications >> should support multi-homing: one router to use multiple interfaces >> towards outside the moving network, or multiple routers. >>=20 >> Current version of Internet protocols >> ------------------------------------- >> The group will only work on IPv6 solutions. >>=20 >> What SDOs may need this work? >> ----------------------------- >> The requirements and standards for moving network to nearby moving >> network communications, often involving IPv6, and novel V2V and >> V2Infra concepts, are developed mainly at ISO TC204 "Intelligent >> Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For >> Vehicle-to-Internet communications, 3GPP LTE and other cellular >> technologies represent the long-range connectivity method; for >> Vehicle-to-Vehicle communications, LTE Direct is currently specified, >> as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need >> for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive >> Cruise Control and Platooning. The IEEE developed a popular link for >> short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a >> set of requirements for V2V communications. >>=20 >> Work Items >> ---------- >> - use-cases for moving network to nearby moving network = communications >> - Problem Statement for moving network to nearby moving network >> communications >> including V2V, V2I and DNS. >> - Security and Privacy Requirements for moving network to >> nearby moving network communications >> - Solutions, which might include new protocols or extensions to >> existing protocols. With MIB. >> - IPv6-over foo, where foo is pertinent for moving network to nearby >> moving network communications (e.g. 802.11 OCB, VLC, LTE-D, = 802.11ad) >> - List of Research Papers in the V2V domain, identifying which uses = IP. >>=20 >> Timeline >> -------- >> - >>=20 >>=20 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 >>=20 >> -- >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Assistant Professor >> Department of Software >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com , >> pauljeong@skku.edu >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >> >>=20 >>=20 >>=20 >> -- >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Assistant Professor >> Department of Software >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com , >> pauljeong@skku.edu >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >> >>=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Sun Apr 17 23:52:57 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4088412DBC4 for ; Sun, 17 Apr 2016 23:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlB0ijwrWTTR for ; Sun, 17 Apr 2016 23:52:54 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5926112DC11 for ; Sun, 17 Apr 2016 23:52:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3I6qo2w008487; Mon, 18 Apr 2016 08:52:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 15FFD209E56; Mon, 18 Apr 2016 08:54:16 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 088C1209DDA; Mon, 18 Apr 2016 08:54:16 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3I6qoaN001501; Mon, 18 Apr 2016 08:52:50 +0200 To: Jong-Hyouk Lee References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> From: Alexandre Petrescu Message-ID: <57148442.4030204@gmail.com> Date: Mon, 18 Apr 2016 08:52:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 06:52:56 -0000 Hi Jong-Hyouk, Le 17/04/2016 14:07, Jong-Hyouk Lee a écrit : > Hi Alex > > Just to clarify. -- Jong-Hyouk Lee, living somewhere between > /dev/null and /dev/random Protocol Engineering Lab., Sangmyung > University > > #email: jonghyouk@gmail.com #webpage: > https://sites.google.com/site/hurryon > >> On Apr 14, 2016, at 5:42 PM, Alexandre Petrescu >> wrote: >> >> ITSers, >> >> We work on a more rigorous ITS charter text. >> >> Now we propose four work items: >> >> 1. "Problem statement for IP in V2V and V2I" including "IP >> addressing architecture for V2V and V2I" and including "Gap >> Analysis: IP protocols suited and gaps" and including "Use-cases >> for IP in V2V and V2I moving network to nearby moving or fixed >> network” > > Are you intending to have one document that includes those three > parts? Yes. Because we need to reduce the number of items. Because one of the remarks during BoF was that the scope was too large. >> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >> context” > > Is this mean that this group first go for this and later considers a > general security document (e.g., security requirements for ITS) ? For now it is "Threat Analysis for IP prefix exchanges in V2V and V2I context". "General security requirements for ITS" seems very broad - what do you mean more precisely? Alex > > Cheers. > >> >> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], >> including connectivity in fast and asymmetric conditions, coverage >> area vs speed diagrams, below-IP congestion management. >> >> 4. "List of papers and _products_ using IP in V2V and V2I" >> >> What do you think? >> >> Please respond by next Monday, April 18th. >> >> Alex and Dapeng [*] a typical IP-over-foo document is, for example, >> RFC2464 "Transmission of IPv6 Packets over Ethernet Networks", >> where "foo" is instantiated as "Ethernet". Other IPv6-over-foo >> documents are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" >> and more. >> >> Le 14/04/2016 09:42, Jérôme Härri a écrit : >>> Paul, >>> >>> Thanks. Btw, when I mentioned ‘people’ are aware of IP V2V but >>> not see the need (so far), I referred to the automotive SDOs (led >>> by automotive industries)…, although there are always ‘minority >>> reports’ J >>> >>> Cheers, >>> >>> Jérôme >>> >>> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] >>> *Sent:* Thursday 14 April 2016 09:36 *To:* Jérôme Härri *Cc:* >>> Alexandre Petrescu; its@ietf.org *Subject:* Re: [its] charter >>> ITS >>> >>> Jérôme, >>> >>> I missed that you are also an academic person. >>> >>> I got it :-) >>> >>> I understand your points for industry activity related to >>> vehicular networking. >>> >>> Your observation seems true. >>> >>> BTW, I will invite you to my team for the draft for a list of >>> academic papers for V2V and V2I >>> >>> by a personal message. >>> >>> Thanks. >>> >>> Paul >>> >>> On Thu, Apr 14, 2016 at 4:09 PM, Jérôme Härri >>> > >>> wrote: >>> >>> Hi Paul, >>> >>> Thanks for your feedback. Do not get me wrong, I am an academic >>> and with my team, we also work on IP-based V2V and V2I, in >>> particular related to mobility management with DMM, but also in >>> the context of vehicular IoT. >>> >>> I just have the feeling that people are perfectly aware of the >>> fact that IP _can_ be used for V2V and V2I, but does not ‘_need_’ >>> to be used as other solutions already perfectly fit their need. >>> Listing papers will not change this awareness. >>> >>> So, as a complement to academic papers, it would help to be able >>> to pin-point which industrial activities are using or are >>> strongly planning (short term I mean) to use pure IPv6 system in >>> vehicles. >>> >>> My feeling here is we have a different eco-system that the >>> Automotive industry (and automotive industry-related SDO)..more >>> likely the IoT industry…and as such, we should not need to have >>> the (direct) involvement of automotive industry in the Charter. >>> If we can make this clear by an industry-based ‘survey’, that >>> would help make the case for the WG. >>> >>> Btw, you can count on me your draft..we can add some IP-based V2V >>> and V2I for mobility management and also IoT. >>> >>> Cheers, >>> >>> Jérôme >>> >>> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com >>> ] *Sent:* Thursday 14 April 2016 >>> 03:22 *To:* Jérôme Härri *Cc:* Alexandre Petrescu; its@ietf.org >>> *Subject:* Re: [its] charter ITS >>> >>> Hi Jérôme, >>> >>> I have an opinion on your comment 5) below. >>> >>> I think that a list of high-quality papers about IP-based V2V and >>> V2I >>> >>> can teach very useful lessons to software designers of IP in V2V >>> and V2I >>> >>> in the industry. >>> >>> Multiple people are working for this IP-based V2V and V2I >>> >>> (including Sandra Cespedes and me) in academia and >>> >>> more people(including Nabil Benamar) are willing to work for this >>> area. >>> >>> I think we need to utilize the list of such papers as the ground >>> for our ITS group >>> >>> through a WI. Note that the draft of the list will include the >>> summary of the main >>> >>> ideas of the papers. >>> >>> For the industry current activities for this area, I believe that >>> you can share them >>> >>> as references through our ITS mailing list rather than through a >>> WI. >>> >>> Could you join my team that are making efforts for a list of such >>> papers? >>> >>> Thanks. >>> >>> Best Regards, >>> >>> Paul >>> >>> On Thu, Apr 7, 2016 at 8:11 AM, Jérôme Härri >>> > >>> wrote: >>> >>> Dear ITSers, Dear Alex, >>> >>> Here are some comments on the updated charter: >>> >>> 1)Can we keep a reference to IEEE 802.11p, considering it does >>> not exist anymore? It is now fully integrated into IEEE >>> 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of course. >>> >>> 2)Should we really keep C-ACC (or Platooning) in the charter >>> explicitly as use case, considering it is a seriously >>> controversial aspect with some SDOs (ex. In Automotive SDOs)? In >>> the ISO presentation, Thierry mentions traffic >>> efficiency/infotainment applications, such as in-signage >>> applications... >>> >>> a.We might have to aim at less controversial use cases to >>> attract automotive industries >>> >>> 3)One potential WI I could think of (rather a basic one): >>> _definition of a vehicular wireless ‘link’ in an automotive >>> context_ >>> >>> a.To me, this is a fundamental brick in the larger IETF WG ITS >>> house.. >>> >>> 4)I would suggest to be more explicit in the foreseen challenges >>> of this WG, instead of mentioning general use case (which end up >>> be controversial) >>> >>> a.Example: maintaining IPv6 connectivity in fast and asymmetric >>> wireless links; also under quickly changing topologies (actually >>> suggested by Dick Roy on the chat room) >>> >>> b.Example: IPv6 addressing in link-local scope.. >>> >>> c.Example: guaranteeing privacy in IPv6 moving networks etc.. >>> >>> 5)Before listing academic papers referring to IPv6 in vehicles, I >>> would suggest to first try to list commercial products/solutions >>> that are in vehicles and are using IPv6, possibly suffering from >>> a silo limitations (ex. restricted to a single technology, single >>> use case…) >>> >>> a.I think we need to get to products first, before academic >>> visions >>> >>> My two cents.. >>> >>> Best Regards, >>> >>> Jérôme >>> >>> *From:*its [mailto:its-bounces@ietf.org >>> ] *On Behalf Of *Alexandre Petrescu >>> *Sent:* Wednesday 06 April 2016 23:45 *To:* its@ietf.org >>> *Subject:* [its] charter ITS >>> >>> ITSers, >>> >>> Please see below the current charter. >>> >>> - the two Problem Statements drafts V2V and V2I joined, so there >>> is less text in charter. - added an Item on "List of Research >>> papers..." >>> >>> Erik: did I understand you correctly that there should be some >>> item on discussing whether link-local addressing is sufficient, >>> whether prefix exchange is necessary? >>> >>> Dino: should LISP be included in the gap analysis draft which >>> includes C-ACC use-case? OR should we separate a dedicated I-D >>> only with gap analysis including ND, MIP, AODVv2, LISP? >>> >>> Person from mediatek: is the 'zeroconf' need in the >>> vehicle-to-vehicle interface illustrated good enough by the words >>> "moving network to nearby moving network communications"? Or is >>> it better to say "the 1-IP-hop between nearby moving networks >>> must be self-configured"? >>> >>> Nabil, Sandra: is it ok to have a working group item "List of >>> Research Papers for IP in V2V and V2I communications"? >>> >>> Other comments? >>> >>> Alex >>> >>> ------------------------------------------------------------------ >>> >>> >>> ITS (name to change) >>> Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its >>> >>> >>> Intelligent Transportation Systems (its) >>> ---------------------------------------- Current Status: WG >>> forming >>> >>> Chairs: TBD >>> >>> Assigned Area Director: TBD >>> >>> Mailing list Address: its@ietf.org 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: >>> >>> Goal ---- The goal of this group is to standardize IP-based >>> protocols for establishing direct and secure connectivity between >>> moving networks, some of which could be fixed permanently or >>> temporarily. >>> >>> Moving Network to Nearby Moving Network Communications >>> ------------------------------------------------------ The group >>> is concerned with all situations involving moving network to >>> nearby moving network communications. For example: >>> vehicle-to-vehicle communications, nomadic user wearing a PAN and >>> communicating to a homenet, vehicle-to-infrastructure >>> communications, wagon-to-wagon in a train, or >>> train-to-intersection signalling. >>> >>> Example from the automobile communications space >>> ------------------------------------------------ Automobiles and >>> vehicles of all types are increasingly connected to the Internet, >>> either as vehicle-to-vehicle, vehicle-to-infra or >>> vehicle-to-Internet. Entertainment apps enhancing comfort, >>> reliable data exchanges for road safety, and automated driving >>> are features coming in automobiles to hit the roads from now to >>> year 2020. Highlighting increased safety as an immediate result >>> of hyper-connectivity applied to vehicles, public authorities >>> worldwide are increasingly mandating secure communication >>> technology requirements in vehicles. >>> >>> Emergency apps for new instrumented ambulances carry many >>> benefits both to the users and to society in general. >>> >>> Why IP? ------- Today, there are several deployed >>> Vehicle-to-Internet technologies, including car tethering through >>> driver's cellular smartphone. However, Vehicle-to-Vehicle and >>> Vehicle-to-Infrastructure communications are still being >>> developed. To improve on a situation of link-specific data >>> exchanges, and enable independent application sets to share the >>> same links, IP data exchanges are needed. Enabling IP >>> communication between vehicles (V2V), and between vehicles and >>> the immediate infrastructure (V2I), will provide (0) ability to >>> reach the rest of the world on the Internet (1) short and >>> deterministic delays, (2) fast forwarding through scalable paths >>> of routers, (3) ease of reuse of existing Internet applications >>> in a vehicular environment. >>> >>> Moving network to nearby moving network communications involve >>> link layers such as: 802.11p OCB (Outside the Context of a Basic >>> Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible >>> Light Communications), IrDA, LTE-D. Only the IP protocols are >>> capable of running on each of these links and establish IP paths >>> across them in an interoperable manner. >>> >>> Scenarios? ---------- There are a few scenarios exhibiting the >>> need to communicate from one moving network to another nearby >>> moving network. >>> >>> In the automobile space, the Cooperative Adaptive Cruise Control >>> and Platooning features consider that vehicles close to each >>> other exchange data describing their kinematic status. At the >>> cross-roads, the moving network inside a vehicle exchanges data >>> with the moving network in the red-light pole. >>> >>> Several public safety scenarios involve moving networks. >>> Distinct organizations deploy different moving networks >>> (in-vehicle, on-person) at an incident scene. These networks >>> need to interoperate in order to more effectively understand and >>> deal with the incident scene. >>> >>> In connected rail scenarios the moving network deployed in >>> trains communicate with other moving networks at the >>> cross-points. >>> >>> What kind of solutions? ----------------------- The current >>> technical solutions considered to achieve moving network to >>> nearby moving network communications are of two kinds: IP >>> routing protocols for n-hop path management and 1-hop link-scoped >>> IP protocol enhancements. The 1-hop link-scoped protocols >>> include the protocols for route establishment involving ICMP >>> Router Advertisements. The n-hop path management protocols >>> include n-hop path establishment protocols (e.g. Babel, OSPF) and >>> n-hop path search protocols (most notably AODV and derivates). >>> >>> In this proposed Working Group the focus is on 1-hop protocols, >>> and leverage from other Working Groups for the n-hop situations. >>> >>> In some of the moving network applications the window of >>> opportunity for exchanging data with the immediate infrastructure >>> may be very short. For example, a car driving near a road-side >>> unit may have only 5s to exchange with that RSU (depending on >>> speed, RSU range and number). (ephemeral connections). >>> >>> What kind of requirements? -------------------------- The >>> requirements for mechanisms for moving network to nearby moving >>> network communications are focusing on low delays of the data >>> paths, reduced number of messages for path establishment, >>> application friendly, resilience to attacks, compatibility with >>> DHCP and Mobile IP. >>> >>> In addition, some moving network to nearby moving network >>> applications involve IP multicast mechanisms (e.g. virtual >>> siren); thus C-ACC the 1-hop IP moving network to nearby moving >>> netowrk mechanisms will need to gracefully support IP multicast. >>> >>> Due to the inherent characteristics of safety-related >>> communications, all new moving network to nearby moving network >>> mechanisms must afford authenticity and confidentiality where >>> necessary. Dynamically establishing ephemeral communication >>> paths between automobiles in public areas must offer privacy >>> safeguards for the end users (passengers). >>> >>> Establishing 1-hop IP V2V paths must not break the existing >>> on-board protocols and applications which communicate with the >>> Internet, possibly via multiple radios. >>> >>> In a moving network deployed in an automobile, typically one >>> exit point connects the moving network to other moving networks. >>> However, in a more general manner (and to support reliability) >>> any new mechanism of moving network to nearby moving network >>> communications should support multi-homing: one router to use >>> multiple interfaces towards outside the moving network, or >>> multiple routers. >>> >>> Current version of Internet protocols >>> ------------------------------------- The group will only work on >>> IPv6 solutions. >>> >>> What SDOs may need this work? ----------------------------- The >>> requirements and standards for moving network to nearby moving >>> network communications, often involving IPv6, and novel V2V and >>> V2Infra concepts, are developed mainly at ISO TC204 "Intelligent >>> Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For >>> Vehicle-to-Internet communications, 3GPP LTE and other cellular >>> technologies represent the long-range connectivity method; for >>> Vehicle-to-Vehicle communications, LTE Direct is currently >>> specified, as well as OCB mode of IEEE 802.11. Several use-cases >>> exhibit a need for IPv6 data exchanges between vehicles: ETSI's >>> Cooperative Adaptive Cruise Control and Platooning. The IEEE >>> developed a popular link for short-range communications - IEEE >>> 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V >>> communications. >>> >>> Work Items ---------- - use-cases for moving network to nearby >>> moving network communications - Problem Statement for moving >>> network to nearby moving network communications including V2V, >>> V2I and DNS. - Security and Privacy Requirements for moving >>> network to nearby moving network communications - Solutions, >>> which might include new protocols or extensions to existing >>> protocols. With MIB. - IPv6-over foo, where foo is pertinent for >>> moving network to nearby moving network communications (e.g. >>> 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in >>> the V2V domain, identifying which uses IP. >>> >>> Timeline -------- - >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>> >>> >>> -- >>> >>> =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. >>> Assistant Professor Department of Software Sungkyunkwan >>> University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>> , pauljeong@skku.edu >>> Personal Homepage: >>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>> >>> >>> >>> >>> -- >>> >>> =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. >>> Assistant Professor Department of Software Sungkyunkwan >>> University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>> , pauljeong@skku.edu >>> Personal Homepage: >>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>> >>> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Mon Apr 18 00:32:36 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6CA12DE1C for ; Mon, 18 Apr 2016 00:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zg7os7eKERoQ for ; Mon, 18 Apr 2016 00:32:30 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8445312DE1B for ; Mon, 18 Apr 2016 00:32:30 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id r187so16412024pfr.2 for ; Mon, 18 Apr 2016 00:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=7FuXGrpHOxVq27RPwArAVa55AO7LWZoapQXa2w9+EiM=; b=sg7Y+KPgyl2GlroMgyeIHfLJUig+tHQfa/1N4nf4Ja/nxZs/Mb7ImQ+XEhwNtEJSYc ciiO/JdruWDqcWTui7i0eYyr8uIZ8xFLK7Q7cPuC9Z63UKpuZYeqTKE0VrVQGZ+uL1Dm P6uXcPM8mCyGmfImKwZX65g1znhwBhaAsjk8ggbaAQLv9QyYqEPF4pngMF9r6iogYMpP rKrvB8gW3oglFq/aKcUp8rrcTkCceX8EG0Y5BMQLS9PE/TjZOVwqIQlFoLl2YI2o47JP MstuO7f90K0soBXYBHTnW3rQIcc0gOG7/fzfoKkS4qJMXQioZzMdAyBObvEev/NYh2Lj rI0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=7FuXGrpHOxVq27RPwArAVa55AO7LWZoapQXa2w9+EiM=; b=LJ9rIZmKu6DIWCmrJ9DUmISbFvceK4licNiTEBft9DykePIBuecEiqH6AO53Ze9TZB WNsOitpz9XPTKqQXUk67DEVlcjF/WdP/XG/goYI2efIzPAjmmtBSz0+uCDztOFoKWE8M P1LVonLrMnW+WEQ7lCgK8PzoMZMF9sGm0JhU/3QEReBxGaSZ2OBMOzgGd1crE7OGKkSm PwuOxm/0HTHGgoTZCpvZBM7wjS7ujGxTUX6Rl+S8NCcIulZpTZRuCmmoWPywCIFA7ucY oUrktWge8ChHAP3RqblCDb0EopbjgwbZVs9H//AAkukJ6/EVnlJdJFwnmi9074vO8BGY jnFQ== X-Gm-Message-State: AOPr4FXwIiMlxqeFW6FbrXj3ShCqlqIpuDbL/gqid+GA9DWgDPm1BVBUsFRGvqd/TUdnnw== X-Received: by 10.98.69.75 with SMTP id s72mr48010574pfa.66.1460964750002; Mon, 18 Apr 2016 00:32:30 -0700 (PDT) Received: from [192.168.0.100] ([203.230.193.110]) by smtp.gmail.com with ESMTPSA id bb5sm36056107pac.21.2016.04.18.00.32.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Apr 2016 00:32:29 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_DBF966FC-B337-457B-A6E8-79A2E8FBDF37" From: Jong-Hyouk Lee In-Reply-To: <57148442.4030204@gmail.com> Date: Mon, 18 Apr 2016 16:32:25 +0900 Message-Id: References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 07:32:34 -0000 --Apple-Mail=_DBF966FC-B337-457B-A6E8-79A2E8FBDF37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thx, plz see inline. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 18, 2016, at 3:52 PM, Alexandre Petrescu = wrote: >=20 > Hi Jong-Hyouk, >=20 > Le 17/04/2016 14:07, Jong-Hyouk Lee a =C3=A9crit : >> Hi Alex >>=20 >> Just to clarify. -- Jong-Hyouk Lee, living somewhere between >> /dev/null and /dev/random Protocol Engineering Lab., Sangmyung >> University >>=20 >> #email: jonghyouk@gmail.com #webpage: >> https://sites.google.com/site/hurryon >>=20 >>> On Apr 14, 2016, at 5:42 PM, Alexandre Petrescu >>> wrote: >>>=20 >>> ITSers, >>>=20 >>> We work on a more rigorous ITS charter text. >>>=20 >>> Now we propose four work items: >>>=20 >>> 1. "Problem statement for IP in V2V and V2I" including "IP >>> addressing architecture for V2V and V2I" and including "Gap >>> Analysis: IP protocols suited and gaps" and including "Use-cases >>> for IP in V2V and V2I moving network to nearby moving or fixed >>> network=E2=80=9D >>=20 >> Are you intending to have one document that includes those three >> parts? >=20 > Yes. >=20 > Because we need to reduce the number of items. Because one of the > remarks during BoF was that the scope was too large. Hum=E2=80=A6then, the document will be too broad. We may need people to = work on each part. >=20 >>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>> context=E2=80=9D >>=20 >> Is this mean that this group first go for this and later considers a >> general security document (e.g., security requirements for ITS) ? >=20 > For now it is "Threat Analysis for IP prefix exchanges in V2V and V2I = context=E2=80=9D. Ok. For the document =E2=80=9CThreat Analysis of IP prefix exchanges in = V2V and V2I=E2=80=9D, I just started to work on. Soon I will post.=20 >=20 > "General security requirements for ITS" seems very broad - what do you = mean more precisely? We may later need one document describing general security requirements = for ITS that corresponds the document =E2=80=9CPS for IP in V2V and = V2I=E2=80=9D. We will be later. ;) Good day! >=20 > Alex >=20 >>=20 >> Cheers. >>=20 >>>=20 >>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], >>> including connectivity in fast and asymmetric conditions, coverage >>> area vs speed diagrams, below-IP congestion management. >>>=20 >>> 4. "List of papers and _products_ using IP in V2V and V2I" >>>=20 >>> What do you think? >>>=20 >>> Please respond by next Monday, April 18th. >>>=20 >>> Alex and Dapeng [*] a typical IP-over-foo document is, for example, >>> RFC2464 "Transmission of IPv6 Packets over Ethernet Networks", >>> where "foo" is instantiated as "Ethernet". Other IPv6-over-foo >>> documents are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" >>> and more. >>>=20 >>> Le 14/04/2016 09:42, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : >>>> Paul, >>>>=20 >>>> Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of = IP V2V but >>>> not see the need (so far), I referred to the automotive SDOs (led >>>> by automotive industries)=E2=80=A6, although there are always = =E2=80=98minority >>>> reports=E2=80=99 J >>>>=20 >>>> Cheers, >>>>=20 >>>> J=C3=A9r=C3=B4me >>>>=20 >>>> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] >>>> *Sent:* Thursday 14 April 2016 09:36 *To:* J=C3=A9r=C3=B4me H=C3=A4rr= i *Cc:* >>>> Alexandre Petrescu; its@ietf.org *Subject:* Re: [its] charter >>>> ITS >>>>=20 >>>> J=C3=A9r=C3=B4me, >>>>=20 >>>> I missed that you are also an academic person. >>>>=20 >>>> I got it :-) >>>>=20 >>>> I understand your points for industry activity related to >>>> vehicular networking. >>>>=20 >>>> Your observation seems true. >>>>=20 >>>> BTW, I will invite you to my team for the draft for a list of >>>> academic papers for V2V and V2I >>>>=20 >>>> by a personal message. >>>>=20 >>>> Thanks. >>>>=20 >>>> Paul >>>>=20 >>>> On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri >>>> > >>>> wrote: >>>>=20 >>>> Hi Paul, >>>>=20 >>>> Thanks for your feedback. Do not get me wrong, I am an academic >>>> and with my team, we also work on IP-based V2V and V2I, in >>>> particular related to mobility management with DMM, but also in >>>> the context of vehicular IoT. >>>>=20 >>>> I just have the feeling that people are perfectly aware of the >>>> fact that IP _can_ be used for V2V and V2I, but does not = =E2=80=98_need_=E2=80=99 >>>> to be used as other solutions already perfectly fit their need. >>>> Listing papers will not change this awareness. >>>>=20 >>>> So, as a complement to academic papers, it would help to be able >>>> to pin-point which industrial activities are using or are >>>> strongly planning (short term I mean) to use pure IPv6 system in >>>> vehicles. >>>>=20 >>>> My feeling here is we have a different eco-system that the >>>> Automotive industry (and automotive industry-related SDO)..more >>>> likely the IoT industry=E2=80=A6and as such, we should not need to = have >>>> the (direct) involvement of automotive industry in the Charter. >>>> If we can make this clear by an industry-based =E2=80=98survey=E2=80=99= , that >>>> would help make the case for the WG. >>>>=20 >>>> Btw, you can count on me your draft..we can add some IP-based V2V >>>> and V2I for mobility management and also IoT. >>>>=20 >>>> Cheers, >>>>=20 >>>> J=C3=A9r=C3=B4me >>>>=20 >>>> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com >>>> ] *Sent:* Thursday 14 April 2016 >>>> 03:22 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:* Alexandre Petrescu; = its@ietf.org >>>> *Subject:* Re: [its] charter ITS >>>>=20 >>>> Hi J=C3=A9r=C3=B4me, >>>>=20 >>>> I have an opinion on your comment 5) below. >>>>=20 >>>> I think that a list of high-quality papers about IP-based V2V and >>>> V2I >>>>=20 >>>> can teach very useful lessons to software designers of IP in V2V >>>> and V2I >>>>=20 >>>> in the industry. >>>>=20 >>>> Multiple people are working for this IP-based V2V and V2I >>>>=20 >>>> (including Sandra Cespedes and me) in academia and >>>>=20 >>>> more people(including Nabil Benamar) are willing to work for this >>>> area. >>>>=20 >>>> I think we need to utilize the list of such papers as the ground >>>> for our ITS group >>>>=20 >>>> through a WI. Note that the draft of the list will include the >>>> summary of the main >>>>=20 >>>> ideas of the papers. >>>>=20 >>>> For the industry current activities for this area, I believe that >>>> you can share them >>>>=20 >>>> as references through our ITS mailing list rather than through a >>>> WI. >>>>=20 >>>> Could you join my team that are making efforts for a list of such >>>> papers? >>>>=20 >>>> Thanks. >>>>=20 >>>> Best Regards, >>>>=20 >>>> Paul >>>>=20 >>>> On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri >>>> > >>>> wrote: >>>>=20 >>>> Dear ITSers, Dear Alex, >>>>=20 >>>> Here are some comments on the updated charter: >>>>=20 >>>> 1)Can we keep a reference to IEEE 802.11p, considering it does >>>> not exist anymore? It is now fully integrated into IEEE >>>> 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of course. >>>>=20 >>>> 2)Should we really keep C-ACC (or Platooning) in the charter >>>> explicitly as use case, considering it is a seriously >>>> controversial aspect with some SDOs (ex. In Automotive SDOs)? In >>>> the ISO presentation, Thierry mentions traffic >>>> efficiency/infotainment applications, such as in-signage >>>> applications... >>>>=20 >>>> a.We might have to aim at less controversial use cases to >>>> attract automotive industries >>>>=20 >>>> 3)One potential WI I could think of (rather a basic one): >>>> _definition of a vehicular wireless =E2=80=98link=E2=80=99 in an = automotive >>>> context_ >>>>=20 >>>> a.To me, this is a fundamental brick in the larger IETF WG ITS >>>> house.. >>>>=20 >>>> 4)I would suggest to be more explicit in the foreseen challenges >>>> of this WG, instead of mentioning general use case (which end up >>>> be controversial) >>>>=20 >>>> a.Example: maintaining IPv6 connectivity in fast and asymmetric >>>> wireless links; also under quickly changing topologies (actually >>>> suggested by Dick Roy on the chat room) >>>>=20 >>>> b.Example: IPv6 addressing in link-local scope.. >>>>=20 >>>> c.Example: guaranteeing privacy in IPv6 moving networks etc.. >>>>=20 >>>> 5)Before listing academic papers referring to IPv6 in vehicles, I >>>> would suggest to first try to list commercial products/solutions >>>> that are in vehicles and are using IPv6, possibly suffering from >>>> a silo limitations (ex. restricted to a single technology, single >>>> use case=E2=80=A6) >>>>=20 >>>> a.I think we need to get to products first, before academic >>>> visions >>>>=20 >>>> My two cents.. >>>>=20 >>>> Best Regards, >>>>=20 >>>> J=C3=A9r=C3=B4me >>>>=20 >>>> *From:*its [mailto:its-bounces@ietf.org >>>> ] *On Behalf Of *Alexandre Petrescu >>>> *Sent:* Wednesday 06 April 2016 23:45 *To:* its@ietf.org >>>> *Subject:* [its] charter ITS >>>>=20 >>>> ITSers, >>>>=20 >>>> Please see below the current charter. >>>>=20 >>>> - the two Problem Statements drafts V2V and V2I joined, so there >>>> is less text in charter. - added an Item on "List of Research >>>> papers..." >>>>=20 >>>> Erik: did I understand you correctly that there should be some >>>> item on discussing whether link-local addressing is sufficient, >>>> whether prefix exchange is necessary? >>>>=20 >>>> Dino: should LISP be included in the gap analysis draft which >>>> includes C-ACC use-case? OR should we separate a dedicated I-D >>>> only with gap analysis including ND, MIP, AODVv2, LISP? >>>>=20 >>>> Person from mediatek: is the 'zeroconf' need in the >>>> vehicle-to-vehicle interface illustrated good enough by the words >>>> "moving network to nearby moving network communications"? Or is >>>> it better to say "the 1-IP-hop between nearby moving networks >>>> must be self-configured"? >>>>=20 >>>> Nabil, Sandra: is it ok to have a working group item "List of >>>> Research Papers for IP in V2V and V2I communications"? >>>>=20 >>>> Other comments? >>>>=20 >>>> Alex >>>>=20 >>>> ------------------------------------------------------------------ >>>>=20 >>>>=20 >>>>=20 > ITS (name to change) >>>> Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its >>>>=20 >>>>=20 >>>> Intelligent Transportation Systems (its) >>>> ---------------------------------------- Current Status: WG >>>> forming >>>>=20 >>>> Chairs: TBD >>>>=20 >>>> Assigned Area Director: TBD >>>>=20 >>>> Mailing list Address: its@ietf.org To >>>> Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: >>>> http://www.ietf.org/mail-archive/web/its/current/maillist.html >>>>=20 >>>> Additional web page TBD >>>>=20 >>>> Charter: >>>>=20 >>>> Goal ---- The goal of this group is to standardize IP-based >>>> protocols for establishing direct and secure connectivity between >>>> moving networks, some of which could be fixed permanently or >>>> temporarily. >>>>=20 >>>> Moving Network to Nearby Moving Network Communications >>>> ------------------------------------------------------ The group >>>> is concerned with all situations involving moving network to >>>> nearby moving network communications. For example: >>>> vehicle-to-vehicle communications, nomadic user wearing a PAN and >>>> communicating to a homenet, vehicle-to-infrastructure >>>> communications, wagon-to-wagon in a train, or >>>> train-to-intersection signalling. >>>>=20 >>>> Example from the automobile communications space >>>> ------------------------------------------------ Automobiles and >>>> vehicles of all types are increasingly connected to the Internet, >>>> either as vehicle-to-vehicle, vehicle-to-infra or >>>> vehicle-to-Internet. Entertainment apps enhancing comfort, >>>> reliable data exchanges for road safety, and automated driving >>>> are features coming in automobiles to hit the roads from now to >>>> year 2020. Highlighting increased safety as an immediate result >>>> of hyper-connectivity applied to vehicles, public authorities >>>> worldwide are increasingly mandating secure communication >>>> technology requirements in vehicles. >>>>=20 >>>> Emergency apps for new instrumented ambulances carry many >>>> benefits both to the users and to society in general. >>>>=20 >>>> Why IP? ------- Today, there are several deployed >>>> Vehicle-to-Internet technologies, including car tethering through >>>> driver's cellular smartphone. However, Vehicle-to-Vehicle and >>>> Vehicle-to-Infrastructure communications are still being >>>> developed. To improve on a situation of link-specific data >>>> exchanges, and enable independent application sets to share the >>>> same links, IP data exchanges are needed. Enabling IP >>>> communication between vehicles (V2V), and between vehicles and >>>> the immediate infrastructure (V2I), will provide (0) ability to >>>> reach the rest of the world on the Internet (1) short and >>>> deterministic delays, (2) fast forwarding through scalable paths >>>> of routers, (3) ease of reuse of existing Internet applications >>>> in a vehicular environment. >>>>=20 >>>> Moving network to nearby moving network communications involve >>>> link layers such as: 802.11p OCB (Outside the Context of a Basic >>>> Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible >>>> Light Communications), IrDA, LTE-D. Only the IP protocols are >>>> capable of running on each of these links and establish IP paths >>>> across them in an interoperable manner. >>>>=20 >>>> Scenarios? ---------- There are a few scenarios exhibiting the >>>> need to communicate from one moving network to another nearby >>>> moving network. >>>>=20 >>>> In the automobile space, the Cooperative Adaptive Cruise Control >>>> and Platooning features consider that vehicles close to each >>>> other exchange data describing their kinematic status. At the >>>> cross-roads, the moving network inside a vehicle exchanges data >>>> with the moving network in the red-light pole. >>>>=20 >>>> Several public safety scenarios involve moving networks. >>>> Distinct organizations deploy different moving networks >>>> (in-vehicle, on-person) at an incident scene. These networks >>>> need to interoperate in order to more effectively understand and >>>> deal with the incident scene. >>>>=20 >>>> In connected rail scenarios the moving network deployed in >>>> trains communicate with other moving networks at the >>>> cross-points. >>>>=20 >>>> What kind of solutions? ----------------------- The current >>>> technical solutions considered to achieve moving network to >>>> nearby moving network communications are of two kinds: IP >>>> routing protocols for n-hop path management and 1-hop link-scoped >>>> IP protocol enhancements. The 1-hop link-scoped protocols >>>> include the protocols for route establishment involving ICMP >>>> Router Advertisements. The n-hop path management protocols >>>> include n-hop path establishment protocols (e.g. Babel, OSPF) and >>>> n-hop path search protocols (most notably AODV and derivates). >>>>=20 >>>> In this proposed Working Group the focus is on 1-hop protocols, >>>> and leverage from other Working Groups for the n-hop situations. >>>>=20 >>>> In some of the moving network applications the window of >>>> opportunity for exchanging data with the immediate infrastructure >>>> may be very short. For example, a car driving near a road-side >>>> unit may have only 5s to exchange with that RSU (depending on >>>> speed, RSU range and number). (ephemeral connections). >>>>=20 >>>> What kind of requirements? -------------------------- The >>>> requirements for mechanisms for moving network to nearby moving >>>> network communications are focusing on low delays of the data >>>> paths, reduced number of messages for path establishment, >>>> application friendly, resilience to attacks, compatibility with >>>> DHCP and Mobile IP. >>>>=20 >>>> In addition, some moving network to nearby moving network >>>> applications involve IP multicast mechanisms (e.g. virtual >>>> siren); thus C-ACC the 1-hop IP moving network to nearby moving >>>> netowrk mechanisms will need to gracefully support IP multicast. >>>>=20 >>>> Due to the inherent characteristics of safety-related >>>> communications, all new moving network to nearby moving network >>>> mechanisms must afford authenticity and confidentiality where >>>> necessary. Dynamically establishing ephemeral communication >>>> paths between automobiles in public areas must offer privacy >>>> safeguards for the end users (passengers). >>>>=20 >>>> Establishing 1-hop IP V2V paths must not break the existing >>>> on-board protocols and applications which communicate with the >>>> Internet, possibly via multiple radios. >>>>=20 >>>> In a moving network deployed in an automobile, typically one >>>> exit point connects the moving network to other moving networks. >>>> However, in a more general manner (and to support reliability) >>>> any new mechanism of moving network to nearby moving network >>>> communications should support multi-homing: one router to use >>>> multiple interfaces towards outside the moving network, or >>>> multiple routers. >>>>=20 >>>> Current version of Internet protocols >>>> ------------------------------------- The group will only work on >>>> IPv6 solutions. >>>>=20 >>>> What SDOs may need this work? ----------------------------- The >>>> requirements and standards for moving network to nearby moving >>>> network communications, often involving IPv6, and novel V2V and >>>> V2Infra concepts, are developed mainly at ISO TC204 "Intelligent >>>> Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For >>>> Vehicle-to-Internet communications, 3GPP LTE and other cellular >>>> technologies represent the long-range connectivity method; for >>>> Vehicle-to-Vehicle communications, LTE Direct is currently >>>> specified, as well as OCB mode of IEEE 802.11. Several use-cases >>>> exhibit a need for IPv6 data exchanges between vehicles: ETSI's >>>> Cooperative Adaptive Cruise Control and Platooning. The IEEE >>>> developed a popular link for short-range communications - IEEE >>>> 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V >>>> communications. >>>>=20 >>>> Work Items ---------- - use-cases for moving network to nearby >>>> moving network communications - Problem Statement for moving >>>> network to nearby moving network communications including V2V, >>>> V2I and DNS. - Security and Privacy Requirements for moving >>>> network to nearby moving network communications - Solutions, >>>> which might include new protocols or extensions to existing >>>> protocols. With MIB. - IPv6-over foo, where foo is pertinent for >>>> moving network to nearby moving network communications (e.g. >>>> 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in >>>> the V2V domain, identifying which uses IP. >>>>=20 >>>> Timeline -------- - >>>>=20 >>>>=20 >>>> _______________________________________________ its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. >>>> Assistant Professor Department of Software Sungkyunkwan >>>> University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>>> , pauljeong@skku.edu >>>> Personal Homepage: >>>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>>> >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. >>>> Assistant Professor Department of Software Sungkyunkwan >>>> University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>>> , pauljeong@skku.edu >>>> Personal Homepage: >>>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>>> >>>>=20 >>>=20 >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_DBF966FC-B337-457B-A6E8-79A2E8FBDF37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thx, plz see inline.
--
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Apr 18, 2016, at 3:52 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

Hi Jong-Hyouk,

Le 17/04/2016 14:07, Jong-Hyouk Lee a =C3=A9crit = :
Hi = Alex

Just to clarify. -- Jong-Hyouk Lee, = living somewhere between
/dev/null and /dev/random = Protocol Engineering Lab., Sangmyung
University

#email: jonghyouk@gmail.com #webpage:
https://sites.google.com/site/hurryon

On Apr 14, 2016, at 5:42 = PM, Alexandre Petrescu
<alexandre.petrescu@gmail.com> = wrote:

ITSers,

We work on a more rigorous ITS charter text.

Now we propose four work items:

1.= "Problem statement for IP in V2V and V2I" including "IP
addressing architecture for V2V and V2I" and including = "Gap
Analysis: IP protocols suited and gaps" and including = "Use-cases
for IP in V2V and V2I moving network to nearby = moving or fixed
network=E2=80=9D

Are you intending to have one = document that includes those three
parts?

Yes.

Because we need to reduce the number of items. =  Because one of the
remarks during BoF was that the scope was = too large.

Hum=E2=80=A6t= hen, the document will be too broad. We may need people to work on each = part.


2. "Threat Analysis for = IP prefix exchanges in V2V and V2I
context=E2=80=9D

Is this mean that this group = first go for this and later considers a
general security = document (e.g., security requirements for ITS) ?

For now it is "Threat Analysis for IP prefix = exchanges in V2V and V2I context=E2=80=9D.

Ok. = For the document =E2=80=9CThreat Analysis of IP prefix exchanges in V2V = and V2I=E2=80=9D, I just started to work on. Soon I will = post. 


"General security requirements for ITS" seems = very broad - what do you mean more precisely?

We may later need one document describing general = security requirements for ITS that corresponds the document =E2=80=9CPS = for IP in V2V and V2I=E2=80=9D. We will be later. ;)

Good day!


Alex


Cheers.


3. "IP over DSRC (802.11-OCB)" typical = IP-over-foo document[*],
including connectivity in fast = and asymmetric conditions, coverage
area vs speed = diagrams, below-IP congestion management.

4. = "List of papers and _products_ using IP in V2V and V2I"

What do you think?

Please = respond by next Monday, April 18th.

Alex = and Dapeng [*] a typical IP-over-foo document is, for example,
RFC2464 "Transmission of IPv6 Packets over Ethernet = Networks",
where "foo" is instantiated as "Ethernet". =  Other IPv6-over-foo
documents are RFC4944 "IPv6 over = 802.15.4" RFC5072 "IPv6 over PPP"
and more.

Le 14/04/2016 09:42, J=C3=A9r=C3=B4me H=C3=A4rri= a =C3=A9crit :
Paul,

Thanks. Btw, when I = mentioned =E2=80=98people=E2=80=99 are aware of IP V2V but
not see the need (so far), I referred to the automotive SDOs = (led
by automotive industries)=E2=80=A6, although there = are always =E2=80=98minority
reports=E2=80=99 J

Cheers,

J=C3=A9r=C3= =B4me

*From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com]
*Sent:* = Thursday 14 April 2016 09:36 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:*
Alexandre Petrescu; its@ietf.org *Subject:* Re: [its] charter
ITS

J=C3=A9r=C3=B4me,

I missed that you are also an academic = person.

I got it :-)

I understand your points for industry activity related to
vehicular networking.

Your = observation seems true.

BTW, I will invite = you to my team for the draft for a list of
academic papers = for V2V and V2I

by a personal message.

Thanks.

Paul

On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4m= e H=C3=A4rri
<jerome.haerri@eurecom.fr <mailto:jerome.haerri@eurecom.fr>>
wrote:

Hi Paul,

Thanks for your feedback. Do not get me wrong, I am an = academic
and with my team, we also work on IP-based V2V = and V2I, in
particular related to mobility management with = DMM, but also in
the context of vehicular IoT.

I just have the feeling that people are = perfectly aware of the
fact that IP _can_ be used for V2V = and V2I, but does not =E2=80=98_need_=E2=80=99
to be used = as other solutions already perfectly fit their need.
Listing= papers will not change this awareness.

So, = as a complement to academic papers, it would help to be able
to pin-point which industrial activities are using or are
strongly planning (short term I mean) to use pure IPv6 system = in
vehicles.

My feeling here = is we have a different eco-system that the
Automotive = industry (and automotive industry-related SDO)..more
likely = the IoT industry=E2=80=A6and as such, we should not need to have
the (direct) involvement of automotive industry in the = Charter.
If we can make this clear by an industry-based = =E2=80=98survey=E2=80=99, that
would help make the case = for the WG.

Btw, you can count on me your = draft..we can add some IP-based V2V
and V2I for mobility = management and also IoT.

Cheers,

J=C3=A9r=C3=B4me

*From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com
<mailto:jaehoon.paul@gmail.com>] *Sent:* Thursday 14 = April 2016
03:22 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:* = Alexandre Petrescu; its@ietf.org
<mailto:its@ietf.org> = *Subject:* Re: [its] charter ITS

Hi = J=C3=A9r=C3=B4me,

I have an opinion on your = comment 5) below.

I think that a list of = high-quality papers about IP-based V2V and
V2I

can teach very useful lessons to software = designers of IP in V2V
and V2I

in the industry.

Multiple people = are working for this IP-based V2V and V2I

(including Sandra Cespedes and me) in academia and

more people(including Nabil Benamar) are = willing to work for this
area.

I think we need to utilize the list of such papers as the = ground
for our ITS group

through a WI. Note that the draft of the list will include = the
summary of the main

ideas = of the papers.

For the industry current = activities for this area, I believe that
you can share = them

as references through our ITS mailing = list rather than through a
WI.

Could you join my team that are making efforts for a list of = such
papers?

Thanks.

Best Regards,

Paul

On Thu, Apr 7, 2016 at 8:11 = AM, J=C3=A9r=C3=B4me H=C3=A4rri
<jerome.haerri@eurecom.fr <mailto:jerome.haerri@eurecom.fr>>
wrote:

Dear ITSers,  Dear = Alex,

Here are some comments on the updated = charter:

1)Can we keep a reference to IEEE = 802.11p, considering it does
not exist anymore? It is now = fully integrated into IEEE
802.11-2012 as OCB mode (and = 10Mhz @5.9Ghz) of course.

2)Should we = really keep C-ACC (or Platooning) in the charter
explicitly = as use case, considering it is a seriously
controversial = aspect with some SDOs (ex. In Automotive SDOs)? In
the ISO = presentation, Thierry mentions traffic
efficiency/infotainment applications, such as in-signage
applications...

a.We might have = to aim at less controversial use cases to
attract = automotive industries

3)One potential WI I = could think of (rather a basic one):
_definition of a = vehicular wireless =E2=80=98link=E2=80=99 in an automotive
context_

a.To me, this is =  a fundamental brick in the larger IETF WG ITS
house..

4)I would suggest to be = more explicit in the foreseen challenges
of this WG, = instead of mentioning general use case (which end up
be = controversial)

a.Example: maintaining IPv6 = connectivity in fast and asymmetric
wireless links; also = under quickly changing topologies (actually
suggested by = Dick Roy on the chat room)

b.Example: IPv6 = addressing in link-local scope..

c.Example: = guaranteeing privacy in IPv6 moving networks etc..

5)Before listing academic papers referring to IPv6 in = vehicles, I
would suggest to first try to list commercial = products/solutions
that are in vehicles and are using = IPv6, possibly suffering from
a silo limitations (ex. = restricted to a single technology, single
use case=E2=80=A6)=

a.I think we need to get to products = first, before academic
visions

My two cents..

Best Regards,

J=C3=A9r=C3=B4me

*From:*its [mailto:its-bounces@ietf.org
<mailto:its-bounces@ietf.org>] *On Behalf Of *Alexandre = Petrescu
*Sent:* Wednesday 06 April 2016 23:45 *To:* its@ietf.org
<mailto:its@ietf.org> *Subject:* [its] charter ITS

ITSers,

Please = see below the current charter.

- the two = Problem Statements drafts V2V and V2I joined, so there
is = less text in charter. - added an Item on "List of Research
papers..."

Erik: did I = understand you correctly that there should be some
item on = discussing whether link-local addressing is sufficient,
whether prefix exchange is necessary?

Dino: should LISP be included in the gap analysis draft = which
includes C-ACC use-case?  OR should we separate = a dedicated I-D
only with gap analysis including ND, MIP, = AODVv2, LISP?

Person from mediatek: is the = 'zeroconf' need in the
vehicle-to-vehicle interface = illustrated good enough by the words
"moving network to = nearby moving network communications"?  Or is
it = better to say "the 1-IP-hop between nearby moving networks
must be self-configured"?

Nabil, = Sandra: is it ok to have a working group item "List of
Research Papers for IP in V2V and V2I communications"?

Other comments?

Alex

---------------------------------------------------------------= ---



ITS (name to change)
Charter April 6th, 2016 = http://ietf.org/mailman/listinfo/its


Intelligent Transportation Systems (its)
---------------------------------------- Current Status: = WG
forming

Chairs: TBD

Assigned Area Director: TBD

Mailing list Address: its@ietf.org <mailto:its@ietf.org> To
Subscribe: https://www.ietf.org/mailman/listinfo/its Archive:
http://www.ietf.org/mail-archive/web/its/current/maillist.html<= /a>

Additional web page TBD
Charter:

Goal ---- The goal of = this group is to standardize IP-based
protocols for = establishing direct and secure connectivity between
moving = networks, some of which could be fixed permanently or
temporarily.

Moving Network to = Nearby Moving Network Communications
------------------------------------------------------ The = group
is concerned with all situations involving moving = network to
nearby moving network communications.  For = example:
vehicle-to-vehicle communications, nomadic user = wearing a PAN and
communicating to a homenet, = vehicle-to-infrastructure
communications, wagon-to-wagon = in a train, or
train-to-intersection signalling.

Example from the automobile communications = space
------------------------------------------------ = Automobiles and
vehicles of all types are increasingly = connected to the Internet,
either as vehicle-to-vehicle, = vehicle-to-infra or
vehicle-to-Internet. =  Entertainment apps enhancing comfort,
reliable data = exchanges for road safety, and automated driving
are = features coming in automobiles to hit the roads from now to
year 2020. Highlighting increased safety as an immediate = result
of hyper-connectivity applied to vehicles, public = authorities
worldwide are increasingly mandating secure = communication
technology requirements in vehicles.

Emergency apps for new instrumented ambulances = carry many
benefits both to the users and to society in = general.

Why IP? ------- Today, there are = several deployed
Vehicle-to-Internet technologies, = including car tethering through
driver's cellular = smartphone. However, Vehicle-to-Vehicle and
Vehicle-to-Infrastructure communications are still being
developed.  To improve on a situation of link-specific = data
exchanges, and enable independent application sets to = share the
same links, IP data exchanges are needed. =  Enabling IP
communication between vehicles (V2V), = and between vehicles and
the immediate infrastructure = (V2I), will provide (0) ability to
reach the rest of the = world on the Internet (1) short and
deterministic delays, = (2) fast forwarding through scalable paths
of routers, (3) = ease of reuse of existing Internet applications
in a = vehicular environment.

Moving network to = nearby moving network communications involve
link layers = such as: 802.11p OCB (Outside the Context of a Basic
Service= Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible
Light = Communications), IrDA, LTE-D.  Only the IP protocols are
capable of running on each of these links and establish IP = paths
across them in an interoperable manner.

Scenarios? ---------- There are a few = scenarios exhibiting the
need to communicate from one = moving network to another nearby
moving network.

In the automobile space, the Cooperative = Adaptive Cruise Control
and Platooning features consider = that vehicles close to each
other exchange data describing = their kinematic status.  At the
cross-roads, the = moving network inside a vehicle exchanges data
with the = moving network in the red-light pole.

Several= public safety scenarios involve moving networks.
Distinct = organizations deploy different moving networks
(in-vehicle, = on-person) at an incident scene.  These networks
need = to interoperate in order to more effectively understand and
deal with the incident scene.

In = connected rail scenarios the moving network deployed in
trains communicate with other moving networks at the
cross-points.

What kind of = solutions? ----------------------- The current
technical = solutions considered to achieve moving network to
nearby = moving network communications are of two kinds: IP
routing = protocols for n-hop path management and 1-hop link-scoped
IP= protocol enhancements.  The 1-hop link-scoped protocols
include the protocols for route establishment involving = ICMP
Router Advertisements.  The n-hop path = management protocols
include n-hop path establishment = protocols (e.g. Babel, OSPF) and
n-hop path search = protocols (most notably AODV and derivates).

In this proposed Working Group the focus is on 1-hop = protocols,
and leverage from other Working Groups for the = n-hop situations.

In some of the moving = network applications the window of
opportunity for = exchanging data with the immediate infrastructure
may be = very short.  For example, a car driving near a road-side
unit may have only 5s to exchange with that RSU (depending = on
speed, RSU range and number). (ephemeral = connections).

What kind of requirements? = -------------------------- The
requirements for mechanisms = for moving network to nearby moving
network communications = are focusing on low delays of the data
paths, reduced = number of messages for path establishment,
application = friendly, resilience to attacks, compatibility with
DHCP = and Mobile IP.

In addition, some moving = network to nearby moving network
applications involve IP = multicast mechanisms (e.g. virtual
siren); thus C-ACC the = 1-hop IP moving network to nearby moving
netowrk = mechanisms will need to gracefully support IP multicast.
Due to the inherent characteristics of safety-related
communications, all new moving network to nearby moving = network
mechanisms must afford authenticity and = confidentiality where
necessary.  Dynamically = establishing ephemeral communication
paths between = automobiles in public areas must offer privacy
safeguards = for the end users (passengers).

Establishing = 1-hop IP V2V paths must not break the existing
on-board = protocols and applications which communicate with the
Internet, possibly via multiple radios.

In a moving network deployed in an automobile, typically = one
exit point connects the moving network to other moving = networks.
However, in a more general manner (and to = support reliability)
any new mechanism of moving network = to nearby moving network
communications should support = multi-homing: one router to use
multiple interfaces = towards outside the moving network, or
multiple = routers.

Current version of Internet = protocols
------------------------------------- The group = will only work on
IPv6 solutions.

What SDOs may need this work? ----------------------------- = The
requirements and standards for moving network to = nearby moving
network communications, often involving = IPv6, and novel V2V and
V2Infra concepts, are developed = mainly at ISO TC204 "Intelligent
Transport Systems", 3GPP, = ETSI, NHTSA and IEEE.  For
Vehicle-to-Internet = communications, 3GPP LTE and other cellular
technologies = represent the long-range connectivity method; for
Vehicle-to-Vehicle communications, LTE Direct is currently
specified, as well as OCB mode of IEEE 802.11.  Several = use-cases
exhibit a need for IPv6 data exchanges between = vehicles: ETSI's
Cooperative Adaptive Cruise Control and = Platooning.  The IEEE
developed a popular link for = short-range communications - IEEE
802.11p "WAVE". =  The NHTSA wrote a set of requirements for V2V
communications.

Work Items = ---------- - use-cases for moving network to nearby
moving = network communications - Problem Statement for moving
network to nearby moving network communications including = V2V,
V2I and DNS. - Security and Privacy Requirements for = moving
network to nearby moving network communications - = Solutions,
which might include new protocols or extensions = to existing
protocols.  With MIB. - IPv6-over foo, = where foo is pertinent for
moving network to nearby moving = network communications (e.g.
802.11 OCB, VLC, LTE-D, = 802.11ad) - List of Research Papers in
the V2V domain, = identifying which uses IP.

Timeline = -------- -


_______________________________________________ its mailing = list
its@ietf.org <mailto:its@ietf.org>
https://www.ietf.org/mailman/listinfo/its



--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant= Professor Department of Software Sungkyunkwan
University = Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com
<mailto:jaehoon.paul@gmail.com>, pauljeong@skku.edu
<mailto:pauljeong@skku.edu> Personal Homepage:
http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>



--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor Department of Software Sungkyunkwan
University Office: +82-31-299-4957 Email: = jaehoon.paul@gmail.com
<mailto:jaehoon.paul@gmail.com>, pauljeong@skku.edu
<mailto:pauljeong@skku.edu> Personal Homepage:
http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>


_______________________________________________ its mailing = list
its@ietf.org https://www.ietf.org/mailman/listinfo/its

= --Apple-Mail=_DBF966FC-B337-457B-A6E8-79A2E8FBDF37-- From nobody Mon Apr 18 00:52:09 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A0112DDD9 for ; Mon, 18 Apr 2016 00:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBY4CBbGeone for ; Mon, 18 Apr 2016 00:52:06 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C571A12DEA3 for ; Mon, 18 Apr 2016 00:52:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3I7q3kh000470; Mon, 18 Apr 2016 09:52:03 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 17DB5208C53; Mon, 18 Apr 2016 09:53:29 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0AB322013FF; Mon, 18 Apr 2016 09:53:29 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3I7q2cC009284; Mon, 18 Apr 2016 09:52:03 +0200 To: Jong-Hyouk Lee References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> From: Alexandre Petrescu Message-ID: <57149222.8090806@gmail.com> Date: Mon, 18 Apr 2016 09:52:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 07:52:08 -0000 Le 18/04/2016 09:32, Jong-Hyouk Lee a écrit : > Thx, plz see inline. > -- > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > Protocol Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com > #webpage: https://sites.google.com/site/hurryon > >> On Apr 18, 2016, at 3:52 PM, Alexandre Petrescu >> > >> wrote: >> >> Hi Jong-Hyouk, >> >> Le 17/04/2016 14:07, Jong-Hyouk Lee a écrit : >>> Hi Alex >>> >>> Just to clarify. -- Jong-Hyouk Lee, living somewhere between >>> /dev/null and /dev/random Protocol Engineering Lab., Sangmyung >>> University >>> >>> #email: jonghyouk@gmail.com #webpage: >>> https://sites.google.com/site/hurryon >>> >>>> On Apr 14, 2016, at 5:42 PM, Alexandre Petrescu >>>> wrote: >>>> >>>> ITSers, >>>> >>>> We work on a more rigorous ITS charter text. >>>> >>>> Now we propose four work items: >>>> >>>> 1. "Problem statement for IP in V2V and V2I" including "IP >>>> addressing architecture for V2V and V2I" and including "Gap >>>> Analysis: IP protocols suited and gaps" and including "Use-cases >>>> for IP in V2V and V2I moving network to nearby moving or fixed >>>> network” >>> >>> Are you intending to have one document that includes those three >>> parts? >> >> Yes. >> >> Because we need to reduce the number of items. Because one of the >> remarks during BoF was that the scope was too large. > > Hum…then, the document will be too broad. We may need people to work on > each part. Yes. There are already a few drafts for this item. Their authors are interested and agreed on joining some of the efforts. Are you interested in some part of this big document? >>>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>>> context” >>> >>> Is this mean that this group first go for this and later considers a >>> general security document (e.g., security requirements for ITS) ? >> >> For now it is "Threat Analysis for IP prefix exchanges in V2V and V2I >> context”. > > Ok. For the document “Threat Analysis of IP prefix exchanges in V2V and > V2I”, I just started to work on. Soon I will post. I take it as agreement from you, and it will be in the proposed charter text. >> "General security requirements for ITS" seems very broad - what do you >> mean more precisely? > > We may later need one document describing general security requirements > for ITS that corresponds the document “PS for IP in V2V and V2I”. We > will be later. ;) Ok. Alex > > Good day! > >> >> Alex >> >>> >>> Cheers. >>> >>>> >>>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], >>>> including connectivity in fast and asymmetric conditions, coverage >>>> area vs speed diagrams, below-IP congestion management. >>>> >>>> 4. "List of papers and _products_ using IP in V2V and V2I" >>>> >>>> What do you think? >>>> >>>> Please respond by next Monday, April 18th. >>>> >>>> Alex and Dapeng [*] a typical IP-over-foo document is, for example, >>>> RFC2464 "Transmission of IPv6 Packets over Ethernet Networks", >>>> where "foo" is instantiated as "Ethernet". Other IPv6-over-foo >>>> documents are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" >>>> and more. >>>> >>>> Le 14/04/2016 09:42, Jérôme Härri a écrit : >>>>> Paul, >>>>> >>>>> Thanks. Btw, when I mentioned ‘people’ are aware of IP V2V but >>>>> not see the need (so far), I referred to the automotive SDOs (led >>>>> by automotive industries)…, although there are always ‘minority >>>>> reports’ J >>>>> >>>>> Cheers, >>>>> >>>>> Jérôme >>>>> >>>>> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] >>>>> *Sent:* Thursday 14 April 2016 09:36 *To:* Jérôme Härri *Cc:* >>>>> Alexandre Petrescu; its@ietf.org *Subject:* >>>>> Re: [its] charter >>>>> ITS >>>>> >>>>> Jérôme, >>>>> >>>>> I missed that you are also an academic person. >>>>> >>>>> I got it :-) >>>>> >>>>> I understand your points for industry activity related to >>>>> vehicular networking. >>>>> >>>>> Your observation seems true. >>>>> >>>>> BTW, I will invite you to my team for the draft for a list of >>>>> academic papers for V2V and V2I >>>>> >>>>> by a personal message. >>>>> >>>>> Thanks. >>>>> >>>>> Paul >>>>> >>>>> On Thu, Apr 14, 2016 at 4:09 PM, Jérôme Härri >>>>> >>>>> > >>>>> wrote: >>>>> >>>>> Hi Paul, >>>>> >>>>> Thanks for your feedback. Do not get me wrong, I am an academic >>>>> and with my team, we also work on IP-based V2V and V2I, in >>>>> particular related to mobility management with DMM, but also in >>>>> the context of vehicular IoT. >>>>> >>>>> I just have the feeling that people are perfectly aware of the >>>>> fact that IP _can_ be used for V2V and V2I, but does not ‘_need_’ >>>>> to be used as other solutions already perfectly fit their need. >>>>> Listing papers will not change this awareness. >>>>> >>>>> So, as a complement to academic papers, it would help to be able >>>>> to pin-point which industrial activities are using or are >>>>> strongly planning (short term I mean) to use pure IPv6 system in >>>>> vehicles. >>>>> >>>>> My feeling here is we have a different eco-system that the >>>>> Automotive industry (and automotive industry-related SDO)..more >>>>> likely the IoT industry…and as such, we should not need to have >>>>> the (direct) involvement of automotive industry in the Charter. >>>>> If we can make this clear by an industry-based ‘survey’, that >>>>> would help make the case for the WG. >>>>> >>>>> Btw, you can count on me your draft..we can add some IP-based V2V >>>>> and V2I for mobility management and also IoT. >>>>> >>>>> Cheers, >>>>> >>>>> Jérôme >>>>> >>>>> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com >>>>> ] *Sent:* Thursday 14 April 2016 >>>>> 03:22 *To:* Jérôme Härri *Cc:* Alexandre Petrescu; its@ietf.org >>>>> >>>>> *Subject:* Re: [its] charter ITS >>>>> >>>>> Hi Jérôme, >>>>> >>>>> I have an opinion on your comment 5) below. >>>>> >>>>> I think that a list of high-quality papers about IP-based V2V and >>>>> V2I >>>>> >>>>> can teach very useful lessons to software designers of IP in V2V >>>>> and V2I >>>>> >>>>> in the industry. >>>>> >>>>> Multiple people are working for this IP-based V2V and V2I >>>>> >>>>> (including Sandra Cespedes and me) in academia and >>>>> >>>>> more people(including Nabil Benamar) are willing to work for this >>>>> area. >>>>> >>>>> I think we need to utilize the list of such papers as the ground >>>>> for our ITS group >>>>> >>>>> through a WI. Note that the draft of the list will include the >>>>> summary of the main >>>>> >>>>> ideas of the papers. >>>>> >>>>> For the industry current activities for this area, I believe that >>>>> you can share them >>>>> >>>>> as references through our ITS mailing list rather than through a >>>>> WI. >>>>> >>>>> Could you join my team that are making efforts for a list of such >>>>> papers? >>>>> >>>>> Thanks. >>>>> >>>>> Best Regards, >>>>> >>>>> Paul >>>>> >>>>> On Thu, Apr 7, 2016 at 8:11 AM, Jérôme Härri >>>>> >>>>> > >>>>> wrote: >>>>> >>>>> Dear ITSers, Dear Alex, >>>>> >>>>> Here are some comments on the updated charter: >>>>> >>>>> 1)Can we keep a reference to IEEE 802.11p, considering it does >>>>> not exist anymore? It is now fully integrated into IEEE >>>>> 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of course. >>>>> >>>>> 2)Should we really keep C-ACC (or Platooning) in the charter >>>>> explicitly as use case, considering it is a seriously >>>>> controversial aspect with some SDOs (ex. In Automotive SDOs)? In >>>>> the ISO presentation, Thierry mentions traffic >>>>> efficiency/infotainment applications, such as in-signage >>>>> applications... >>>>> >>>>> a.We might have to aim at less controversial use cases to >>>>> attract automotive industries >>>>> >>>>> 3)One potential WI I could think of (rather a basic one): >>>>> _definition of a vehicular wireless ‘link’ in an automotive >>>>> context_ >>>>> >>>>> a.To me, this is a fundamental brick in the larger IETF WG ITS >>>>> house.. >>>>> >>>>> 4)I would suggest to be more explicit in the foreseen challenges >>>>> of this WG, instead of mentioning general use case (which end up >>>>> be controversial) >>>>> >>>>> a.Example: maintaining IPv6 connectivity in fast and asymmetric >>>>> wireless links; also under quickly changing topologies (actually >>>>> suggested by Dick Roy on the chat room) >>>>> >>>>> b.Example: IPv6 addressing in link-local scope.. >>>>> >>>>> c.Example: guaranteeing privacy in IPv6 moving networks etc.. >>>>> >>>>> 5)Before listing academic papers referring to IPv6 in vehicles, I >>>>> would suggest to first try to list commercial products/solutions >>>>> that are in vehicles and are using IPv6, possibly suffering from >>>>> a silo limitations (ex. restricted to a single technology, single >>>>> use case…) >>>>> >>>>> a.I think we need to get to products first, before academic >>>>> visions >>>>> >>>>> My two cents.. >>>>> >>>>> Best Regards, >>>>> >>>>> Jérôme >>>>> >>>>> *From:*its [mailto:its-bounces@ietf.org >>>>> ] *On Behalf Of *Alexandre Petrescu >>>>> *Sent:* Wednesday 06 April 2016 23:45 *To:* its@ietf.org >>>>> >>>>> *Subject:* [its] charter ITS >>>>> >>>>> ITSers, >>>>> >>>>> Please see below the current charter. >>>>> >>>>> - the two Problem Statements drafts V2V and V2I joined, so there >>>>> is less text in charter. - added an Item on "List of Research >>>>> papers..." >>>>> >>>>> Erik: did I understand you correctly that there should be some >>>>> item on discussing whether link-local addressing is sufficient, >>>>> whether prefix exchange is necessary? >>>>> >>>>> Dino: should LISP be included in the gap analysis draft which >>>>> includes C-ACC use-case? OR should we separate a dedicated I-D >>>>> only with gap analysis including ND, MIP, AODVv2, LISP? >>>>> >>>>> Person from mediatek: is the 'zeroconf' need in the >>>>> vehicle-to-vehicle interface illustrated good enough by the words >>>>> "moving network to nearby moving network communications"? Or is >>>>> it better to say "the 1-IP-hop between nearby moving networks >>>>> must be self-configured"? >>>>> >>>>> Nabil, Sandra: is it ok to have a working group item "List of >>>>> Research Papers for IP in V2V and V2I communications"? >>>>> >>>>> Other comments? >>>>> >>>>> Alex >>>>> >>>>> ------------------------------------------------------------------ >>>>> >>>>> >>>>> >> ITS (name to change) >>>>> Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> Intelligent Transportation Systems (its) >>>>> ---------------------------------------- Current Status: WG >>>>> forming >>>>> >>>>> Chairs: TBD >>>>> >>>>> Assigned Area Director: TBD >>>>> >>>>> Mailing list Address: its@ietf.org >>>>> 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: >>>>> >>>>> Goal ---- The goal of this group is to standardize IP-based >>>>> protocols for establishing direct and secure connectivity between >>>>> moving networks, some of which could be fixed permanently or >>>>> temporarily. >>>>> >>>>> Moving Network to Nearby Moving Network Communications >>>>> ------------------------------------------------------ The group >>>>> is concerned with all situations involving moving network to >>>>> nearby moving network communications. For example: >>>>> vehicle-to-vehicle communications, nomadic user wearing a PAN and >>>>> communicating to a homenet, vehicle-to-infrastructure >>>>> communications, wagon-to-wagon in a train, or >>>>> train-to-intersection signalling. >>>>> >>>>> Example from the automobile communications space >>>>> ------------------------------------------------ Automobiles and >>>>> vehicles of all types are increasingly connected to the Internet, >>>>> either as vehicle-to-vehicle, vehicle-to-infra or >>>>> vehicle-to-Internet. Entertainment apps enhancing comfort, >>>>> reliable data exchanges for road safety, and automated driving >>>>> are features coming in automobiles to hit the roads from now to >>>>> year 2020. Highlighting increased safety as an immediate result >>>>> of hyper-connectivity applied to vehicles, public authorities >>>>> worldwide are increasingly mandating secure communication >>>>> technology requirements in vehicles. >>>>> >>>>> Emergency apps for new instrumented ambulances carry many >>>>> benefits both to the users and to society in general. >>>>> >>>>> Why IP? ------- Today, there are several deployed >>>>> Vehicle-to-Internet technologies, including car tethering through >>>>> driver's cellular smartphone. However, Vehicle-to-Vehicle and >>>>> Vehicle-to-Infrastructure communications are still being >>>>> developed. To improve on a situation of link-specific data >>>>> exchanges, and enable independent application sets to share the >>>>> same links, IP data exchanges are needed. Enabling IP >>>>> communication between vehicles (V2V), and between vehicles and >>>>> the immediate infrastructure (V2I), will provide (0) ability to >>>>> reach the rest of the world on the Internet (1) short and >>>>> deterministic delays, (2) fast forwarding through scalable paths >>>>> of routers, (3) ease of reuse of existing Internet applications >>>>> in a vehicular environment. >>>>> >>>>> Moving network to nearby moving network communications involve >>>>> link layers such as: 802.11p OCB (Outside the Context of a Basic >>>>> Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible >>>>> Light Communications), IrDA, LTE-D. Only the IP protocols are >>>>> capable of running on each of these links and establish IP paths >>>>> across them in an interoperable manner. >>>>> >>>>> Scenarios? ---------- There are a few scenarios exhibiting the >>>>> need to communicate from one moving network to another nearby >>>>> moving network. >>>>> >>>>> In the automobile space, the Cooperative Adaptive Cruise Control >>>>> and Platooning features consider that vehicles close to each >>>>> other exchange data describing their kinematic status. At the >>>>> cross-roads, the moving network inside a vehicle exchanges data >>>>> with the moving network in the red-light pole. >>>>> >>>>> Several public safety scenarios involve moving networks. >>>>> Distinct organizations deploy different moving networks >>>>> (in-vehicle, on-person) at an incident scene. These networks >>>>> need to interoperate in order to more effectively understand and >>>>> deal with the incident scene. >>>>> >>>>> In connected rail scenarios the moving network deployed in >>>>> trains communicate with other moving networks at the >>>>> cross-points. >>>>> >>>>> What kind of solutions? ----------------------- The current >>>>> technical solutions considered to achieve moving network to >>>>> nearby moving network communications are of two kinds: IP >>>>> routing protocols for n-hop path management and 1-hop link-scoped >>>>> IP protocol enhancements. The 1-hop link-scoped protocols >>>>> include the protocols for route establishment involving ICMP >>>>> Router Advertisements. The n-hop path management protocols >>>>> include n-hop path establishment protocols (e.g. Babel, OSPF) and >>>>> n-hop path search protocols (most notably AODV and derivates). >>>>> >>>>> In this proposed Working Group the focus is on 1-hop protocols, >>>>> and leverage from other Working Groups for the n-hop situations. >>>>> >>>>> In some of the moving network applications the window of >>>>> opportunity for exchanging data with the immediate infrastructure >>>>> may be very short. For example, a car driving near a road-side >>>>> unit may have only 5s to exchange with that RSU (depending on >>>>> speed, RSU range and number). (ephemeral connections). >>>>> >>>>> What kind of requirements? -------------------------- The >>>>> requirements for mechanisms for moving network to nearby moving >>>>> network communications are focusing on low delays of the data >>>>> paths, reduced number of messages for path establishment, >>>>> application friendly, resilience to attacks, compatibility with >>>>> DHCP and Mobile IP. >>>>> >>>>> In addition, some moving network to nearby moving network >>>>> applications involve IP multicast mechanisms (e.g. virtual >>>>> siren); thus C-ACC the 1-hop IP moving network to nearby moving >>>>> netowrk mechanisms will need to gracefully support IP multicast. >>>>> >>>>> Due to the inherent characteristics of safety-related >>>>> communications, all new moving network to nearby moving network >>>>> mechanisms must afford authenticity and confidentiality where >>>>> necessary. Dynamically establishing ephemeral communication >>>>> paths between automobiles in public areas must offer privacy >>>>> safeguards for the end users (passengers). >>>>> >>>>> Establishing 1-hop IP V2V paths must not break the existing >>>>> on-board protocols and applications which communicate with the >>>>> Internet, possibly via multiple radios. >>>>> >>>>> In a moving network deployed in an automobile, typically one >>>>> exit point connects the moving network to other moving networks. >>>>> However, in a more general manner (and to support reliability) >>>>> any new mechanism of moving network to nearby moving network >>>>> communications should support multi-homing: one router to use >>>>> multiple interfaces towards outside the moving network, or >>>>> multiple routers. >>>>> >>>>> Current version of Internet protocols >>>>> ------------------------------------- The group will only work on >>>>> IPv6 solutions. >>>>> >>>>> What SDOs may need this work? ----------------------------- The >>>>> requirements and standards for moving network to nearby moving >>>>> network communications, often involving IPv6, and novel V2V and >>>>> V2Infra concepts, are developed mainly at ISO TC204 "Intelligent >>>>> Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For >>>>> Vehicle-to-Internet communications, 3GPP LTE and other cellular >>>>> technologies represent the long-range connectivity method; for >>>>> Vehicle-to-Vehicle communications, LTE Direct is currently >>>>> specified, as well as OCB mode of IEEE 802.11. Several use-cases >>>>> exhibit a need for IPv6 data exchanges between vehicles: ETSI's >>>>> Cooperative Adaptive Cruise Control and Platooning. The IEEE >>>>> developed a popular link for short-range communications - IEEE >>>>> 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V >>>>> communications. >>>>> >>>>> Work Items ---------- - use-cases for moving network to nearby >>>>> moving network communications - Problem Statement for moving >>>>> network to nearby moving network communications including V2V, >>>>> V2I and DNS. - Security and Privacy Requirements for moving >>>>> network to nearby moving network communications - Solutions, >>>>> which might include new protocols or extensions to existing >>>>> protocols. With MIB. - IPv6-over foo, where foo is pertinent for >>>>> moving network to nearby moving network communications (e.g. >>>>> 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in >>>>> the V2V domain, identifying which uses IP. >>>>> >>>>> Timeline -------- - >>>>> >>>>> >>>>> _______________________________________________ its mailing list >>>>> its@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. >>>>> Assistant Professor Department of Software Sungkyunkwan >>>>> University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>>>> , pauljeong@skku.edu >>>>> Personal Homepage: >>>>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. >>>>> Assistant Professor Department of Software Sungkyunkwan >>>>> University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>>>> , pauljeong@skku.edu >>>>> Personal Homepage: >>>>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>> >>>>> >>>> >>>> _______________________________________________ its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its > From nobody Mon Apr 18 00:54:57 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E59C12D70A for ; Mon, 18 Apr 2016 00:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vvIcFofLXG1 for ; Mon, 18 Apr 2016 00:54:52 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EB412DC15 for ; Mon, 18 Apr 2016 00:54:51 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id u206so110795184wme.1 for ; Mon, 18 Apr 2016 00:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=lnuQbM3CHtLS12l8d1yod1hxw9g4AayKCw4USX6oJbk=; b=YgrkXdPBQkvWRCg7r04JIpEmwvlpyIQZvvDQOMDPv9D+HuwSlvaaBIhDxeWECM4Z8R 7y4ExM2qY75KfjVlf7NCZpZkx8wP3hXH0kV+NKzwv2qI9khX3qJnHc0XwUbfoQzYtOjg xaylZvotUN2baWXXoEOXMxOzn/wkz7mK8R6ZuTrUYwi0Md8+s+oeycLpoF7kKhrqFrpE h5qGQyvdt2kfEcrtcwxYqGTn+WELJuQzRFGKdQE1a0Rz/Xl+e5wCdOzAIwn0uA+hZTYV UyuTqdRd/dpkUAzxbUFW7F3/qy9IEJSK5+QIlJprwE0O/Rlm0+O5dBsTVsM4GTRKxKHp 2hQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lnuQbM3CHtLS12l8d1yod1hxw9g4AayKCw4USX6oJbk=; b=QfndBo9IaZ1mXZcdXNy0h0uh0xgI9DiIRqaRsy38M7iHdIdyfQt3EBJfRK64FOBTzt TS0nrg7E4dSSwjLBgDuYfOjMDNX4ZUkFjmu1VijLaNgwxf8aRVibtoqmjmKWNB5UZd8R JiJftcFplLjt18waC7KGuBQ26+buh3urjO4deT1cxBIx0D9QXj2Y/KpTYZu3Kop2bkYg 202JXJ0Rg8Qv9wDOzt8UrhpJ21TqHD9UKvpKhU1yaq2dxWscAfrXpXBfwknN1BtfDU2a lykwIjMstMvNIJwH8QmOvkFfWnTJgMOX5/KduWkLiRVXsOUH9H1xcRyJsn7+koetwuln ArUw== X-Gm-Message-State: AOPr4FUlPP0Fm7pIyPZbvLZgFPHCFTRwlZrRYu9o6+caeEzlvwu+z9WMrST03q8CToVCEn7qgK8QAj1cEEKbAQ== MIME-Version: 1.0 X-Received: by 10.195.13.135 with SMTP id ey7mr34092797wjd.161.1460966090181; Mon, 18 Apr 2016 00:54:50 -0700 (PDT) Received: by 10.28.224.137 with HTTP; Mon, 18 Apr 2016 00:54:50 -0700 (PDT) In-Reply-To: <570F57EB.4060606@gmail.com> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> Date: Mon, 18 Apr 2016 08:54:50 +0100 Message-ID: From: Nabil Benamar To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=047d7bb04dc4d595d60530bdacde Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 07:54:56 -0000 --047d7bb04dc4d595d60530bdacde Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, I agree on the current charter since these are the points discussed during the BoF! However there were some replies in this list mentioning to probably add IoT as an exemple of IP based communications. I think that we should keep the focus on vehicular communications/networks and do not diverge from this topic. IoT is fundamentally different from vehicular networks in many aspects such as routing, energy consumption, mac layer, etc... Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Thu, Apr 14, 2016 at 9:42 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > ITSers, > > We work on a more rigorous ITS charter text. > > Now we propose four work items: > > 1. "Problem statement for IP in V2V and V2I" > including "IP addressing architecture for V2V and V2I" > and including "Gap Analysis: IP protocols suited and gaps" > and including "Use-cases for IP in V2V and V2I moving network to > nearby moving or fixed network" > > 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" > > 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], > including connectivity in fast and asymmetric conditions, coverage > area vs speed diagrams, below-IP congestion management. > > 4. "List of papers and _products_ using IP in V2V and V2I" > > What do you think? > > Please respond by next Monday, April 18th. > > Alex and Dapeng > [*] a typical IP-over-foo document is, for example, RFC2464 > "Transmission of IPv6 Packets over Ethernet Networks", where > "foo" is instantiated as "Ethernet". Other IPv6-over-foo documents > are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and more. > > Le 14/04/2016 09:42, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : > >> Paul, >> >> Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of IP V= 2V but not see >> the need (so far), I referred to the automotive SDOs (led by automotive >> industries)=E2=80=A6, although there are always =E2=80=98minority report= s=E2=80=99 J >> >> Cheers, >> >> J=C3=A9r=C3=B4me >> >> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] >> *Sent:* Thursday 14 April 2016 09:36 >> *To:* J=C3=A9r=C3=B4me H=C3=A4rri >> *Cc:* Alexandre Petrescu; its@ietf.org >> *Subject:* Re: [its] charter ITS >> >> J=C3=A9r=C3=B4me, >> >> I missed that you are also an academic person. >> >> I got it :-) >> >> I understand your points for industry activity related to vehicular >> networking. >> >> Your observation seems true. >> >> BTW, I will invite you to my team for the draft for a list of academic >> papers for V2V and V2I >> >> by a personal message. >> >> Thanks. >> >> Paul >> >> On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri > > wrote: >> >> Hi Paul, >> >> Thanks for your feedback. Do not get me wrong, I am an academic and with >> my team, we also work on IP-based V2V and V2I, in particular related to >> mobility management with DMM, but also in the context of vehicular IoT. >> >> I just have the feeling that people are perfectly aware of the fact that >> IP _can_ be used for V2V and V2I, but does not =E2=80=98_need_=E2=80=99 = to be used as >> other solutions already perfectly fit their need. Listing papers will >> not change this awareness. >> >> So, as a complement to academic papers, it would help to be able to >> pin-point which industrial activities are using or are strongly planning >> (short term I mean) to use pure IPv6 system in vehicles. >> >> My feeling here is we have a different eco-system that the Automotive >> industry (and automotive industry-related SDO)..more likely the IoT >> industry=E2=80=A6and as such, we should not need to have the (direct) >> involvement of automotive industry in the Charter. If we can make this >> clear by an industry-based =E2=80=98survey=E2=80=99, that would help mak= e the case for >> the WG. >> >> Btw, you can count on me your draft..we can add some IP-based V2V and >> V2I for mobility management and also IoT. >> >> Cheers, >> >> J=C3=A9r=C3=B4me >> >> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com >> ] >> *Sent:* Thursday 14 April 2016 03:22 >> *To:* J=C3=A9r=C3=B4me H=C3=A4rri >> *Cc:* Alexandre Petrescu; its@ietf.org >> *Subject:* Re: [its] charter ITS >> >> Hi J=C3=A9r=C3=B4me, >> >> I have an opinion on your comment 5) below. >> >> I think that a list of high-quality papers about IP-based V2V and V2I >> >> can teach very useful lessons to software designers of IP in V2V and V2I >> >> in the industry. >> >> Multiple people are working for this IP-based V2V and V2I >> >> (including Sandra Cespedes and me) in academia and >> >> more people(including Nabil Benamar) are willing to work for this area. >> >> I think we need to utilize the list of such papers as the ground for our >> ITS group >> >> through a WI. Note that the draft of the list will include the summary >> of the main >> >> ideas of the papers. >> >> For the industry current activities for this area, I believe that you >> can share them >> >> as references through our ITS mailing list rather than through a WI. >> >> Could you join my team that are making efforts for a list of such papers= ? >> >> Thanks. >> >> Best Regards, >> >> Paul >> >> On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri > > wrote: >> >> Dear ITSers, Dear Alex, >> >> Here are some comments on the updated charter: >> >> 1)Can we keep a reference to IEEE 802.11p, considering it does not exist >> anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mode >> (and 10Mhz @5.9Ghz) of course. >> >> 2)Should we really keep C-ACC (or Platooning) in the charter explicitly >> as use case, considering it is a seriously controversial aspect with >> some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry >> mentions traffic efficiency/infotainment applications, such as >> in-signage applications... >> >> a.We might have to aim at less controversial use cases to attract >> automotive industries >> >> 3)One potential WI I could think of (rather a basic one): _definition of >> a vehicular wireless =E2=80=98link=E2=80=99 in an automotive context_ >> >> a.To me, this is a fundamental brick in the larger IETF WG ITS house.. >> >> 4)I would suggest to be more explicit in the foreseen challenges of this >> WG, instead of mentioning general use case (which end up be controversia= l) >> >> a.Example: maintaining IPv6 connectivity in fast and asymmetric wireless >> links; also under quickly changing topologies (actually suggested by >> Dick Roy on the chat room) >> >> b.Example: IPv6 addressing in link-local scope.. >> >> c.Example: guaranteeing privacy in IPv6 moving networks etc.. >> >> 5)Before listing academic papers referring to IPv6 in vehicles, I would >> suggest to first try to list commercial products/solutions that are in >> vehicles and are using IPv6, possibly suffering from a silo limitations >> (ex. restricted to a single technology, single use case=E2=80=A6) >> >> a.I think we need to get to products first, before academic visions >> >> My two cents.. >> >> Best Regards, >> >> J=C3=A9r=C3=B4me >> >> *From:*its [mailto:its-bounces@ietf.org ] >> *On Behalf Of *Alexandre Petrescu >> *Sent:* Wednesday 06 April 2016 23:45 >> *To:* its@ietf.org >> *Subject:* [its] charter ITS >> >> ITSers, >> >> Please see below the current charter. >> >> - the two Problem Statements drafts V2V and V2I joined, so there is less >> text in charter. >> - added an Item on "List of Research papers..." >> >> Erik: did I understand you correctly that there should be some item on >> discussing whether link-local addressing is sufficient, whether prefix >> exchange is necessary? >> >> Dino: should LISP be included in the gap analysis draft which includes >> C-ACC use-case? OR should we separate a dedicated I-D only with gap >> analysis including ND, MIP, AODVv2, LISP? >> >> Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle >> interface illustrated good enough by the words "moving network to nearby >> moving network communications"? Or is it better to say "the 1-IP-hop >> between nearby moving networks must be self-configured"? >> >> Nabil, Sandra: is it ok to have a working group item "List of Research >> Papers for IP in V2V and V2I communications"? >> >> Other comments? >> >> Alex >> >> ------------------------------------------------------------------ >> >> ITS (name to change) >> Charter >> April 6th, 2016 >> http://ietf.org/mailman/listinfo/its >> >> >> Intelligent Transportation Systems (its) >> ---------------------------------------- >> Current Status: WG forming >> >> Chairs: >> TBD >> >> Assigned Area Director: >> TBD >> >> Mailing list >> Address: its@ietf.org >> 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: >> >> Goal >> ---- >> The goal of this group is to standardize IP-based protocols for >> establishing direct and secure connectivity between moving networks, >> some of which could be fixed permanently or temporarily. >> >> Moving Network to Nearby Moving Network Communications >> ------------------------------------------------------ >> The group is concerned with all situations involving moving network to >> nearby moving network communications. For example: vehicle-to-vehicle >> communications, nomadic user wearing a PAN and communicating to a >> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a >> train, or train-to-intersection signalling. >> >> Example from the automobile communications space >> ------------------------------------------------ >> Automobiles and vehicles of all types are increasingly connected to >> the Internet, either as vehicle-to-vehicle, vehicle-to-infra or >> vehicle-to-Internet. Entertainment apps enhancing comfort, reliable >> data exchanges for road safety, and automated driving are features >> coming in automobiles to hit the roads from now to year 2020. >> Highlighting increased safety as an immediate result of >> hyper-connectivity applied to vehicles, public authorities worldwide >> are increasingly mandating secure communication technology >> requirements in vehicles. >> >> Emergency apps for new instrumented ambulances carry many benefits >> both to the users and to society in general. >> >> Why IP? >> ------- >> Today, there are several deployed Vehicle-to-Internet technologies, >> including car tethering through driver's cellular smartphone. >> However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure >> communications are still being developed. To improve on a situation >> of link-specific data exchanges, and enable independent application >> sets to share the same links, IP data exchanges are needed. Enabling >> IP communication between vehicles (V2V), and between vehicles and the >> immediate infrastructure (V2I), will provide (0) ability to reach the >> rest of the world on the Internet (1) short and deterministic delays, >> (2) fast forwarding through scalable paths of routers, (3) ease of >> reuse of existing Internet applications in a vehicular environment. >> >> Moving network to nearby moving network communications involve link >> layers such as: 802.11p OCB (Outside the Context of a Basic Service >> Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light >> Communications), IrDA, LTE-D. Only the IP protocols are capable of >> running on each of these links and establish IP paths across them in >> an interoperable manner. >> >> Scenarios? >> ---------- >> There are a few scenarios exhibiting the need to communicate from one >> moving network to another nearby moving network. >> >> In the automobile space, the Cooperative Adaptive Cruise Control and >> Platooning features consider that vehicles close to each other >> exchange data describing their kinematic status. At the cross-roads, >> the moving network inside a vehicle exchanges data with the moving >> network in the red-light pole. >> >> Several public safety scenarios involve moving networks. Distinct >> organizations deploy different moving networks (in-vehicle, on-person) >> at an incident scene. These networks need to interoperate in order to >> more effectively understand and deal with the incident scene. >> >> In connected rail scenarios the moving network deployed in trains >> communicate with other moving networks at the cross-points. >> >> What kind of solutions? >> ----------------------- >> The current technical solutions considered to achieve moving network >> to nearby moving network communications are of two kinds: IP routing >> protocols for n-hop path management and 1-hop link-scoped IP protocol >> enhancements. The 1-hop link-scoped protocols include the protocols >> for route establishment involving ICMP Router Advertisements. The >> n-hop path management protocols include n-hop path establishment >> protocols (e.g. Babel, OSPF) and n-hop path search protocols (most >> notably AODV and derivates). >> >> In this proposed Working Group the focus is on 1-hop protocols, and >> leverage from other Working Groups for the n-hop situations. >> >> In some of the moving network applications the window of opportunity >> for exchanging data with the immediate infrastructure may be very >> short. For example, a car driving near a road-side unit may have only >> 5s to exchange with that RSU (depending on speed, RSU range and >> number). (ephemeral connections). >> >> What kind of requirements? >> -------------------------- >> The requirements for mechanisms for moving network to nearby moving >> network communications are focusing on low delays of the data paths, >> reduced number of messages for path establishment, application >> friendly, resilience to attacks, compatibility with DHCP and Mobile >> IP. >> >> In addition, some moving network to nearby moving network applications >> involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the >> 1-hop IP moving network to nearby moving netowrk mechanisms will need >> to gracefully support IP multicast. >> >> Due to the inherent characteristics of safety-related communications, >> all new moving network to nearby moving network mechanisms must afford >> authenticity and confidentiality where necessary. Dynamically >> establishing ephemeral communication paths between automobiles in >> public areas must offer privacy safeguards for the end users >> (passengers). >> >> Establishing 1-hop IP V2V paths must not break the existing on-board >> protocols and applications which communicate with the Internet, >> possibly via multiple radios. >> >> In a moving network deployed in an automobile, typically one exit >> point connects the moving network to other moving networks. However, >> in a more general manner (and to support reliability) any new >> mechanism of moving network to nearby moving network communications >> should support multi-homing: one router to use multiple interfaces >> towards outside the moving network, or multiple routers. >> >> Current version of Internet protocols >> ------------------------------------- >> The group will only work on IPv6 solutions. >> >> What SDOs may need this work? >> ----------------------------- >> The requirements and standards for moving network to nearby moving >> network communications, often involving IPv6, and novel V2V and >> V2Infra concepts, are developed mainly at ISO TC204 "Intelligent >> Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For >> Vehicle-to-Internet communications, 3GPP LTE and other cellular >> technologies represent the long-range connectivity method; for >> Vehicle-to-Vehicle communications, LTE Direct is currently specified, >> as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need >> for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive >> Cruise Control and Platooning. The IEEE developed a popular link for >> short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a >> set of requirements for V2V communications. >> >> Work Items >> ---------- >> - use-cases for moving network to nearby moving network communications >> - Problem Statement for moving network to nearby moving network >> communications >> including V2V, V2I and DNS. >> - Security and Privacy Requirements for moving network to >> nearby moving network communications >> - Solutions, which might include new protocols or extensions to >> existing protocols. With MIB. >> - IPv6-over foo, where foo is pertinent for moving network to nearby >> moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) >> - List of Research Papers in the V2V domain, identifying which uses IP. >> >> Timeline >> -------- >> - >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> >> >> -- >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Assistant Professor >> Department of Software >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com , >> pauljeong@skku.edu >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >> >> >> >> >> -- >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Assistant Professor >> Department of Software >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com , >> pauljeong@skku.edu >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >> >> >> > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --047d7bb04dc4d595d60530bdacde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I agree on the current charter sinc= e these are the points discussed during the BoF! However there were some re= plies in this list mentioning to probably add IoT as an exemple of IP based= communications.=C2=A0 I think that we should keep the focus on vehicular c= ommunications/networks and do not diverge from this topic. IoT is fundament= ally different from vehicular networks in many aspects such as routing, ene= rgy consumption, mac layer, etc...
<= div dir=3D"ltr">
Best regards
Nabil Benamar
---= ----------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88
<= div>

On Thu, Apr 14, 2016 at 9:42 AM, Alexandre P= etrescu <alexandre.petrescu@gmail.com> wrote:
=
ITSers,

We work on a more rigorous ITS charter text.

Now we propose four work items:

1. "Problem statement for IP in V2V and V2I"
=C2=A0 =C2=A0including "IP addressing architecture for V2V and V2I&quo= t;
=C2=A0 =C2=A0and including "Gap Analysis: IP protocols suited and gaps= "
=C2=A0 =C2=A0and including "Use-cases for IP in V2V and V2I moving net= work to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nearby movin= g or fixed network"

2. "Threat Analysis for IP prefix exchanges in V2V and V2I context&quo= t;

3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], =C2=A0 =C2=A0including connectivity in fast and asymmetric conditions, cove= rage
=C2=A0 =C2=A0area vs speed diagrams, below-IP congestion management.

4. "List of papers and _products_ using IP in V2V and V2I"

What do you think?

Please respond by next Monday, April 18th.

Alex and Dapeng
[*] a typical IP-over-foo document is, for example, RFC2464
=C2=A0 =C2=A0 "Transmission of IPv6 Packets over Ethernet Networks&quo= t;, where
=C2=A0 =C2=A0 "foo" is instantiated as "Ethernet".=C2= =A0 Other IPv6-over-foo documents
=C2=A0 =C2=A0 are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6= over PPP" and more.

Le 14/04/2016 09:42, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit :
Paul,

Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of IP V2V = but not see
the need (so far), I referred to the automotive SDOs (led by automotive
industries)=E2=80=A6, although there are always =E2=80=98minority reports= =E2=80=99 J

Cheers,

J=C3=A9r=C3=B4me

*From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com]
*Sent:* Thursday 14 April 2016 09:36
*To:* J=C3=A9r=C3=B4me H=C3=A4rri
*Cc:* Alexandre Petrescu; its@ietf.org
*Subject:* Re: [its] charter ITS

J=C3=A9r=C3=B4me,

I missed that you are also an academic person.

I got it :-)

I understand your points for industry activity related to vehicular
networking.

Your observation seems true.

BTW, I will invite you to my team for the draft for a list of academic
papers for V2V and V2I

by a personal message.

Thanks.

Paul

On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.f= r
<mailto:je= rome.haerri@eurecom.fr>> wrote:

Hi Paul,

Thanks for your feedback. Do not get me wrong, I am an academic and with my team, we also work on IP-based V2V and V2I, in particular related to
mobility management with DMM, but also in the context of vehicular IoT.

I just have the feeling that people are perfectly aware of the fact that IP _can_ be used for V2V and V2I, but does not =E2=80=98_need_=E2=80=99 to = be used as
other solutions already perfectly fit their need. Listing papers will
not change this awareness.

So, as a complement to academic papers, it would help to be able to
pin-point which industrial activities are using or are strongly planning (short term I mean) to use pure IPv6 system in vehicles.

My feeling here is we have a different eco-system that the Automotive
industry (and automotive industry-related SDO)..more likely the IoT
industry=E2=80=A6and as such, we should not need to have the (direct)
involvement of automotive industry in the Charter. If we can make this
clear by an industry-based =E2=80=98survey=E2=80=99, that would help make t= he case for
the WG.

Btw, you can count on me your draft..we can add some IP-based V2V and
V2I for mobility management and also IoT.

Cheers,

J=C3=A9r=C3=B4me

*From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com
<mailto:jaeh= oon.paul@gmail.com>]
*Sent:* Thursday 14 April 2016 03:22
*To:* J=C3=A9r=C3=B4me H=C3=A4rri
*Cc:* Alexandre Petrescu; its@ietf.org <mailto:its@ietf.org>
*Subject:* Re: [its] charter ITS

Hi J=C3=A9r=C3=B4me,

I have an opinion on your comment 5) below.

I think that a list of high-quality papers about IP-based V2V and V2I

can teach very useful lessons to software designers of IP in V2V and V2I
in the industry.

Multiple people are working for this IP-based V2V and V2I

(including Sandra Cespedes and me) in academia and

more people(including Nabil Benamar) are willing to work for this area.

I think we need to utilize the list of such papers as the ground for our ITS group

through a WI. Note that the draft of the list will include the summary
of the main

ideas of the papers.

For the industry current activities for this area, I believe that you
can share them

as references through our ITS mailing list rather than through a WI.

Could you join my team that are making efforts for a list of such papers?
Thanks.

Best Regards,

Paul

On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr=
<mailto:je= rome.haerri@eurecom.fr>> wrote:

Dear ITSers,=C2=A0 Dear Alex,

Here are some comments on the updated charter:

1)Can we keep a reference to IEEE 802.11p, considering it does not exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mode
(and 10Mhz @5.9Ghz) of course.

2)Should we really keep C-ACC (or Platooning) in the charter explicitly
as use case, considering it is a seriously controversial aspect with
some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry
mentions traffic efficiency/infotainment applications, such as
in-signage applications...

a.We might have to aim at less controversial use cases to attract
automotive industries

3)One potential WI I could think of (rather a basic one): _definition of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive context_

a.To me, this is=C2=A0 a fundamental brick in the larger IETF WG ITS house.= .

4)I would suggest to be more explicit in the foreseen challenges of this WG, instead of mentioning general use case (which end up be controversial)<= br>
a.Example: maintaining IPv6 connectivity in fast and asymmetric wireless links; also under quickly changing topologies (actually suggested by
Dick Roy on the chat room)

b.Example: IPv6 addressing in link-local scope..

c.Example: guaranteeing privacy in IPv6 moving networks etc..

5)Before listing academic papers referring to IPv6 in vehicles, I would
suggest to first try to list commercial products/solutions that are in
vehicles and are using IPv6, possibly suffering from a silo limitations
(ex. restricted to a single technology, single use case=E2=80=A6)

a.I think we need to get to products first, before academic visions

My two cents..

Best Regards,

J=C3=A9r=C3=B4me

*From:*its [mailto:its-bounces@ietf.org <mailto:its-bounces@ietf.org>]
*On Behalf Of *Alexandre Petrescu
*Sent:* Wednesday 06 April 2016 23:45
*To:* its@ietf.org &l= t;mailto:its@ietf.org= >
*Subject:* [its] charter ITS

ITSers,

Please see below the current charter.

- the two Problem Statements drafts V2V and V2I joined, so there is less text in charter.
- added an Item on "List of Research papers..."

Erik: did I understand you correctly that there should be some item on
discussing whether link-local addressing is sufficient, whether prefix
exchange is necessary?

Dino: should LISP be included in the gap analysis draft which includes
C-ACC use-case?=C2=A0 OR should we separate a dedicated I-D only with gap analysis including ND, MIP, AODVv2, LISP?

Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehi= cle
interface illustrated good enough by the words "moving network to near= by
moving network communications"?=C2=A0 Or is it better to say "the= 1-IP-hop
between nearby moving networks must be self-configured"?

Nabil, Sandra: is it ok to have a working group item "List of Research=
Papers for IP in V2V and V2I communications"?

Other comments?

Alex

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ITS (name to change)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Chart= er
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 April 6th, 2016
http://ietf.org/mailman/listinfo/its


Intelligent Transportation Systems (its)
----------------------------------------
Current Status: WG forming

Chairs:
=C2=A0 =C2=A0 TBD

Assigned Area Director:
=C2=A0 =C2=A0 TBD

Mailing list
=C2=A0 =C2=A0 Address: it= s@ietf.org <mailto:its@ietf.org>
=C2=A0 =C2=A0 To Subscribe: https://www.ietf.org/mailman/li= stinfo/its
=C2=A0 =C2=A0 Archive:
http://www.ietf.org/mail-archive/web/i= ts/current/maillist.html

Additional web page
=C2=A0 =C2=A0 TBD

Charter:

Goal
----
The goal of this group is to standardize IP-based protocols for
establishing direct and secure connectivity between moving networks,
some of which could be fixed permanently or temporarily.

Moving Network to Nearby Moving Network Communications
------------------------------------------------------
The group is concerned with all situations involving moving network to
nearby moving network communications.=C2=A0 For example: vehicle-to-vehicle=
communications, nomadic user wearing a PAN and communicating to a
homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a
train, or train-to-intersection signalling.

Example from the automobile communications space
------------------------------------------------
Automobiles and vehicles of all types are increasingly connected to
the Internet, either as vehicle-to-vehicle, vehicle-to-infra or
vehicle-to-Internet.=C2=A0 Entertainment apps enhancing comfort, reliable data exchanges for road safety, and automated driving are features
coming in automobiles to hit the roads from now to year 2020.
Highlighting increased safety as an immediate result of
hyper-connectivity applied to vehicles, public authorities worldwide
are increasingly mandating secure communication technology
requirements in vehicles.

Emergency apps for new instrumented ambulances carry many benefits
both to the users and to society in general.

Why IP?
-------
Today, there are several deployed Vehicle-to-Internet technologies,
including car tethering through driver's cellular smartphone.
However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communications are still being developed.=C2=A0 To improve on a situation of link-specific data exchanges, and enable independent application
sets to share the same links, IP data exchanges are needed.=C2=A0 Enabling<= br> IP communication between vehicles (V2V), and between vehicles and the
immediate infrastructure (V2I), will provide (0) ability to reach the
rest of the world on the Internet (1) short and deterministic delays,
(2) fast forwarding through scalable paths of routers, (3) ease of
reuse of existing Internet applications in a vehicular environment.

Moving network to nearby moving network communications involve link
layers such as: 802.11p OCB (Outside the Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light
Communications), IrDA, LTE-D.=C2=A0 Only the IP protocols are capable of running on each of these links and establish IP paths across them in
an interoperable manner.

Scenarios?
----------
There are a few scenarios exhibiting the need to communicate from one
moving network to another nearby moving network.

In the automobile space, the Cooperative Adaptive Cruise Control and
Platooning features consider that vehicles close to each other
exchange data describing their kinematic status.=C2=A0 At the cross-roads,<= br> the moving network inside a vehicle exchanges data with the moving
network in the red-light pole.

Several public safety scenarios involve moving networks.=C2=A0 Distinct
organizations deploy different moving networks (in-vehicle, on-person)
at an incident scene.=C2=A0 These networks need to interoperate in order to=
more effectively understand and deal with the incident scene.

In connected rail scenarios the moving network deployed in trains
communicate with other moving networks at the cross-points.

What kind of solutions?
-----------------------
The current technical solutions considered to achieve moving network
to nearby moving network communications are of two kinds: IP routing
protocols for n-hop path management and 1-hop link-scoped IP protocol
enhancements.=C2=A0 The 1-hop link-scoped protocols include the protocols for route establishment involving ICMP Router Advertisements.=C2=A0 The
n-hop path management protocols include n-hop path establishment
protocols (e.g. Babel, OSPF) and n-hop path search protocols (most
notably AODV and derivates).

In this proposed Working Group the focus is on 1-hop protocols, and
leverage from other Working Groups for the n-hop situations.

In some of the moving network applications the window of opportunity
for exchanging data with the immediate infrastructure may be very
short.=C2=A0 For example, a car driving near a road-side unit may have only=
5s to exchange with that RSU (depending on speed, RSU range and
number). (ephemeral connections).

What kind of requirements?
--------------------------
The requirements for mechanisms for moving network to nearby moving
network communications are focusing on low delays of the data paths,
reduced number of messages for path establishment, application
friendly, resilience to attacks, compatibility with DHCP and Mobile
IP.

In addition, some moving network to nearby moving network applications
involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP moving network to nearby moving netowrk mechanisms will need
to gracefully support IP multicast.

Due to the inherent characteristics of safety-related communications,
all new moving network to nearby moving network mechanisms must afford
authenticity and confidentiality where necessary.=C2=A0 Dynamically
establishing ephemeral communication paths between automobiles in
public areas must offer privacy safeguards for the end users
(passengers).

Establishing 1-hop IP V2V paths must not break the existing on-board
protocols and applications which communicate with the Internet,
possibly via multiple radios.

In a moving network deployed in an automobile, typically one exit
point connects the moving network to other moving networks.=C2=A0 However,<= br> in a more general manner (and to support reliability) any new
mechanism of moving network to nearby moving network communications
should support multi-homing: one router to use multiple interfaces
towards outside the moving network, or multiple routers.

Current version of Internet protocols
-------------------------------------
The group will only work on IPv6 solutions.

What SDOs may need this work?
-----------------------------
The requirements and standards for moving network to nearby moving
network communications, often involving IPv6, and novel V2V and
V2Infra concepts, are developed mainly at ISO TC204 "Intelligent
Transport Systems", 3GPP, ETSI, NHTSA and IEEE.=C2=A0 For
Vehicle-to-Internet communications, 3GPP LTE and other cellular
technologies represent the long-range connectivity method; for
Vehicle-to-Vehicle communications, LTE Direct is currently specified,
as well as OCB mode of IEEE 802.11.=C2=A0 Several use-cases exhibit a need<= br> for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning.=C2=A0 The IEEE developed a popular link for<= br> short-range communications - IEEE 802.11p "WAVE".=C2=A0 The NHTSA= wrote a
set of requirements for V2V communications.

Work Items
----------
- use-cases for moving network to nearby moving network communications
- Problem Statement for moving network to nearby moving network
communications
=C2=A0 =C2=A0including V2V, V2I and DNS.
- Security and Privacy Requirements for moving network to
=C2=A0 =C2=A0nearby moving network communications
- Solutions, which might include new protocols or extensions to
=C2=A0 =C2=A0existing protocols.=C2=A0 With MIB.
- IPv6-over foo, where foo is pertinent for moving network to nearby
=C2=A0 =C2=A0moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 80= 2.11ad)
- List of Research Papers in the V2V domain, identifying which uses IP.

Timeline
--------
-


_______________________________________________
its mailing list
its@ietf.org <mail= to:its@ietf.org> https://www.ietf.org/mailman/listinfo/its



--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com <mailto:jaehoon.paul@gmail.com>,
pauljeong@skku.edu<= /a> <mailto:paul= jeong@skku.edu>
Personal Homepage: http://iotlab.skku.edu/people-jaeh= oon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>



--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com <mailto:jaehoon.paul@gmail.com>,
pauljeong@skku.edu<= /a> <mailto:paul= jeong@skku.edu>
Personal Homepage: http://iotlab.skku.edu/people-jaeh= oon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>


_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

--047d7bb04dc4d595d60530bdacde-- From nobody Mon Apr 18 03:07:41 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC01C12D80B for ; Mon, 18 Apr 2016 03:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB4Nr3GddH3e for ; Mon, 18 Apr 2016 03:07:36 -0700 (PDT) Received: from mail-pa0-x243.google.com (mail-pa0-x243.google.com [IPv6:2607:f8b0:400e:c03::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E44012D78B for ; Mon, 18 Apr 2016 03:07:36 -0700 (PDT) Received: by mail-pa0-x243.google.com with SMTP id hb4so15922846pac.1 for ; Mon, 18 Apr 2016 03:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7S+F/c7JAjmQGMBX2ozDExbMjGeEeKCr7bW98PpMWKY=; b=T9gDp3/fwXZ/MD18OhoxsNDzYvacIElOk4L518hUWdNZxyWczfxXHuWu3Fj8SfHz7r GXyVVvOvzUGuOm5qHJnlT8CMrYuOMTTc1FwgGaCNoLeZa3xu/23Vmq8XjymLrf+W70qQ i8FGMJod225TkC18ERN5UnJTBp8nW9uxKkfOH++blMwbQGe9KtZlply/VKHiy8yRYxR3 pZ5WzwQCm2QQ1mr30Xn2g+zunDFivJ6CDk29LbBbNFgPwrX4ZVSoZDszN4maVhLgfQR8 XhaN1hdctQJF9V1UHIUiuXv/ptT3vCX5vS/mldhdINRf6j9RoFLPkvYUvz5FqPOWZbT1 6Tpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7S+F/c7JAjmQGMBX2ozDExbMjGeEeKCr7bW98PpMWKY=; b=U+xn35gOVMqlgIFh5D0JDNT+DWeJ6Qvlzivsfv0Oz+6uS2oGMqjCB/99ewZ9r6nkg1 /EZzuOy6RkmSFMxNFnkRDVtVw6WQQZkOjoTG/DetwUU6RAiCIYs3xVHn4KzXC8XffjyO PzBPErNbZwujD/2QhtbcboWOwdCCDzglBnWAHNBz84fea8M0A7zG4NtaBd4zDpAbC1qa Oz47YHoRJ+HYKjNzIEiq+LPcTLxexhbd8cD8FmBavMLxB/iw2nuTHVdcOz5vTbE51daq cDqcr+A0gtOvSoPTcmKJXeHDMg3X+g9fnYq8rGZ3QBUCMcJCdDYJd6EIx9iQfD6pKaTC DAYQ== X-Gm-Message-State: AOPr4FW0HcXh3KPMifnSG38+14z4cM7PqXM4Q37NjSrwnbqTABalf/Vw/K9cx+iWMKkS/Q== X-Received: by 10.67.14.98 with SMTP id ff2mr48511252pad.105.1460974055885; Mon, 18 Apr 2016 03:07:35 -0700 (PDT) Received: from [192.168.0.100] ([203.230.193.110]) by smtp.gmail.com with ESMTPSA id 6sm25388292pfx.68.2016.04.18.03.07.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Apr 2016 03:07:35 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Jong-Hyouk Lee In-Reply-To: <57149222.8090806@gmail.com> Date: Mon, 18 Apr 2016 19:07:31 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 10:07:39 -0000 Hi Alex Thx for your prompt message. Plz see inline. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 18, 2016, at 4:52 PM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 18/04/2016 09:32, Jong-Hyouk Lee a =C3=A9crit : >> Thx, plz see inline. >> -- >> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >> Protocol Engineering Lab., Sangmyung University >>=20 >> #email: jonghyouk@gmail.com >> #webpage: https://sites.google.com/site/hurryon >>=20 >>> On Apr 18, 2016, at 3:52 PM, Alexandre Petrescu >>> > >>> wrote: >>>=20 >>> Hi Jong-Hyouk, >>>=20 >>> Le 17/04/2016 14:07, Jong-Hyouk Lee a =C3=A9crit : >>>> Hi Alex >>>>=20 >>>> Just to clarify. -- Jong-Hyouk Lee, living somewhere between >>>> /dev/null and /dev/random Protocol Engineering Lab., Sangmyung >>>> University >>>>=20 >>>> #email: jonghyouk@gmail.com #webpage: >>>> https://sites.google.com/site/hurryon >>>>=20 >>>>> On Apr 14, 2016, at 5:42 PM, Alexandre Petrescu >>>>> wrote: >>>>>=20 >>>>> ITSers, >>>>>=20 >>>>> We work on a more rigorous ITS charter text. >>>>>=20 >>>>> Now we propose four work items: >>>>>=20 >>>>> 1. "Problem statement for IP in V2V and V2I" including "IP >>>>> addressing architecture for V2V and V2I" and including "Gap >>>>> Analysis: IP protocols suited and gaps" and including "Use-cases >>>>> for IP in V2V and V2I moving network to nearby moving or fixed >>>>> network=E2=80=9D >>>>=20 >>>> Are you intending to have one document that includes those three >>>> parts? >>>=20 >>> Yes. >>>=20 >>> Because we need to reduce the number of items. Because one of the >>> remarks during BoF was that the scope was too large. >>=20 >> Hum=E2=80=A6then, the document will be too broad. We may need people = to work on >> each part. >=20 > Yes. There are already a few drafts for this item. Their authors are = interested and agreed on joining some of the efforts. Which ones? Can you kindly give pointers? >=20 > Are you interested in some part of this big document? Sure, I am interested in this work. I suppose that the gap analysis part = is a good start point for us and for me as well. I am waiting for your = pointers to the exiting drafts relevant with this work item. If the = existing drafts are not covering yet the gap analysis, then I=E2=80=99ll = go for this. >=20 >>>>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>>>> context=E2=80=9D >>>>=20 >>>> Is this mean that this group first go for this and later considers = a >>>> general security document (e.g., security requirements for ITS) ? >>>=20 >>> For now it is "Threat Analysis for IP prefix exchanges in V2V and = V2I >>> context=E2=80=9D. >>=20 >> Ok. For the document =E2=80=9CThreat Analysis of IP prefix exchanges = in V2V and >> V2I=E2=80=9D, I just started to work on. Soon I will post. >=20 > I take it as agreement from you, and it will be in the proposed = charter text. Yes, plz. I will soon post.=20 >=20 >>> "General security requirements for ITS" seems very broad - what do = you >>> mean more precisely? >>=20 >> We may later need one document describing general security = requirements >> for ITS that corresponds the document =E2=80=9CPS for IP in V2V and = V2I=E2=80=9D. We >> will be later. ;) >=20 > Ok. >=20 > Alex >=20 >>=20 >> Good day! >>=20 >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Cheers. >>>>=20 >>>>>=20 >>>>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], >>>>> including connectivity in fast and asymmetric conditions, coverage >>>>> area vs speed diagrams, below-IP congestion management. >>>>>=20 >>>>> 4. "List of papers and _products_ using IP in V2V and V2I" >>>>>=20 >>>>> What do you think? >>>>>=20 >>>>> Please respond by next Monday, April 18th. >>>>>=20 >>>>> Alex and Dapeng [*] a typical IP-over-foo document is, for = example, >>>>> RFC2464 "Transmission of IPv6 Packets over Ethernet Networks", >>>>> where "foo" is instantiated as "Ethernet". Other IPv6-over-foo >>>>> documents are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" >>>>> and more. >>>>>=20 >>>>> Le 14/04/2016 09:42, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : >>>>>> Paul, >>>>>>=20 >>>>>> Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware = of IP V2V but >>>>>> not see the need (so far), I referred to the automotive SDOs (led >>>>>> by automotive industries)=E2=80=A6, although there are always = =E2=80=98minority >>>>>> reports=E2=80=99 J >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> J=C3=A9r=C3=B4me >>>>>>=20 >>>>>> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] >>>>>> *Sent:* Thursday 14 April 2016 09:36 *To:* J=C3=A9r=C3=B4me = H=C3=A4rri *Cc:* >>>>>> Alexandre Petrescu; its@ietf.org *Subject:* >>>>>> Re: [its] charter >>>>>> ITS >>>>>>=20 >>>>>> J=C3=A9r=C3=B4me, >>>>>>=20 >>>>>> I missed that you are also an academic person. >>>>>>=20 >>>>>> I got it :-) >>>>>>=20 >>>>>> I understand your points for industry activity related to >>>>>> vehicular networking. >>>>>>=20 >>>>>> Your observation seems true. >>>>>>=20 >>>>>> BTW, I will invite you to my team for the draft for a list of >>>>>> academic papers for V2V and V2I >>>>>>=20 >>>>>> by a personal message. >>>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>> Paul >>>>>>=20 >>>>>> On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri >>>>>> >>>>>> > >>>>>> wrote: >>>>>>=20 >>>>>> Hi Paul, >>>>>>=20 >>>>>> Thanks for your feedback. Do not get me wrong, I am an academic >>>>>> and with my team, we also work on IP-based V2V and V2I, in >>>>>> particular related to mobility management with DMM, but also in >>>>>> the context of vehicular IoT. >>>>>>=20 >>>>>> I just have the feeling that people are perfectly aware of the >>>>>> fact that IP _can_ be used for V2V and V2I, but does not = =E2=80=98_need_=E2=80=99 >>>>>> to be used as other solutions already perfectly fit their need. >>>>>> Listing papers will not change this awareness. >>>>>>=20 >>>>>> So, as a complement to academic papers, it would help to be able >>>>>> to pin-point which industrial activities are using or are >>>>>> strongly planning (short term I mean) to use pure IPv6 system in >>>>>> vehicles. >>>>>>=20 >>>>>> My feeling here is we have a different eco-system that the >>>>>> Automotive industry (and automotive industry-related SDO)..more >>>>>> likely the IoT industry=E2=80=A6and as such, we should not need = to have >>>>>> the (direct) involvement of automotive industry in the Charter. >>>>>> If we can make this clear by an industry-based =E2=80=98survey=E2=80= =99, that >>>>>> would help make the case for the WG. >>>>>>=20 >>>>>> Btw, you can count on me your draft..we can add some IP-based V2V >>>>>> and V2I for mobility management and also IoT. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> J=C3=A9r=C3=B4me >>>>>>=20 >>>>>> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com >>>>>> ] *Sent:* Thursday 14 April 2016 >>>>>> 03:22 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:* Alexandre Petrescu; = its@ietf.org >>>>>> >>>>>> *Subject:* Re: [its] charter ITS >>>>>>=20 >>>>>> Hi J=C3=A9r=C3=B4me, >>>>>>=20 >>>>>> I have an opinion on your comment 5) below. >>>>>>=20 >>>>>> I think that a list of high-quality papers about IP-based V2V and >>>>>> V2I >>>>>>=20 >>>>>> can teach very useful lessons to software designers of IP in V2V >>>>>> and V2I >>>>>>=20 >>>>>> in the industry. >>>>>>=20 >>>>>> Multiple people are working for this IP-based V2V and V2I >>>>>>=20 >>>>>> (including Sandra Cespedes and me) in academia and >>>>>>=20 >>>>>> more people(including Nabil Benamar) are willing to work for this >>>>>> area. >>>>>>=20 >>>>>> I think we need to utilize the list of such papers as the ground >>>>>> for our ITS group >>>>>>=20 >>>>>> through a WI. Note that the draft of the list will include the >>>>>> summary of the main >>>>>>=20 >>>>>> ideas of the papers. >>>>>>=20 >>>>>> For the industry current activities for this area, I believe that >>>>>> you can share them >>>>>>=20 >>>>>> as references through our ITS mailing list rather than through a >>>>>> WI. >>>>>>=20 >>>>>> Could you join my team that are making efforts for a list of such >>>>>> papers? >>>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>> Best Regards, >>>>>>=20 >>>>>> Paul >>>>>>=20 >>>>>> On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri >>>>>> >>>>>> > >>>>>> wrote: >>>>>>=20 >>>>>> Dear ITSers, Dear Alex, >>>>>>=20 >>>>>> Here are some comments on the updated charter: >>>>>>=20 >>>>>> 1)Can we keep a reference to IEEE 802.11p, considering it does >>>>>> not exist anymore? It is now fully integrated into IEEE >>>>>> 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of course. >>>>>>=20 >>>>>> 2)Should we really keep C-ACC (or Platooning) in the charter >>>>>> explicitly as use case, considering it is a seriously >>>>>> controversial aspect with some SDOs (ex. In Automotive SDOs)? In >>>>>> the ISO presentation, Thierry mentions traffic >>>>>> efficiency/infotainment applications, such as in-signage >>>>>> applications... >>>>>>=20 >>>>>> a.We might have to aim at less controversial use cases to >>>>>> attract automotive industries >>>>>>=20 >>>>>> 3)One potential WI I could think of (rather a basic one): >>>>>> _definition of a vehicular wireless =E2=80=98link=E2=80=99 in an = automotive >>>>>> context_ >>>>>>=20 >>>>>> a.To me, this is a fundamental brick in the larger IETF WG ITS >>>>>> house.. >>>>>>=20 >>>>>> 4)I would suggest to be more explicit in the foreseen challenges >>>>>> of this WG, instead of mentioning general use case (which end up >>>>>> be controversial) >>>>>>=20 >>>>>> a.Example: maintaining IPv6 connectivity in fast and asymmetric >>>>>> wireless links; also under quickly changing topologies (actually >>>>>> suggested by Dick Roy on the chat room) >>>>>>=20 >>>>>> b.Example: IPv6 addressing in link-local scope.. >>>>>>=20 >>>>>> c.Example: guaranteeing privacy in IPv6 moving networks etc.. >>>>>>=20 >>>>>> 5)Before listing academic papers referring to IPv6 in vehicles, I >>>>>> would suggest to first try to list commercial products/solutions >>>>>> that are in vehicles and are using IPv6, possibly suffering from >>>>>> a silo limitations (ex. restricted to a single technology, single >>>>>> use case=E2=80=A6) >>>>>>=20 >>>>>> a.I think we need to get to products first, before academic >>>>>> visions >>>>>>=20 >>>>>> My two cents.. >>>>>>=20 >>>>>> Best Regards, >>>>>>=20 >>>>>> J=C3=A9r=C3=B4me >>>>>>=20 >>>>>> *From:*its [mailto:its-bounces@ietf.org >>>>>> ] *On Behalf Of *Alexandre Petrescu >>>>>> *Sent:* Wednesday 06 April 2016 23:45 *To:* its@ietf.org >>>>>> >>>>>> *Subject:* [its] charter ITS >>>>>>=20 >>>>>> ITSers, >>>>>>=20 >>>>>> Please see below the current charter. >>>>>>=20 >>>>>> - the two Problem Statements drafts V2V and V2I joined, so there >>>>>> is less text in charter. - added an Item on "List of Research >>>>>> papers..." >>>>>>=20 >>>>>> Erik: did I understand you correctly that there should be some >>>>>> item on discussing whether link-local addressing is sufficient, >>>>>> whether prefix exchange is necessary? >>>>>>=20 >>>>>> Dino: should LISP be included in the gap analysis draft which >>>>>> includes C-ACC use-case? OR should we separate a dedicated I-D >>>>>> only with gap analysis including ND, MIP, AODVv2, LISP? >>>>>>=20 >>>>>> Person from mediatek: is the 'zeroconf' need in the >>>>>> vehicle-to-vehicle interface illustrated good enough by the words >>>>>> "moving network to nearby moving network communications"? Or is >>>>>> it better to say "the 1-IP-hop between nearby moving networks >>>>>> must be self-configured"? >>>>>>=20 >>>>>> Nabil, Sandra: is it ok to have a working group item "List of >>>>>> Research Papers for IP in V2V and V2I communications"? >>>>>>=20 >>>>>> Other comments? >>>>>>=20 >>>>>> Alex >>>>>>=20 >>>>>> = ------------------------------------------------------------------ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>> ITS (name to change) >>>>>> Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its >>>>>>=20 >>>>>>=20 >>>>>> Intelligent Transportation Systems (its) >>>>>> ---------------------------------------- Current Status: WG >>>>>> forming >>>>>>=20 >>>>>> Chairs: TBD >>>>>>=20 >>>>>> Assigned Area Director: TBD >>>>>>=20 >>>>>> Mailing list Address: its@ietf.org >>>>>> To >>>>>> Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: >>>>>> http://www.ietf.org/mail-archive/web/its/current/maillist.html >>>>>>=20 >>>>>> Additional web page TBD >>>>>>=20 >>>>>> Charter: >>>>>>=20 >>>>>> Goal ---- The goal of this group is to standardize IP-based >>>>>> protocols for establishing direct and secure connectivity between >>>>>> moving networks, some of which could be fixed permanently or >>>>>> temporarily. >>>>>>=20 >>>>>> Moving Network to Nearby Moving Network Communications >>>>>> ------------------------------------------------------ The group >>>>>> is concerned with all situations involving moving network to >>>>>> nearby moving network communications. For example: >>>>>> vehicle-to-vehicle communications, nomadic user wearing a PAN and >>>>>> communicating to a homenet, vehicle-to-infrastructure >>>>>> communications, wagon-to-wagon in a train, or >>>>>> train-to-intersection signalling. >>>>>>=20 >>>>>> Example from the automobile communications space >>>>>> ------------------------------------------------ Automobiles and >>>>>> vehicles of all types are increasingly connected to the Internet, >>>>>> either as vehicle-to-vehicle, vehicle-to-infra or >>>>>> vehicle-to-Internet. Entertainment apps enhancing comfort, >>>>>> reliable data exchanges for road safety, and automated driving >>>>>> are features coming in automobiles to hit the roads from now to >>>>>> year 2020. Highlighting increased safety as an immediate result >>>>>> of hyper-connectivity applied to vehicles, public authorities >>>>>> worldwide are increasingly mandating secure communication >>>>>> technology requirements in vehicles. >>>>>>=20 >>>>>> Emergency apps for new instrumented ambulances carry many >>>>>> benefits both to the users and to society in general. >>>>>>=20 >>>>>> Why IP? ------- Today, there are several deployed >>>>>> Vehicle-to-Internet technologies, including car tethering through >>>>>> driver's cellular smartphone. However, Vehicle-to-Vehicle and >>>>>> Vehicle-to-Infrastructure communications are still being >>>>>> developed. To improve on a situation of link-specific data >>>>>> exchanges, and enable independent application sets to share the >>>>>> same links, IP data exchanges are needed. Enabling IP >>>>>> communication between vehicles (V2V), and between vehicles and >>>>>> the immediate infrastructure (V2I), will provide (0) ability to >>>>>> reach the rest of the world on the Internet (1) short and >>>>>> deterministic delays, (2) fast forwarding through scalable paths >>>>>> of routers, (3) ease of reuse of existing Internet applications >>>>>> in a vehicular environment. >>>>>>=20 >>>>>> Moving network to nearby moving network communications involve >>>>>> link layers such as: 802.11p OCB (Outside the Context of a Basic >>>>>> Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible >>>>>> Light Communications), IrDA, LTE-D. Only the IP protocols are >>>>>> capable of running on each of these links and establish IP paths >>>>>> across them in an interoperable manner. >>>>>>=20 >>>>>> Scenarios? ---------- There are a few scenarios exhibiting the >>>>>> need to communicate from one moving network to another nearby >>>>>> moving network. >>>>>>=20 >>>>>> In the automobile space, the Cooperative Adaptive Cruise Control >>>>>> and Platooning features consider that vehicles close to each >>>>>> other exchange data describing their kinematic status. At the >>>>>> cross-roads, the moving network inside a vehicle exchanges data >>>>>> with the moving network in the red-light pole. >>>>>>=20 >>>>>> Several public safety scenarios involve moving networks. >>>>>> Distinct organizations deploy different moving networks >>>>>> (in-vehicle, on-person) at an incident scene. These networks >>>>>> need to interoperate in order to more effectively understand and >>>>>> deal with the incident scene. >>>>>>=20 >>>>>> In connected rail scenarios the moving network deployed in >>>>>> trains communicate with other moving networks at the >>>>>> cross-points. >>>>>>=20 >>>>>> What kind of solutions? ----------------------- The current >>>>>> technical solutions considered to achieve moving network to >>>>>> nearby moving network communications are of two kinds: IP >>>>>> routing protocols for n-hop path management and 1-hop link-scoped >>>>>> IP protocol enhancements. The 1-hop link-scoped protocols >>>>>> include the protocols for route establishment involving ICMP >>>>>> Router Advertisements. The n-hop path management protocols >>>>>> include n-hop path establishment protocols (e.g. Babel, OSPF) and >>>>>> n-hop path search protocols (most notably AODV and derivates). >>>>>>=20 >>>>>> In this proposed Working Group the focus is on 1-hop protocols, >>>>>> and leverage from other Working Groups for the n-hop situations. >>>>>>=20 >>>>>> In some of the moving network applications the window of >>>>>> opportunity for exchanging data with the immediate infrastructure >>>>>> may be very short. For example, a car driving near a road-side >>>>>> unit may have only 5s to exchange with that RSU (depending on >>>>>> speed, RSU range and number). (ephemeral connections). >>>>>>=20 >>>>>> What kind of requirements? -------------------------- The >>>>>> requirements for mechanisms for moving network to nearby moving >>>>>> network communications are focusing on low delays of the data >>>>>> paths, reduced number of messages for path establishment, >>>>>> application friendly, resilience to attacks, compatibility with >>>>>> DHCP and Mobile IP. >>>>>>=20 >>>>>> In addition, some moving network to nearby moving network >>>>>> applications involve IP multicast mechanisms (e.g. virtual >>>>>> siren); thus C-ACC the 1-hop IP moving network to nearby moving >>>>>> netowrk mechanisms will need to gracefully support IP multicast. >>>>>>=20 >>>>>> Due to the inherent characteristics of safety-related >>>>>> communications, all new moving network to nearby moving network >>>>>> mechanisms must afford authenticity and confidentiality where >>>>>> necessary. Dynamically establishing ephemeral communication >>>>>> paths between automobiles in public areas must offer privacy >>>>>> safeguards for the end users (passengers). >>>>>>=20 >>>>>> Establishing 1-hop IP V2V paths must not break the existing >>>>>> on-board protocols and applications which communicate with the >>>>>> Internet, possibly via multiple radios. >>>>>>=20 >>>>>> In a moving network deployed in an automobile, typically one >>>>>> exit point connects the moving network to other moving networks. >>>>>> However, in a more general manner (and to support reliability) >>>>>> any new mechanism of moving network to nearby moving network >>>>>> communications should support multi-homing: one router to use >>>>>> multiple interfaces towards outside the moving network, or >>>>>> multiple routers. >>>>>>=20 >>>>>> Current version of Internet protocols >>>>>> ------------------------------------- The group will only work on >>>>>> IPv6 solutions. >>>>>>=20 >>>>>> What SDOs may need this work? ----------------------------- The >>>>>> requirements and standards for moving network to nearby moving >>>>>> network communications, often involving IPv6, and novel V2V and >>>>>> V2Infra concepts, are developed mainly at ISO TC204 "Intelligent >>>>>> Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For >>>>>> Vehicle-to-Internet communications, 3GPP LTE and other cellular >>>>>> technologies represent the long-range connectivity method; for >>>>>> Vehicle-to-Vehicle communications, LTE Direct is currently >>>>>> specified, as well as OCB mode of IEEE 802.11. Several use-cases >>>>>> exhibit a need for IPv6 data exchanges between vehicles: ETSI's >>>>>> Cooperative Adaptive Cruise Control and Platooning. The IEEE >>>>>> developed a popular link for short-range communications - IEEE >>>>>> 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V >>>>>> communications. >>>>>>=20 >>>>>> Work Items ---------- - use-cases for moving network to nearby >>>>>> moving network communications - Problem Statement for moving >>>>>> network to nearby moving network communications including V2V, >>>>>> V2I and DNS. - Security and Privacy Requirements for moving >>>>>> network to nearby moving network communications - Solutions, >>>>>> which might include new protocols or extensions to existing >>>>>> protocols. With MIB. - IPv6-over foo, where foo is pertinent for >>>>>> moving network to nearby moving network communications (e.g. >>>>>> 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in >>>>>> the V2V domain, identifying which uses IP. >>>>>>=20 >>>>>> Timeline -------- - >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ its mailing list >>>>>> its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. >>>>>> Assistant Professor Department of Software Sungkyunkwan >>>>>> University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>>>>> , pauljeong@skku.edu >>>>>> Personal Homepage: >>>>>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>> >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. >>>>>> Assistant Professor Department of Software Sungkyunkwan >>>>>> University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>>>>> , pauljeong@skku.edu >>>>>> Personal Homepage: >>>>>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>> >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ its mailing list >>>>> its@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/its >>=20 From nobody Mon Apr 18 04:23:46 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA50312DD59 for ; Mon, 18 Apr 2016 04:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veZCHzz4b_NP for ; Mon, 18 Apr 2016 04:23:41 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B62112D782 for ; Mon, 18 Apr 2016 04:23:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3IBNbSN022527; Mon, 18 Apr 2016 13:23:37 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 90B9020A187; Mon, 18 Apr 2016 13:25:03 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 829E520123D; Mon, 18 Apr 2016 13:25:03 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3IBNb5g000808; Mon, 18 Apr 2016 13:23:37 +0200 To: Jong-Hyouk Lee References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> From: Alexandre Petrescu Message-ID: <5714C3B9.8030904@gmail.com> Date: Mon, 18 Apr 2016 13:23:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 11:23:45 -0000 Hi Jong-Hyouk, Le 18/04/2016 12:07, Jong-Hyouk Lee a écrit : > Hi Alex > > Thx for your prompt message. Plz see inline. -- Jong-Hyouk Lee, > living somewhere between /dev/null and /dev/random Protocol > Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com #webpage: > https://sites.google.com/site/hurryon > >> On Apr 18, 2016, at 4:52 PM, Alexandre Petrescu >> wrote: >> >> >> >> Le 18/04/2016 09:32, Jong-Hyouk Lee a écrit : >>> Thx, plz see inline. -- Jong-Hyouk Lee, living somewhere between >>> /dev/null and /dev/random Protocol Engineering Lab., Sangmyung >>> University >>> >>> #email: jonghyouk@gmail.com >>> #webpage: https://sites.google.com/site/hurryon >>> >>>> On Apr 18, 2016, at 3:52 PM, Alexandre Petrescu >>>> >>> > wrote: >>>> >>>> Hi Jong-Hyouk, >>>> >>>> Le 17/04/2016 14:07, Jong-Hyouk Lee a écrit : >>>>> Hi Alex >>>>> >>>>> Just to clarify. -- Jong-Hyouk Lee, living somewhere between >>>>> /dev/null and /dev/random Protocol Engineering Lab., >>>>> Sangmyung University >>>>> >>>>> #email: jonghyouk@gmail.com >>>>> #webpage: https://sites.google.com/site/hurryon >>>>> >>>>>> On Apr 14, 2016, at 5:42 PM, Alexandre Petrescu >>>>>> wrote: >>>>>> >>>>>> ITSers, >>>>>> >>>>>> We work on a more rigorous ITS charter text. >>>>>> >>>>>> Now we propose four work items: >>>>>> >>>>>> 1. "Problem statement for IP in V2V and V2I" including "IP >>>>>> addressing architecture for V2V and V2I" and including >>>>>> "Gap Analysis: IP protocols suited and gaps" and including >>>>>> "Use-cases for IP in V2V and V2I moving network to nearby >>>>>> moving or fixed network” >>>>> >>>>> Are you intending to have one document that includes those >>>>> three parts? >>>> >>>> Yes. >>>> >>>> Because we need to reduce the number of items. Because one of >>>> the remarks during BoF was that the scope was too large. >>> >>> Hum…then, the document will be too broad. We may need people to >>> work on each part. >> >> Yes. There are already a few drafts for this item. Their authors >> are interested and agreed on joining some of the efforts. > > Which ones? Can you kindly give pointers? There are two Problem Statements, one for V2V and one for V2I: draft-petrescu-its-problem-01.txt draft-jeong-its-v2i-problem-statement-00 Their authors agreed to join. There is a section titled 'Gap Analysis' in: draft-petrescu-its-cacc-sdo-04.txt We could extract that section. There is some useful text that can be used for 'use-cases for IP in V2V and V2I moving network to nearby moving or fixed network': draft-liu-its-scenario-00 draft-petrescu-its-cacc-sdo-04.txt I expect authors to agree. If that is not enough, we can ask members of the ITS at IETF email list whether they can write use-case text for this latter part. The use-case is any use-case that makes use of the following topology: Vehicle 1 Vehicle 2 e.g. o)) LTE D2D, ((o | 802.11p, | | LiFi | | | +------+ +--+--+ +--+--+ +----------+ |GPS PC| | eR1 | | eR2 | |Braking PC| +--+---+ +--+--+ +--+--+ +-----+----+ | | | | | | | | | Ethernet | | Ethernet | -+-----------------+- ---+--------------+----- 2001:db8:1::/40 2001:db8:2::/40 >> Are you interested in some part of this big document? > > Sure, I am interested in this work. I suppose that the gap analysis > part is a good start point for us and for me as well. I am waiting > for your pointers to the exiting drafts relevant with this work item. > If the existing drafts are not covering yet the gap analysis, then > I’ll go for this. Look at the gap analysis: https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-04#section-14 Alex > >> >>>>>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>>>>> context” >>>>> >>>>> Is this mean that this group first go for this and later >>>>> considers a general security document (e.g., security >>>>> requirements for ITS) ? >>>> >>>> For now it is "Threat Analysis for IP prefix exchanges in V2V >>>> and V2I context”. >>> >>> Ok. For the document “Threat Analysis of IP prefix exchanges in >>> V2V and V2I”, I just started to work on. Soon I will post. >> >> I take it as agreement from you, and it will be in the proposed >> charter text. > > Yes, plz. I will soon post. > >> >>>> "General security requirements for ITS" seems very broad - what >>>> do you mean more precisely? >>> >>> We may later need one document describing general security >>> requirements for ITS that corresponds the document “PS for IP in >>> V2V and V2I”. We will be later. ;) >> >> Ok. >> >> Alex >> >>> >>> Good day! >>> >>>> >>>> Alex >>>> >>>>> >>>>> Cheers. >>>>> >>>>>> >>>>>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo >>>>>> document[*], including connectivity in fast and asymmetric >>>>>> conditions, coverage area vs speed diagrams, below-IP >>>>>> congestion management. >>>>>> >>>>>> 4. "List of papers and _products_ using IP in V2V and V2I" >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Please respond by next Monday, April 18th. >>>>>> >>>>>> Alex and Dapeng [*] a typical IP-over-foo document is, for >>>>>> example, RFC2464 "Transmission of IPv6 Packets over >>>>>> Ethernet Networks", where "foo" is instantiated as >>>>>> "Ethernet". Other IPv6-over-foo documents are RFC4944 >>>>>> "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and more. >>>>>> >>>>>> Le 14/04/2016 09:42, Jérôme Härri a écrit : >>>>>>> Paul, >>>>>>> >>>>>>> Thanks. Btw, when I mentioned ‘people’ are aware of IP >>>>>>> V2V but not see the need (so far), I referred to the >>>>>>> automotive SDOs (led by automotive industries)…, although >>>>>>> there are always ‘minority reports’ J >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Jérôme >>>>>>> >>>>>>> *From:*Mr. Jaehoon Paul Jeong >>>>>>> [mailto:jaehoon.paul@gmail.com] *Sent:* Thursday 14 April >>>>>>> 2016 09:36 *To:* Jérôme Härri *Cc:* Alexandre Petrescu; >>>>>>> its@ietf.org *Subject:* Re: [its] >>>>>>> charter ITS >>>>>>> >>>>>>> Jérôme, >>>>>>> >>>>>>> I missed that you are also an academic person. >>>>>>> >>>>>>> I got it :-) >>>>>>> >>>>>>> I understand your points for industry activity related >>>>>>> to vehicular networking. >>>>>>> >>>>>>> Your observation seems true. >>>>>>> >>>>>>> BTW, I will invite you to my team for the draft for a >>>>>>> list of academic papers for V2V and V2I >>>>>>> >>>>>>> by a personal message. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> On Thu, Apr 14, 2016 at 4:09 PM, Jérôme Härri >>>>>>> >>>>>> >>>>>>> > wrote: >>>>>>> >>>>>>> Hi Paul, >>>>>>> >>>>>>> Thanks for your feedback. Do not get me wrong, I am an >>>>>>> academic and with my team, we also work on IP-based V2V >>>>>>> and V2I, in particular related to mobility management >>>>>>> with DMM, but also in the context of vehicular IoT. >>>>>>> >>>>>>> I just have the feeling that people are perfectly aware >>>>>>> of the fact that IP _can_ be used for V2V and V2I, but >>>>>>> does not ‘_need_’ to be used as other solutions already >>>>>>> perfectly fit their need. Listing papers will not change >>>>>>> this awareness. >>>>>>> >>>>>>> So, as a complement to academic papers, it would help to >>>>>>> be able to pin-point which industrial activities are >>>>>>> using or are strongly planning (short term I mean) to use >>>>>>> pure IPv6 system in vehicles. >>>>>>> >>>>>>> My feeling here is we have a different eco-system that >>>>>>> the Automotive industry (and automotive industry-related >>>>>>> SDO)..more likely the IoT industry…and as such, we should >>>>>>> not need to have the (direct) involvement of automotive >>>>>>> industry in the Charter. If we can make this clear by an >>>>>>> industry-based ‘survey’, that would help make the case >>>>>>> for the WG. >>>>>>> >>>>>>> Btw, you can count on me your draft..we can add some >>>>>>> IP-based V2V and V2I for mobility management and also >>>>>>> IoT. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Jérôme >>>>>>> >>>>>>> *From:*Mr. Jaehoon Paul Jeong >>>>>>> [mailto:jaehoon.paul@gmail.com >>>>>>> ] *Sent:* Thursday 14 >>>>>>> April 2016 03:22 *To:* Jérôme Härri *Cc:* Alexandre >>>>>>> Petrescu; its@ietf.org >>>>>>> *Subject:* Re: [its] charter ITS >>>>>>> >>>>>>> Hi Jérôme, >>>>>>> >>>>>>> I have an opinion on your comment 5) below. >>>>>>> >>>>>>> I think that a list of high-quality papers about IP-based >>>>>>> V2V and V2I >>>>>>> >>>>>>> can teach very useful lessons to software designers of IP >>>>>>> in V2V and V2I >>>>>>> >>>>>>> in the industry. >>>>>>> >>>>>>> Multiple people are working for this IP-based V2V and >>>>>>> V2I >>>>>>> >>>>>>> (including Sandra Cespedes and me) in academia and >>>>>>> >>>>>>> more people(including Nabil Benamar) are willing to work >>>>>>> for this area. >>>>>>> >>>>>>> I think we need to utilize the list of such papers as the >>>>>>> ground for our ITS group >>>>>>> >>>>>>> through a WI. Note that the draft of the list will >>>>>>> include the summary of the main >>>>>>> >>>>>>> ideas of the papers. >>>>>>> >>>>>>> For the industry current activities for this area, I >>>>>>> believe that you can share them >>>>>>> >>>>>>> as references through our ITS mailing list rather than >>>>>>> through a WI. >>>>>>> >>>>>>> Could you join my team that are making efforts for a list >>>>>>> of such papers? >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> On Thu, Apr 7, 2016 at 8:11 AM, Jérôme Härri >>>>>>> >>>>>> >>>>>>> > wrote: >>>>>>> >>>>>>> Dear ITSers, Dear Alex, >>>>>>> >>>>>>> Here are some comments on the updated charter: >>>>>>> >>>>>>> 1)Can we keep a reference to IEEE 802.11p, considering it >>>>>>> does not exist anymore? It is now fully integrated into >>>>>>> IEEE 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of >>>>>>> course. >>>>>>> >>>>>>> 2)Should we really keep C-ACC (or Platooning) in the >>>>>>> charter explicitly as use case, considering it is a >>>>>>> seriously controversial aspect with some SDOs (ex. In >>>>>>> Automotive SDOs)? In the ISO presentation, Thierry >>>>>>> mentions traffic efficiency/infotainment applications, >>>>>>> such as in-signage applications... >>>>>>> >>>>>>> a.We might have to aim at less controversial use cases >>>>>>> to attract automotive industries >>>>>>> >>>>>>> 3)One potential WI I could think of (rather a basic >>>>>>> one): _definition of a vehicular wireless ‘link’ in an >>>>>>> automotive context_ >>>>>>> >>>>>>> a.To me, this is a fundamental brick in the larger IETF >>>>>>> WG ITS house.. >>>>>>> >>>>>>> 4)I would suggest to be more explicit in the foreseen >>>>>>> challenges of this WG, instead of mentioning general use >>>>>>> case (which end up be controversial) >>>>>>> >>>>>>> a.Example: maintaining IPv6 connectivity in fast and >>>>>>> asymmetric wireless links; also under quickly changing >>>>>>> topologies (actually suggested by Dick Roy on the chat >>>>>>> room) >>>>>>> >>>>>>> b.Example: IPv6 addressing in link-local scope.. >>>>>>> >>>>>>> c.Example: guaranteeing privacy in IPv6 moving networks >>>>>>> etc.. >>>>>>> >>>>>>> 5)Before listing academic papers referring to IPv6 in >>>>>>> vehicles, I would suggest to first try to list commercial >>>>>>> products/solutions that are in vehicles and are using >>>>>>> IPv6, possibly suffering from a silo limitations (ex. >>>>>>> restricted to a single technology, single use case…) >>>>>>> >>>>>>> a.I think we need to get to products first, before >>>>>>> academic visions >>>>>>> >>>>>>> My two cents.. >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Jérôme >>>>>>> >>>>>>> *From:*its [mailto:its-bounces@ietf.org >>>>>>> ] *On Behalf Of *Alexandre >>>>>>> Petrescu *Sent:* Wednesday 06 April 2016 23:45 *To:* >>>>>>> its@ietf.org >>>>>>> *Subject:* [its] charter ITS >>>>>>> >>>>>>> ITSers, >>>>>>> >>>>>>> Please see below the current charter. >>>>>>> >>>>>>> - the two Problem Statements drafts V2V and V2I joined, >>>>>>> so there is less text in charter. - added an Item on >>>>>>> "List of Research papers..." >>>>>>> >>>>>>> Erik: did I understand you correctly that there should be >>>>>>> some item on discussing whether link-local addressing is >>>>>>> sufficient, whether prefix exchange is necessary? >>>>>>> >>>>>>> Dino: should LISP be included in the gap analysis draft >>>>>>> which includes C-ACC use-case? OR should we separate a >>>>>>> dedicated I-D only with gap analysis including ND, MIP, >>>>>>> AODVv2, LISP? >>>>>>> >>>>>>> Person from mediatek: is the 'zeroconf' need in the >>>>>>> vehicle-to-vehicle interface illustrated good enough by >>>>>>> the words "moving network to nearby moving network >>>>>>> communications"? Or is it better to say "the 1-IP-hop >>>>>>> between nearby moving networks must be self-configured"? >>>>>>> >>>>>>> Nabil, Sandra: is it ok to have a working group item >>>>>>> "List of Research Papers for IP in V2V and V2I >>>>>>> communications"? >>>>>>> >>>>>>> Other comments? >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> ------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>> >>>>>>> ITS (name to change) >>>>>>> Charter April 6th, 2016 >>>>>>> http://ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> Intelligent Transportation Systems (its) >>>>>>> ---------------------------------------- Current Status: >>>>>>> WG forming >>>>>>> >>>>>>> Chairs: TBD >>>>>>> >>>>>>> Assigned Area Director: TBD >>>>>>> >>>>>>> Mailing list Address: its@ietf.org >>>>>>> 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: >>>>>>> >>>>>>> Goal ---- The goal of this group is to standardize >>>>>>> IP-based protocols for establishing direct and secure >>>>>>> connectivity between moving networks, some of which could >>>>>>> be fixed permanently or temporarily. >>>>>>> >>>>>>> Moving Network to Nearby Moving Network Communications >>>>>>> ------------------------------------------------------ >>>>>>> The group is concerned with all situations involving >>>>>>> moving network to nearby moving network communications. >>>>>>> For example: vehicle-to-vehicle communications, nomadic >>>>>>> user wearing a PAN and communicating to a homenet, >>>>>>> vehicle-to-infrastructure communications, wagon-to-wagon >>>>>>> in a train, or train-to-intersection signalling. >>>>>>> >>>>>>> Example from the automobile communications space >>>>>>> ------------------------------------------------ >>>>>>> Automobiles and vehicles of all types are increasingly >>>>>>> connected to the Internet, either as vehicle-to-vehicle, >>>>>>> vehicle-to-infra or vehicle-to-Internet. Entertainment >>>>>>> apps enhancing comfort, reliable data exchanges for road >>>>>>> safety, and automated driving are features coming in >>>>>>> automobiles to hit the roads from now to year 2020. >>>>>>> Highlighting increased safety as an immediate result of >>>>>>> hyper-connectivity applied to vehicles, public >>>>>>> authorities worldwide are increasingly mandating secure >>>>>>> communication technology requirements in vehicles. >>>>>>> >>>>>>> Emergency apps for new instrumented ambulances carry >>>>>>> many benefits both to the users and to society in >>>>>>> general. >>>>>>> >>>>>>> Why IP? ------- Today, there are several deployed >>>>>>> Vehicle-to-Internet technologies, including car tethering >>>>>>> through driver's cellular smartphone. However, >>>>>>> Vehicle-to-Vehicle and Vehicle-to-Infrastructure >>>>>>> communications are still being developed. To improve on >>>>>>> a situation of link-specific data exchanges, and enable >>>>>>> independent application sets to share the same links, IP >>>>>>> data exchanges are needed. Enabling IP communication >>>>>>> between vehicles (V2V), and between vehicles and the >>>>>>> immediate infrastructure (V2I), will provide (0) ability >>>>>>> to reach the rest of the world on the Internet (1) short >>>>>>> and deterministic delays, (2) fast forwarding through >>>>>>> scalable paths of routers, (3) ease of reuse of existing >>>>>>> Internet applications in a vehicular environment. >>>>>>> >>>>>>> Moving network to nearby moving network communications >>>>>>> involve link layers such as: 802.11p OCB (Outside the >>>>>>> Context of a Basic Service Set), 802.15.4 with 6lowpan, >>>>>>> 802.11ac, VLC (Visible Light Communications), IrDA, >>>>>>> LTE-D. Only the IP protocols are capable of running on >>>>>>> each of these links and establish IP paths across them in >>>>>>> an interoperable manner. >>>>>>> >>>>>>> Scenarios? ---------- There are a few scenarios >>>>>>> exhibiting the need to communicate from one moving >>>>>>> network to another nearby moving network. >>>>>>> >>>>>>> In the automobile space, the Cooperative Adaptive Cruise >>>>>>> Control and Platooning features consider that vehicles >>>>>>> close to each other exchange data describing their >>>>>>> kinematic status. At the cross-roads, the moving network >>>>>>> inside a vehicle exchanges data with the moving network >>>>>>> in the red-light pole. >>>>>>> >>>>>>> Several public safety scenarios involve moving networks. >>>>>>> Distinct organizations deploy different moving networks >>>>>>> (in-vehicle, on-person) at an incident scene. These >>>>>>> networks need to interoperate in order to more >>>>>>> effectively understand and deal with the incident scene. >>>>>>> >>>>>>> In connected rail scenarios the moving network deployed >>>>>>> in trains communicate with other moving networks at the >>>>>>> cross-points. >>>>>>> >>>>>>> What kind of solutions? ----------------------- The >>>>>>> current technical solutions considered to achieve moving >>>>>>> network to nearby moving network communications are of >>>>>>> two kinds: IP routing protocols for n-hop path management >>>>>>> and 1-hop link-scoped IP protocol enhancements. The >>>>>>> 1-hop link-scoped protocols include the protocols for >>>>>>> route establishment involving ICMP Router Advertisements. >>>>>>> The n-hop path management protocols include n-hop path >>>>>>> establishment protocols (e.g. Babel, OSPF) and n-hop path >>>>>>> search protocols (most notably AODV and derivates). >>>>>>> >>>>>>> In this proposed Working Group the focus is on 1-hop >>>>>>> protocols, and leverage from other Working Groups for the >>>>>>> n-hop situations. >>>>>>> >>>>>>> In some of the moving network applications the window of >>>>>>> opportunity for exchanging data with the immediate >>>>>>> infrastructure may be very short. For example, a car >>>>>>> driving near a road-side unit may have only 5s to >>>>>>> exchange with that RSU (depending on speed, RSU range and >>>>>>> number). (ephemeral connections). >>>>>>> >>>>>>> What kind of requirements? -------------------------- >>>>>>> The requirements for mechanisms for moving network to >>>>>>> nearby moving network communications are focusing on low >>>>>>> delays of the data paths, reduced number of messages for >>>>>>> path establishment, application friendly, resilience to >>>>>>> attacks, compatibility with DHCP and Mobile IP. >>>>>>> >>>>>>> In addition, some moving network to nearby moving >>>>>>> network applications involve IP multicast mechanisms >>>>>>> (e.g. virtual siren); thus C-ACC the 1-hop IP moving >>>>>>> network to nearby moving netowrk mechanisms will need to >>>>>>> gracefully support IP multicast. >>>>>>> >>>>>>> Due to the inherent characteristics of safety-related >>>>>>> communications, all new moving network to nearby moving >>>>>>> network mechanisms must afford authenticity and >>>>>>> confidentiality where necessary. Dynamically >>>>>>> establishing ephemeral communication paths between >>>>>>> automobiles in public areas must offer privacy safeguards >>>>>>> for the end users (passengers). >>>>>>> >>>>>>> Establishing 1-hop IP V2V paths must not break the >>>>>>> existing on-board protocols and applications which >>>>>>> communicate with the Internet, possibly via multiple >>>>>>> radios. >>>>>>> >>>>>>> In a moving network deployed in an automobile, typically >>>>>>> one exit point connects the moving network to other >>>>>>> moving networks. However, in a more general manner (and >>>>>>> to support reliability) any new mechanism of moving >>>>>>> network to nearby moving network communications should >>>>>>> support multi-homing: one router to use multiple >>>>>>> interfaces towards outside the moving network, or >>>>>>> multiple routers. >>>>>>> >>>>>>> Current version of Internet protocols >>>>>>> ------------------------------------- The group will only >>>>>>> work on IPv6 solutions. >>>>>>> >>>>>>> What SDOs may need this work? >>>>>>> ----------------------------- The requirements and >>>>>>> standards for moving network to nearby moving network >>>>>>> communications, often involving IPv6, and novel V2V and >>>>>>> V2Infra concepts, are developed mainly at ISO TC204 >>>>>>> "Intelligent Transport Systems", 3GPP, ETSI, NHTSA and >>>>>>> IEEE. For Vehicle-to-Internet communications, 3GPP LTE >>>>>>> and other cellular technologies represent the long-range >>>>>>> connectivity method; for Vehicle-to-Vehicle >>>>>>> communications, LTE Direct is currently specified, as >>>>>>> well as OCB mode of IEEE 802.11. Several use-cases >>>>>>> exhibit a need for IPv6 data exchanges between vehicles: >>>>>>> ETSI's Cooperative Adaptive Cruise Control and >>>>>>> Platooning. The IEEE developed a popular link for >>>>>>> short-range communications - IEEE 802.11p "WAVE". The >>>>>>> NHTSA wrote a set of requirements for V2V >>>>>>> communications. >>>>>>> >>>>>>> Work Items ---------- - use-cases for moving network to >>>>>>> nearby moving network communications - Problem Statement >>>>>>> for moving network to nearby moving network >>>>>>> communications including V2V, V2I and DNS. - Security and >>>>>>> Privacy Requirements for moving network to nearby moving >>>>>>> network communications - Solutions, which might include >>>>>>> new protocols or extensions to existing protocols. With >>>>>>> MIB. - IPv6-over foo, where foo is pertinent for moving >>>>>>> network to nearby moving network communications (e.g. >>>>>>> 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research >>>>>>> Papers in the V2V domain, identifying which uses IP. >>>>>>> >>>>>>> Timeline -------- - >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> =========================== Mr. Jaehoon (Paul) Jeong, >>>>>>> Ph.D. Assistant Professor Department of Software >>>>>>> Sungkyunkwan University Office: +82-31-299-4957 Email: >>>>>>> jaehoon.paul@gmail.com , >>>>>>> pauljeong@skku.edu Personal >>>>>>> Homepage: >>>>>>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> =========================== Mr. Jaehoon (Paul) Jeong, >>>>>>> Ph.D. Assistant Professor Department of Software >>>>>>> Sungkyunkwan University Office: +82-31-299-4957 Email: >>>>>>> jaehoon.paul@gmail.com , >>>>>>> pauljeong@skku.edu Personal >>>>>>> Homepage: >>>>>>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>> > > From nobody Mon Apr 18 04:39:39 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5539612D526 for ; Mon, 18 Apr 2016 04:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOwy_Q2cKezW for ; Mon, 18 Apr 2016 04:39:25 -0700 (PDT) Received: from mail-pa0-x242.google.com (mail-pa0-x242.google.com [IPv6:2607:f8b0:400e:c03::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23ECB12B055 for ; Mon, 18 Apr 2016 04:39:25 -0700 (PDT) Received: by mail-pa0-x242.google.com with SMTP id vv3so16049273pab.0 for ; Mon, 18 Apr 2016 04:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=03marZqmhJv3EabPa0DLL41PdZOZrr9LRqsnPBbvY5I=; b=P9ucKU8SeM9p8CmXpSyF3QPDfloxozRyHTqdhRN8pkH0aDznqxNT7ig2AyKgWdA4JN U5jm9t2tekfoQ9F1TtlryDdPyP0QH1lFhAAQnTnQ9ckbg4gaidg62pradeh1jmV66/Tv npGAuxXG3Ir3dZYuHtUwR8zbPLX1xlf3VCtAmKUZmSnX9Vrio273vvANSXOnIO2OxUeX vLoGQv1xxdR/Pv8Fd5iBSDQAiLSOY4cF/Rj6lTU8/U5SbpzAe9mLgr/x38/e7Z5ygLvY rpkmWh7sdJ69OVKG/v/BbKdo1olsrNIVMA9REPkXQ70T61RJBNC/wBoObfWMXvBCifGx 680A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=03marZqmhJv3EabPa0DLL41PdZOZrr9LRqsnPBbvY5I=; b=YnpE3aHghxd/aQoxD3Bo4rFFIVL7cAUmjVYhg/kk2v3wl8lzBxlH4yNrcvVZupqn4y IvQWZ/JQYTx2wcg48hU7JQ1t0mdboSrNeEVwebnLb5J6bHo7ZoUlZpKoIEDbTABYlFgJ 5uTMbBv32+1UATQls+MiumPTRKH9PEFlgRmoJLmhPROrZkB4U1SdqgH+t6o55jcbaYXc jLLmfMHhE9vHp8QEUK9xeZqjoqtZoGwMbvRR/R3o02D/z2T8M7SbClPt123S8KNo8Cma Vswr/KkgbEY2RA+rWEl1olXE8QaZ11DSkDErySLzUKlKUIDqBpmFDfCyjKS9IEN0/Y+9 z43Q== X-Gm-Message-State: AOPr4FVH9edaPAKJWD9lQ8nz0FrlFdTi/QixEFTP21PUar4Z6FaITNAA9MTxs5fbj5zwOQ== X-Received: by 10.66.231.98 with SMTP id tf2mr12545268pac.56.1460979564631; Mon, 18 Apr 2016 04:39:24 -0700 (PDT) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id kl14sm83430292pab.23.2016.04.18.04.39.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Apr 2016 04:39:23 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_1A23261A-9F45-4D12-9C53-E1B4B4A14C5D" From: Jong-Hyouk Lee In-Reply-To: <5714C3B9.8030904@gmail.com> Date: Mon, 18 Apr 2016 20:39:19 +0900 Message-Id: <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 11:39:38 -0000 --Apple-Mail=_1A23261A-9F45-4D12-9C53-E1B4B4A14C5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Super!=20 Let me work on the gap analysis. Soon I will post this.=20 Cheers! -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 18, 2016, at 8:23 PM, Alexandre Petrescu = wrote: >=20 > Hi Jong-Hyouk, >=20 > Le 18/04/2016 12:07, Jong-Hyouk Lee a =C3=A9crit : >> Hi Alex >>=20 >> Thx for your prompt message. Plz see inline. -- Jong-Hyouk Lee, >> living somewhere between /dev/null and /dev/random Protocol >> Engineering Lab., Sangmyung University >>=20 >> #email: jonghyouk@gmail.com #webpage: >> https://sites.google.com/site/hurryon >>=20 >>> On Apr 18, 2016, at 4:52 PM, Alexandre Petrescu >>> wrote: >>>=20 >>>=20 >>>=20 >>> Le 18/04/2016 09:32, Jong-Hyouk Lee a =C3=A9crit : >>>> Thx, plz see inline. -- Jong-Hyouk Lee, living somewhere between >>>> /dev/null and /dev/random Protocol Engineering Lab., Sangmyung >>>> University >>>>=20 >>>> #email: jonghyouk@gmail.com >>>> #webpage: https://sites.google.com/site/hurryon >>>>=20 >>>>> On Apr 18, 2016, at 3:52 PM, Alexandre Petrescu >>>>> >>>> > wrote: >>>>>=20 >>>>> Hi Jong-Hyouk, >>>>>=20 >>>>> Le 17/04/2016 14:07, Jong-Hyouk Lee a =C3=A9crit : >>>>>> Hi Alex >>>>>>=20 >>>>>> Just to clarify. -- Jong-Hyouk Lee, living somewhere between >>>>>> /dev/null and /dev/random Protocol Engineering Lab., >>>>>> Sangmyung University >>>>>>=20 >>>>>> #email: jonghyouk@gmail.com >>>>>> #webpage: https://sites.google.com/site/hurryon >>>>>>=20 >>>>>>> On Apr 14, 2016, at 5:42 PM, Alexandre Petrescu >>>>>>> wrote: >>>>>>>=20 >>>>>>> ITSers, >>>>>>>=20 >>>>>>> We work on a more rigorous ITS charter text. >>>>>>>=20 >>>>>>> Now we propose four work items: >>>>>>>=20 >>>>>>> 1. "Problem statement for IP in V2V and V2I" including "IP >>>>>>> addressing architecture for V2V and V2I" and including >>>>>>> "Gap Analysis: IP protocols suited and gaps" and including >>>>>>> "Use-cases for IP in V2V and V2I moving network to nearby >>>>>>> moving or fixed network=E2=80=9D >>>>>>=20 >>>>>> Are you intending to have one document that includes those >>>>>> three parts? >>>>>=20 >>>>> Yes. >>>>>=20 >>>>> Because we need to reduce the number of items. Because one of >>>>> the remarks during BoF was that the scope was too large. >>>>=20 >>>> Hum=E2=80=A6then, the document will be too broad. We may need = people to >>>> work on each part. >>>=20 >>> Yes. There are already a few drafts for this item. Their authors >>> are interested and agreed on joining some of the efforts. >>=20 >> Which ones? Can you kindly give pointers? >=20 > There are two Problem Statements, one for V2V and one for V2I: > draft-petrescu-its-problem-01.txt > draft-jeong-its-v2i-problem-statement-00 > Their authors agreed to join. >=20 > There is a section titled 'Gap Analysis' in: > draft-petrescu-its-cacc-sdo-04.txt > We could extract that section. >=20 > There is some useful text that can be used for 'use-cases for IP in = V2V and V2I moving network to nearby moving or fixed network': > draft-liu-its-scenario-00 > draft-petrescu-its-cacc-sdo-04.txt > I expect authors to agree. >=20 > If that is not enough, we can ask members of the ITS at IETF email = list whether they can write use-case text for this latter part. >=20 > The use-case is any use-case that makes use of the following topology: >=20 >=20 > Vehicle 1 Vehicle 2 > e.g. > o)) LTE D2D, ((o > | 802.11p, | > | LiFi | > | | > +------+ +--+--+ +--+--+ +----------+ > |GPS PC| | eR1 | | eR2 | |Braking PC| > +--+---+ +--+--+ +--+--+ +-----+----+ > | | | | > | | | | > | Ethernet | | Ethernet | > -+-----------------+- ---+--------------+----- > 2001:db8:1::/40 2001:db8:2::/40 >=20 >=20 >>> Are you interested in some part of this big document? >>=20 >> Sure, I am interested in this work. I suppose that the gap analysis >> part is a good start point for us and for me as well. I am waiting >> for your pointers to the exiting drafts relevant with this work item. >> If the existing drafts are not covering yet the gap analysis, then >> I=E2=80=99ll go for this. >=20 > Look at the gap analysis: > https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-04#section-14 = >=20 > Alex >=20 >>=20 >>>=20 >>>>>>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>>>>>> context=E2=80=9D >>>>>>=20 >>>>>> Is this mean that this group first go for this and later >>>>>> considers a general security document (e.g., security >>>>>> requirements for ITS) ? >>>>>=20 >>>>> For now it is "Threat Analysis for IP prefix exchanges in V2V >>>>> and V2I context=E2=80=9D. >>>>=20 >>>> Ok. For the document =E2=80=9CThreat Analysis of IP prefix = exchanges in >>>> V2V and V2I=E2=80=9D, I just started to work on. Soon I will post. >>>=20 >>> I take it as agreement from you, and it will be in the proposed >>> charter text. >>=20 >> Yes, plz. I will soon post. >>=20 >>>=20 >>>>> "General security requirements for ITS" seems very broad - what >>>>> do you mean more precisely? >>>>=20 >>>> We may later need one document describing general security >>>> requirements for ITS that corresponds the document =E2=80=9CPS for = IP in >>>> V2V and V2I=E2=80=9D. We will be later. ;) >>>=20 >>> Ok. >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Good day! >>>>=20 >>>>>=20 >>>>> Alex >>>>>=20 >>>>>>=20 >>>>>> Cheers. >>>>>>=20 >>>>>>>=20 >>>>>>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo >>>>>>> document[*], including connectivity in fast and asymmetric >>>>>>> conditions, coverage area vs speed diagrams, below-IP >>>>>>> congestion management. >>>>>>>=20 >>>>>>> 4. "List of papers and _products_ using IP in V2V and V2I" >>>>>>>=20 >>>>>>> What do you think? >>>>>>>=20 >>>>>>> Please respond by next Monday, April 18th. >>>>>>>=20 >>>>>>> Alex and Dapeng [*] a typical IP-over-foo document is, for >>>>>>> example, RFC2464 "Transmission of IPv6 Packets over >>>>>>> Ethernet Networks", where "foo" is instantiated as >>>>>>> "Ethernet". Other IPv6-over-foo documents are RFC4944 >>>>>>> "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and more. >>>>>>>=20 >>>>>>> Le 14/04/2016 09:42, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : >>>>>>>> Paul, >>>>>>>>=20 >>>>>>>> Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are = aware of IP >>>>>>>> V2V but not see the need (so far), I referred to the >>>>>>>> automotive SDOs (led by automotive industries)=E2=80=A6, = although >>>>>>>> there are always =E2=80=98minority reports=E2=80=99 J >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>> J=C3=A9r=C3=B4me >>>>>>>>=20 >>>>>>>> *From:*Mr. Jaehoon Paul Jeong >>>>>>>> [mailto:jaehoon.paul@gmail.com] *Sent:* Thursday 14 April >>>>>>>> 2016 09:36 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:* Alexandre = Petrescu; >>>>>>>> its@ietf.org *Subject:* Re: [its] >>>>>>>> charter ITS >>>>>>>>=20 >>>>>>>> J=C3=A9r=C3=B4me, >>>>>>>>=20 >>>>>>>> I missed that you are also an academic person. >>>>>>>>=20 >>>>>>>> I got it :-) >>>>>>>>=20 >>>>>>>> I understand your points for industry activity related >>>>>>>> to vehicular networking. >>>>>>>>=20 >>>>>>>> Your observation seems true. >>>>>>>>=20 >>>>>>>> BTW, I will invite you to my team for the draft for a >>>>>>>> list of academic papers for V2V and V2I >>>>>>>>=20 >>>>>>>> by a personal message. >>>>>>>>=20 >>>>>>>> Thanks. >>>>>>>>=20 >>>>>>>> Paul >>>>>>>>=20 >>>>>>>> On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri >>>>>>>> >>>>>>> >>>>>>>> > wrote: >>>>>>>>=20 >>>>>>>> Hi Paul, >>>>>>>>=20 >>>>>>>> Thanks for your feedback. Do not get me wrong, I am an >>>>>>>> academic and with my team, we also work on IP-based V2V >>>>>>>> and V2I, in particular related to mobility management >>>>>>>> with DMM, but also in the context of vehicular IoT. >>>>>>>>=20 >>>>>>>> I just have the feeling that people are perfectly aware >>>>>>>> of the fact that IP _can_ be used for V2V and V2I, but >>>>>>>> does not =E2=80=98_need_=E2=80=99 to be used as other solutions = already >>>>>>>> perfectly fit their need. Listing papers will not change >>>>>>>> this awareness. >>>>>>>>=20 >>>>>>>> So, as a complement to academic papers, it would help to >>>>>>>> be able to pin-point which industrial activities are >>>>>>>> using or are strongly planning (short term I mean) to use >>>>>>>> pure IPv6 system in vehicles. >>>>>>>>=20 >>>>>>>> My feeling here is we have a different eco-system that >>>>>>>> the Automotive industry (and automotive industry-related >>>>>>>> SDO)..more likely the IoT industry=E2=80=A6and as such, we = should >>>>>>>> not need to have the (direct) involvement of automotive >>>>>>>> industry in the Charter. If we can make this clear by an >>>>>>>> industry-based =E2=80=98survey=E2=80=99, that would help make = the case >>>>>>>> for the WG. >>>>>>>>=20 >>>>>>>> Btw, you can count on me your draft..we can add some >>>>>>>> IP-based V2V and V2I for mobility management and also >>>>>>>> IoT. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>> J=C3=A9r=C3=B4me >>>>>>>>=20 >>>>>>>> *From:*Mr. Jaehoon Paul Jeong >>>>>>>> [mailto:jaehoon.paul@gmail.com >>>>>>>> ] *Sent:* Thursday 14 >>>>>>>> April 2016 03:22 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:* = Alexandre >>>>>>>> Petrescu; its@ietf.org >>>>>>>> *Subject:* Re: [its] charter ITS >>>>>>>>=20 >>>>>>>> Hi J=C3=A9r=C3=B4me, >>>>>>>>=20 >>>>>>>> I have an opinion on your comment 5) below. >>>>>>>>=20 >>>>>>>> I think that a list of high-quality papers about IP-based >>>>>>>> V2V and V2I >>>>>>>>=20 >>>>>>>> can teach very useful lessons to software designers of IP >>>>>>>> in V2V and V2I >>>>>>>>=20 >>>>>>>> in the industry. >>>>>>>>=20 >>>>>>>> Multiple people are working for this IP-based V2V and >>>>>>>> V2I >>>>>>>>=20 >>>>>>>> (including Sandra Cespedes and me) in academia and >>>>>>>>=20 >>>>>>>> more people(including Nabil Benamar) are willing to work >>>>>>>> for this area. >>>>>>>>=20 >>>>>>>> I think we need to utilize the list of such papers as the >>>>>>>> ground for our ITS group >>>>>>>>=20 >>>>>>>> through a WI. Note that the draft of the list will >>>>>>>> include the summary of the main >>>>>>>>=20 >>>>>>>> ideas of the papers. >>>>>>>>=20 >>>>>>>> For the industry current activities for this area, I >>>>>>>> believe that you can share them >>>>>>>>=20 >>>>>>>> as references through our ITS mailing list rather than >>>>>>>> through a WI. >>>>>>>>=20 >>>>>>>> Could you join my team that are making efforts for a list >>>>>>>> of such papers? >>>>>>>>=20 >>>>>>>> Thanks. >>>>>>>>=20 >>>>>>>> Best Regards, >>>>>>>>=20 >>>>>>>> Paul >>>>>>>>=20 >>>>>>>> On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri >>>>>>>> >>>>>>> >>>>>>>> > wrote: >>>>>>>>=20 >>>>>>>> Dear ITSers, Dear Alex, >>>>>>>>=20 >>>>>>>> Here are some comments on the updated charter: >>>>>>>>=20 >>>>>>>> 1)Can we keep a reference to IEEE 802.11p, considering it >>>>>>>> does not exist anymore? It is now fully integrated into >>>>>>>> IEEE 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of >>>>>>>> course. >>>>>>>>=20 >>>>>>>> 2)Should we really keep C-ACC (or Platooning) in the >>>>>>>> charter explicitly as use case, considering it is a >>>>>>>> seriously controversial aspect with some SDOs (ex. In >>>>>>>> Automotive SDOs)? In the ISO presentation, Thierry >>>>>>>> mentions traffic efficiency/infotainment applications, >>>>>>>> such as in-signage applications... >>>>>>>>=20 >>>>>>>> a.We might have to aim at less controversial use cases >>>>>>>> to attract automotive industries >>>>>>>>=20 >>>>>>>> 3)One potential WI I could think of (rather a basic >>>>>>>> one): _definition of a vehicular wireless =E2=80=98link=E2=80=99 = in an >>>>>>>> automotive context_ >>>>>>>>=20 >>>>>>>> a.To me, this is a fundamental brick in the larger IETF >>>>>>>> WG ITS house.. >>>>>>>>=20 >>>>>>>> 4)I would suggest to be more explicit in the foreseen >>>>>>>> challenges of this WG, instead of mentioning general use >>>>>>>> case (which end up be controversial) >>>>>>>>=20 >>>>>>>> a.Example: maintaining IPv6 connectivity in fast and >>>>>>>> asymmetric wireless links; also under quickly changing >>>>>>>> topologies (actually suggested by Dick Roy on the chat >>>>>>>> room) >>>>>>>>=20 >>>>>>>> b.Example: IPv6 addressing in link-local scope.. >>>>>>>>=20 >>>>>>>> c.Example: guaranteeing privacy in IPv6 moving networks >>>>>>>> etc.. >>>>>>>>=20 >>>>>>>> 5)Before listing academic papers referring to IPv6 in >>>>>>>> vehicles, I would suggest to first try to list commercial >>>>>>>> products/solutions that are in vehicles and are using >>>>>>>> IPv6, possibly suffering from a silo limitations (ex. >>>>>>>> restricted to a single technology, single use case=E2=80=A6) >>>>>>>>=20 >>>>>>>> a.I think we need to get to products first, before >>>>>>>> academic visions >>>>>>>>=20 >>>>>>>> My two cents.. >>>>>>>>=20 >>>>>>>> Best Regards, >>>>>>>>=20 >>>>>>>> J=C3=A9r=C3=B4me >>>>>>>>=20 >>>>>>>> *From:*its [mailto:its-bounces@ietf.org >>>>>>>> ] *On Behalf Of *Alexandre >>>>>>>> Petrescu *Sent:* Wednesday 06 April 2016 23:45 *To:* >>>>>>>> its@ietf.org >>>>>>>> *Subject:* [its] charter ITS >>>>>>>>=20 >>>>>>>> ITSers, >>>>>>>>=20 >>>>>>>> Please see below the current charter. >>>>>>>>=20 >>>>>>>> - the two Problem Statements drafts V2V and V2I joined, >>>>>>>> so there is less text in charter. - added an Item on >>>>>>>> "List of Research papers..." >>>>>>>>=20 >>>>>>>> Erik: did I understand you correctly that there should be >>>>>>>> some item on discussing whether link-local addressing is >>>>>>>> sufficient, whether prefix exchange is necessary? >>>>>>>>=20 >>>>>>>> Dino: should LISP be included in the gap analysis draft >>>>>>>> which includes C-ACC use-case? OR should we separate a >>>>>>>> dedicated I-D only with gap analysis including ND, MIP, >>>>>>>> AODVv2, LISP? >>>>>>>>=20 >>>>>>>> Person from mediatek: is the 'zeroconf' need in the >>>>>>>> vehicle-to-vehicle interface illustrated good enough by >>>>>>>> the words "moving network to nearby moving network >>>>>>>> communications"? Or is it better to say "the 1-IP-hop >>>>>>>> between nearby moving networks must be self-configured"? >>>>>>>>=20 >>>>>>>> Nabil, Sandra: is it ok to have a working group item >>>>>>>> "List of Research Papers for IP in V2V and V2I >>>>>>>> communications"? >>>>>>>>=20 >>>>>>>> Other comments? >>>>>>>>=20 >>>>>>>> Alex >>>>>>>>=20 >>>>>>>> = ------------------------------------------------------------------ >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 > ITS (name to change) >>>>>>>> Charter April 6th, 2016 >>>>>>>> http://ietf.org/mailman/listinfo/its >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Intelligent Transportation Systems (its) >>>>>>>> ---------------------------------------- Current Status: >>>>>>>> WG forming >>>>>>>>=20 >>>>>>>> Chairs: TBD >>>>>>>>=20 >>>>>>>> Assigned Area Director: TBD >>>>>>>>=20 >>>>>>>> Mailing list Address: its@ietf.org >>>>>>>> To Subscribe: >>>>>>>> https://www.ietf.org/mailman/listinfo/its Archive: >>>>>>>> http://www.ietf.org/mail-archive/web/its/current/maillist.html >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 > Additional web page TBD >>>>>>>>=20 >>>>>>>> Charter: >>>>>>>>=20 >>>>>>>> Goal ---- The goal of this group is to standardize >>>>>>>> IP-based protocols for establishing direct and secure >>>>>>>> connectivity between moving networks, some of which could >>>>>>>> be fixed permanently or temporarily. >>>>>>>>=20 >>>>>>>> Moving Network to Nearby Moving Network Communications >>>>>>>> ------------------------------------------------------ >>>>>>>> The group is concerned with all situations involving >>>>>>>> moving network to nearby moving network communications. >>>>>>>> For example: vehicle-to-vehicle communications, nomadic >>>>>>>> user wearing a PAN and communicating to a homenet, >>>>>>>> vehicle-to-infrastructure communications, wagon-to-wagon >>>>>>>> in a train, or train-to-intersection signalling. >>>>>>>>=20 >>>>>>>> Example from the automobile communications space >>>>>>>> ------------------------------------------------ >>>>>>>> Automobiles and vehicles of all types are increasingly >>>>>>>> connected to the Internet, either as vehicle-to-vehicle, >>>>>>>> vehicle-to-infra or vehicle-to-Internet. Entertainment >>>>>>>> apps enhancing comfort, reliable data exchanges for road >>>>>>>> safety, and automated driving are features coming in >>>>>>>> automobiles to hit the roads from now to year 2020. >>>>>>>> Highlighting increased safety as an immediate result of >>>>>>>> hyper-connectivity applied to vehicles, public >>>>>>>> authorities worldwide are increasingly mandating secure >>>>>>>> communication technology requirements in vehicles. >>>>>>>>=20 >>>>>>>> Emergency apps for new instrumented ambulances carry >>>>>>>> many benefits both to the users and to society in >>>>>>>> general. >>>>>>>>=20 >>>>>>>> Why IP? ------- Today, there are several deployed >>>>>>>> Vehicle-to-Internet technologies, including car tethering >>>>>>>> through driver's cellular smartphone. However, >>>>>>>> Vehicle-to-Vehicle and Vehicle-to-Infrastructure >>>>>>>> communications are still being developed. To improve on >>>>>>>> a situation of link-specific data exchanges, and enable >>>>>>>> independent application sets to share the same links, IP >>>>>>>> data exchanges are needed. Enabling IP communication >>>>>>>> between vehicles (V2V), and between vehicles and the >>>>>>>> immediate infrastructure (V2I), will provide (0) ability >>>>>>>> to reach the rest of the world on the Internet (1) short >>>>>>>> and deterministic delays, (2) fast forwarding through >>>>>>>> scalable paths of routers, (3) ease of reuse of existing >>>>>>>> Internet applications in a vehicular environment. >>>>>>>>=20 >>>>>>>> Moving network to nearby moving network communications >>>>>>>> involve link layers such as: 802.11p OCB (Outside the >>>>>>>> Context of a Basic Service Set), 802.15.4 with 6lowpan, >>>>>>>> 802.11ac, VLC (Visible Light Communications), IrDA, >>>>>>>> LTE-D. Only the IP protocols are capable of running on >>>>>>>> each of these links and establish IP paths across them in >>>>>>>> an interoperable manner. >>>>>>>>=20 >>>>>>>> Scenarios? ---------- There are a few scenarios >>>>>>>> exhibiting the need to communicate from one moving >>>>>>>> network to another nearby moving network. >>>>>>>>=20 >>>>>>>> In the automobile space, the Cooperative Adaptive Cruise >>>>>>>> Control and Platooning features consider that vehicles >>>>>>>> close to each other exchange data describing their >>>>>>>> kinematic status. At the cross-roads, the moving network >>>>>>>> inside a vehicle exchanges data with the moving network >>>>>>>> in the red-light pole. >>>>>>>>=20 >>>>>>>> Several public safety scenarios involve moving networks. >>>>>>>> Distinct organizations deploy different moving networks >>>>>>>> (in-vehicle, on-person) at an incident scene. These >>>>>>>> networks need to interoperate in order to more >>>>>>>> effectively understand and deal with the incident scene. >>>>>>>>=20 >>>>>>>> In connected rail scenarios the moving network deployed >>>>>>>> in trains communicate with other moving networks at the >>>>>>>> cross-points. >>>>>>>>=20 >>>>>>>> What kind of solutions? ----------------------- The >>>>>>>> current technical solutions considered to achieve moving >>>>>>>> network to nearby moving network communications are of >>>>>>>> two kinds: IP routing protocols for n-hop path management >>>>>>>> and 1-hop link-scoped IP protocol enhancements. The >>>>>>>> 1-hop link-scoped protocols include the protocols for >>>>>>>> route establishment involving ICMP Router Advertisements. >>>>>>>> The n-hop path management protocols include n-hop path >>>>>>>> establishment protocols (e.g. Babel, OSPF) and n-hop path >>>>>>>> search protocols (most notably AODV and derivates). >>>>>>>>=20 >>>>>>>> In this proposed Working Group the focus is on 1-hop >>>>>>>> protocols, and leverage from other Working Groups for the >>>>>>>> n-hop situations. >>>>>>>>=20 >>>>>>>> In some of the moving network applications the window of >>>>>>>> opportunity for exchanging data with the immediate >>>>>>>> infrastructure may be very short. For example, a car >>>>>>>> driving near a road-side unit may have only 5s to >>>>>>>> exchange with that RSU (depending on speed, RSU range and >>>>>>>> number). (ephemeral connections). >>>>>>>>=20 >>>>>>>> What kind of requirements? -------------------------- >>>>>>>> The requirements for mechanisms for moving network to >>>>>>>> nearby moving network communications are focusing on low >>>>>>>> delays of the data paths, reduced number of messages for >>>>>>>> path establishment, application friendly, resilience to >>>>>>>> attacks, compatibility with DHCP and Mobile IP. >>>>>>>>=20 >>>>>>>> In addition, some moving network to nearby moving >>>>>>>> network applications involve IP multicast mechanisms >>>>>>>> (e.g. virtual siren); thus C-ACC the 1-hop IP moving >>>>>>>> network to nearby moving netowrk mechanisms will need to >>>>>>>> gracefully support IP multicast. >>>>>>>>=20 >>>>>>>> Due to the inherent characteristics of safety-related >>>>>>>> communications, all new moving network to nearby moving >>>>>>>> network mechanisms must afford authenticity and >>>>>>>> confidentiality where necessary. Dynamically >>>>>>>> establishing ephemeral communication paths between >>>>>>>> automobiles in public areas must offer privacy safeguards >>>>>>>> for the end users (passengers). >>>>>>>>=20 >>>>>>>> Establishing 1-hop IP V2V paths must not break the >>>>>>>> existing on-board protocols and applications which >>>>>>>> communicate with the Internet, possibly via multiple >>>>>>>> radios. >>>>>>>>=20 >>>>>>>> In a moving network deployed in an automobile, typically >>>>>>>> one exit point connects the moving network to other >>>>>>>> moving networks. However, in a more general manner (and >>>>>>>> to support reliability) any new mechanism of moving >>>>>>>> network to nearby moving network communications should >>>>>>>> support multi-homing: one router to use multiple >>>>>>>> interfaces towards outside the moving network, or >>>>>>>> multiple routers. >>>>>>>>=20 >>>>>>>> Current version of Internet protocols >>>>>>>> ------------------------------------- The group will only >>>>>>>> work on IPv6 solutions. >>>>>>>>=20 >>>>>>>> What SDOs may need this work? >>>>>>>> ----------------------------- The requirements and >>>>>>>> standards for moving network to nearby moving network >>>>>>>> communications, often involving IPv6, and novel V2V and >>>>>>>> V2Infra concepts, are developed mainly at ISO TC204 >>>>>>>> "Intelligent Transport Systems", 3GPP, ETSI, NHTSA and >>>>>>>> IEEE. For Vehicle-to-Internet communications, 3GPP LTE >>>>>>>> and other cellular technologies represent the long-range >>>>>>>> connectivity method; for Vehicle-to-Vehicle >>>>>>>> communications, LTE Direct is currently specified, as >>>>>>>> well as OCB mode of IEEE 802.11. Several use-cases >>>>>>>> exhibit a need for IPv6 data exchanges between vehicles: >>>>>>>> ETSI's Cooperative Adaptive Cruise Control and >>>>>>>> Platooning. The IEEE developed a popular link for >>>>>>>> short-range communications - IEEE 802.11p "WAVE". The >>>>>>>> NHTSA wrote a set of requirements for V2V >>>>>>>> communications. >>>>>>>>=20 >>>>>>>> Work Items ---------- - use-cases for moving network to >>>>>>>> nearby moving network communications - Problem Statement >>>>>>>> for moving network to nearby moving network >>>>>>>> communications including V2V, V2I and DNS. - Security and >>>>>>>> Privacy Requirements for moving network to nearby moving >>>>>>>> network communications - Solutions, which might include >>>>>>>> new protocols or extensions to existing protocols. With >>>>>>>> MIB. - IPv6-over foo, where foo is pertinent for moving >>>>>>>> network to nearby moving network communications (e.g. >>>>>>>> 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research >>>>>>>> Papers in the V2V domain, identifying which uses IP. >>>>>>>>=20 >>>>>>>> Timeline -------- - >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>>=20 >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Mr. Jaehoon (Paul) Jeong, >>>>>>>> Ph.D. Assistant Professor Department of Software >>>>>>>> Sungkyunkwan University Office: +82-31-299-4957 Email: >>>>>>>> jaehoon.paul@gmail.com , >>>>>>>> pauljeong@skku.edu Personal >>>>>>>> Homepage: >>>>>>>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>>>> >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>>=20 >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Mr. Jaehoon (Paul) Jeong, >>>>>>>> Ph.D. Assistant Professor Department of Software >>>>>>>> Sungkyunkwan University Office: +82-31-299-4957 Email: >>>>>>>> jaehoon.paul@gmail.com , >>>>>>>> pauljeong@skku.edu Personal >>>>>>>> Homepage: >>>>>>>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>>>> >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ its mailing >>>>>>> list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_1A23261A-9F45-4D12-9C53-E1B4B4A14C5D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Super! 

Let me work on the gap analysis. Soon I will post = this. 

Cheers!
--
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Apr 18, 2016, at 8:23 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

Hi Jong-Hyouk,

Le 18/04/2016 12:07, Jong-Hyouk Lee a =C3=A9crit = :
Hi = Alex

Thx for your prompt message. Plz see = inline. -- Jong-Hyouk Lee,
living somewhere between = /dev/null and /dev/random Protocol
Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com = #webpage:
https://sites.google.com/site/hurryon

On Apr 18, 2016, at 4:52 = PM, Alexandre Petrescu
<alexandre.petrescu@gmail.com> = wrote:



Le = 18/04/2016 09:32, Jong-Hyouk Lee a =C3=A9crit :
Thx, plz see inline. -- Jong-Hyouk Lee, living = somewhere between
/dev/null and /dev/random Protocol = Engineering Lab., Sangmyung
University

#email: jonghyouk@gmail.com = <mailto:jonghyouk@gmail.com>
#webpage: = https://sites.google.com/site/hurryon

On Apr 18, 2016, at 3:52 = PM, Alexandre Petrescu
<alexandre.petrescu@gmail.com
<mailto:alexandre.petrescu@gmail.com>> wrote:

Hi Jong-Hyouk,

Le = 17/04/2016 14:07, Jong-Hyouk Lee a =C3=A9crit :
Hi Alex

Just to = clarify. -- Jong-Hyouk Lee, living somewhere between
/dev/null and /dev/random Protocol Engineering Lab.,
Sangmyung University

#email: = jonghyouk@gmail.com <mailto:jonghyouk@gmail.com>
#webpage: https://sites.google.com/site/hurryon

On Apr = 14, 2016, at 5:42 PM, Alexandre Petrescu
<alexandre.petrescu@gmail.com> wrote:

ITSers,

We work on a more = rigorous ITS charter text.

Now we propose = four work items:

1. "Problem statement for = IP in V2V and V2I" including "IP
addressing architecture = for V2V and V2I" and including
"Gap Analysis: IP protocols = suited and gaps" and including
"Use-cases for IP in V2V = and V2I moving network to nearby
moving or fixed = network=E2=80=9D

Are you = intending to have one document that includes those
three = parts?

Yes.

Because we need to reduce the number of items.  Because = one of
the remarks during BoF was that the scope was too = large.

Hum=E2=80=A6then, the = document will be too broad. We may need people to
work on = each part.

Yes.  There = are already a few drafts for this item.  Their authors
are interested and agreed on joining some of the efforts.

Which ones? Can you kindly give = pointers?

There are two Problem Statements, one for = V2V and one for V2I:
draft-petrescu-its-problem-01.txtdraft-jeong-its-v2i-problem-statement-00
Their authors = agreed to join.

There is a section = titled 'Gap Analysis' in:
draft-petrescu-its-cacc-sdo-04.txt
We could extract = that section.

There is some = useful text that can be used for 'use-cases for IP in V2V and V2I moving = network to nearby moving or fixed network':
draft-liu-its-scenario-00
draft-petrescu-its-cacc-sdo-04.txt
I expect authors to = agree.

If that is not = enough, we can ask members of the ITS at IETF email list whether they = can write use-case text for this latter part.

The use-case is any use-case that makes = use of the following topology:


          &nb= sp;   Vehicle 1 =             &n= bsp;           &nbs= p;   Vehicle 2
          &nb= sp;            = ;            e= .g.
          &nb= sp;            = ;      o)) LTE D2D, ((o
          &nb= sp;            = ;      |   802.11p, =   |
          &nb= sp;            = ;      |     LiFi =     |
          &nb= sp;            = ;      | =             &n= bsp;|
        +------+ =          +--+--+ =        +--+--+ =     +----------+
        |GPS PC| =          | eR1 | =        | eR2 | =     |Braking PC|
        +--+---+ =          +--+--+ =        +--+--+ =     +-----+----+
          &nb= sp;| =             &n= bsp;   | =             &n= bsp;| =             &n= bsp;|
          &nb= sp;| =             &n= bsp;   | =             &n= bsp;| =             &n= bsp;|
          &nb= sp;|    Ethernet     | =             &n= bsp;|  Ethernet    |
          -+-= ----------------+- =          ---+--------------+-= ----
          &nb= sp; 2001:db8:1::/40 =             &n= bsp;        2001:db8:2::/40=


Are you interested in some part of this big = document?

Sure, I am = interested in this work. I suppose that the gap analysis
part is a good start point for us and for me as well. I am = waiting
for your pointers to the exiting drafts relevant = with this work item.
If the existing drafts are not = covering yet the gap analysis, then
I=E2=80=99ll go for = this.

Look at the gap analysis:
https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-04#sect= ion-14

Alex



2. "Threat Analysis for IP prefix exchanges in V2V and V2I
context=E2=80=9D

Is = this mean that this group first go for this and later
considers a general security document (e.g., security
requirements for ITS) ?

For now it is "Threat Analysis for IP prefix exchanges in = V2V
and V2I context=E2=80=9D.
Ok. For the document =E2=80=9CThreat Analysis of IP prefix = exchanges in
V2V and V2I=E2=80=9D, I just started to work = on. Soon I will post.

I take = it as agreement from you, and it will be in the proposed
charter text.

Yes, = plz. I will soon post.


"General security = requirements for ITS" seems very broad - what
do you mean = more precisely?

We may later = need one document describing general security
requirements = for ITS that corresponds the document =E2=80=9CPS for IP in
V2V and V2I=E2=80=9D. We will be later. ;)

Ok.

Alex


Good day!


Alex


Cheers.


3. "IP over DSRC (802.11-OCB)" typical = IP-over-foo
document[*], including connectivity in fast = and asymmetric
conditions, coverage area vs speed = diagrams, below-IP
congestion management.

4. "List of papers and _products_ using IP in V2V and V2I"

What do you think?

Please respond by next Monday, April 18th.

Alex and Dapeng [*] a typical IP-over-foo document is, for
example, RFC2464 "Transmission of IPv6 Packets over
Ethernet Networks", where "foo" is instantiated as
"Ethernet".  Other IPv6-over-foo documents are = RFC4944
"IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and = more.

Le 14/04/2016 09:42, J=C3=A9r=C3=B4me = H=C3=A4rri a =C3=A9crit :
Paul,

Thanks. Btw, when I = mentioned =E2=80=98people=E2=80=99 are aware of IP
V2V but = not see the need (so far), I referred to the
automotive = SDOs (led by automotive industries)=E2=80=A6, although
there= are always =E2=80=98minority reports=E2=80=99 J

Cheers,

J=C3=A9r=C3=B4me

*From:*Mr. Jaehoon Paul Jeong
[mailto:jaehoon.paul@gmail.com] *Sent:* Thursday 14 = April
2016 09:36 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:* = Alexandre Petrescu;
its@ietf.org <mailto:its@ietf.org> *Subject:* Re: [its]
charter ITS

J=C3=A9r=C3=B4me,

I missed that you are also an academic = person.

I got it :-)

I understand your points for industry activity related
to vehicular networking.

Your = observation seems true.

BTW, I will invite = you to my team for the draft for a
list of academic papers = for V2V and V2I

by a personal message.

Thanks.

Paul

On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4m= e H=C3=A4rri
<jerome.haerri@eurecom.fr
<mailto:jerome.haerri@eurecom.fr>
<mailto:jerome.haerri@eurecom.fr>> wrote:

Hi Paul,

Thanks = for your feedback. Do not get me wrong, I am an
academic = and with my team, we also work on IP-based V2V
and V2I, in = particular related to mobility management
with DMM, but = also in the context of vehicular IoT.

I = just have the feeling that people are perfectly aware
of = the fact that IP _can_ be used for V2V and V2I, but
does = not =E2=80=98_need_=E2=80=99 to be used as other solutions already
perfectly fit their need. Listing papers will not change
this awareness.

So, as a = complement to academic papers, it would help to
be able to = pin-point which industrial activities are
using or are = strongly planning (short term I mean) to use
pure IPv6 = system in vehicles.

My feeling here is we = have a different eco-system that
the Automotive industry = (and automotive industry-related
SDO)..more likely the IoT = industry=E2=80=A6and as such, we should
not need to have = the (direct) involvement of automotive
industry in the = Charter. If we can make this clear by an
industry-based = =E2=80=98survey=E2=80=99, that would help make the case
for = the WG.

Btw, you can count on me your = draft..we can add some
IP-based V2V and V2I for mobility = management and also
IoT.

Cheers,

J=C3=A9r=C3=B4me

*From:*Mr. Jaehoon Paul Jeong
[mailto:jaehoon.paul@gmail.com
<mailto:jaehoon.paul@gmail.com>] *Sent:* Thursday 14
April 2016 03:22 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:* = Alexandre
Petrescu; its@ietf.org <mailto:its@ietf.org>
<mailto:its@ietf.org> = *Subject:* Re: [its] charter ITS

Hi = J=C3=A9r=C3=B4me,

I have an opinion on your = comment 5) below.

I think that a list of = high-quality papers about IP-based
V2V and V2I

can teach very useful lessons to software = designers of IP
in V2V and V2I

in the industry.

Multiple people = are working for this IP-based V2V and
V2I

(including Sandra Cespedes and me) in academia and

more people(including Nabil Benamar) are = willing to work
for this area.

I think we need to utilize the list of such papers as the
ground for our ITS group

through = a WI. Note that the draft of the list will
include the = summary of the main

ideas of the papers.

For the industry current activities for this = area, I
believe that you can share them

as references through our ITS mailing list rather than
through a WI.

Could you join my = team that are making efforts for a list
of such papers?

Thanks.

Best = Regards,

Paul

On= Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri
<jerome.haerri@eurecom.fr
<mailto:jerome.haerri@eurecom.fr>
<mailto:jerome.haerri@eurecom.fr>> wrote:

Dear ITSers,  Dear Alex,

Here are some comments on the updated charter:

1)Can we keep a reference to IEEE 802.11p, = considering it
does not exist anymore? It is now fully = integrated into
IEEE 802.11-2012 as OCB mode (and 10Mhz = @5.9Ghz) of
course.

2)Should = we really keep C-ACC (or Platooning) in the
charter = explicitly as use case, considering it is a
seriously = controversial aspect with some SDOs (ex. In
Automotive = SDOs)? In the ISO presentation, Thierry
mentions traffic = efficiency/infotainment applications,
such as in-signage = applications...

a.We might have to aim at = less controversial use cases
to attract automotive = industries

3)One potential WI I could think = of (rather a basic
one): _definition of a vehicular = wireless =E2=80=98link=E2=80=99 in an
automotive = context_

a.To me, this is  a = fundamental brick in the larger IETF
WG ITS house..

4)I would suggest to be more explicit in the = foreseen
challenges of this WG, instead of mentioning = general use
case (which end up be controversial)

a.Example: maintaining IPv6 connectivity in = fast and
asymmetric wireless links; also under quickly = changing
topologies (actually suggested by Dick Roy on the = chat
room)

b.Example: IPv6 = addressing in link-local scope..

c.Example: = guaranteeing privacy in IPv6 moving networks
etc..

5)Before listing academic papers referring to = IPv6 in
vehicles, I would suggest to first try to list = commercial
products/solutions that are in vehicles and are = using
IPv6, possibly suffering from a silo limitations = (ex.
restricted to a single technology, single use = case=E2=80=A6)

a.I think we need to get to = products first, before
academic visions

My two cents..

Best Regards,

J=C3=A9r=C3=B4me

*From:*its [mailto:its-bounces@ietf.org
<mailto:its-bounces@ietf.org>] *On Behalf Of = *Alexandre
Petrescu *Sent:* Wednesday 06 April 2016 23:45 = *To:*
its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org>
*Subject:* [its] = charter ITS

ITSers,

Please see below the current charter.

- the two Problem Statements drafts V2V and V2I joined,
so there is less text in charter. - added an Item on
"List of Research papers..."

Erik:= did I understand you correctly that there should be
some = item on discussing whether link-local addressing is
sufficient, whether prefix exchange is necessary?

Dino: should LISP be included in the gap = analysis draft
which includes C-ACC use-case?  OR = should we separate a
dedicated I-D only with gap analysis = including ND, MIP,
AODVv2, LISP?

Person from mediatek: is the 'zeroconf' need in the
vehicle-to-vehicle interface illustrated good enough by
the words "moving network to nearby moving network
communications"?  Or is it better to say "the = 1-IP-hop
between nearby moving networks must be = self-configured"?

Nabil, Sandra: is it ok = to have a working group item
"List of Research Papers for = IP in V2V and V2I
communications"?

Other comments?

Alex

---------------------------------------------------------------= ---





ITS (name to = change)
Charter = April 6th, 2016
http://ietf.org/mailman/listinfo/its


Intelligent Transportation Systems (its)
---------------------------------------- Current Status:
WG forming

Chairs: TBD

Assigned Area Director: TBD

Mailing list Address: its@ietf.org = <mailto:its@ietf.org>
<mailto:its@ietf.org> To = Subscribe:
https://www.ietf.org/mailman/listinfo/its = Archive:
http://www.ietf.org/mail-archive/web/its/current/maillist.html<= br class=3D"">


Additional web page = TBD

Charter:

Goal ---- The goal of = this group is to standardize
IP-based protocols for = establishing direct and secure
connectivity between moving = networks, some of which could
be fixed permanently or = temporarily.

Moving Network to Nearby = Moving Network Communications
------------------------------------------------------
The group is concerned with all situations involving
moving network to nearby moving network communications.
For example: vehicle-to-vehicle communications, nomadic
user wearing a PAN and communicating to a homenet,
vehicle-to-infrastructure communications, wagon-to-wagon
in a train, or train-to-intersection signalling.

Example from the automobile communications = space
------------------------------------------------
Automobiles and vehicles of all types are increasingly
connected to the Internet, either as vehicle-to-vehicle,
vehicle-to-infra or vehicle-to-Internet. =  Entertainment
apps enhancing comfort, reliable data = exchanges for road
safety, and automated driving are = features coming in
automobiles to hit the roads from now = to year 2020.
Highlighting increased safety as an = immediate result of
hyper-connectivity applied to = vehicles, public
authorities worldwide are increasingly = mandating secure
communication technology requirements in = vehicles.

Emergency apps for new = instrumented ambulances carry
many benefits both to the = users and to society in
general.

Why IP? ------- Today, there are several deployed
Vehicle-to-Internet technologies, including car tethering
through driver's cellular smartphone. However,
Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communications are still being developed.  To improve = on
a situation of link-specific data exchanges, and = enable
independent application sets to share the same = links, IP
data exchanges are needed.  Enabling IP = communication
between vehicles (V2V), and between vehicles = and the
immediate infrastructure (V2I), will provide (0) = ability
to reach the rest of the world on the Internet (1) = short
and deterministic delays, (2) fast forwarding = through
scalable paths of routers, (3) ease of reuse of = existing
Internet applications in a vehicular = environment.

Moving network to nearby = moving network communications
involve link layers such as: = 802.11p OCB (Outside the
Context of a Basic Service Set), = 802.15.4 with 6lowpan,
802.11ac, VLC (Visible Light = Communications), IrDA,
LTE-D.  Only the IP protocols = are capable of running on
each of these links and = establish IP paths across them in
an interoperable = manner.

Scenarios? ---------- There are a = few scenarios
exhibiting the need to communicate from one = moving
network to another nearby moving network.

In the automobile space, the Cooperative = Adaptive Cruise
Control and Platooning features consider = that vehicles
close to each other exchange data describing = their
kinematic status.  At the cross-roads, the = moving network
inside a vehicle exchanges data with the = moving network
in the red-light pole.

Several public safety scenarios involve moving networks.
Distinct organizations deploy different moving networks
(in-vehicle, on-person) at an incident scene.  These
networks need to interoperate in order to more
effectively understand and deal with the incident scene.

In connected rail scenarios the moving network = deployed
in trains communicate with other moving networks = at the
cross-points.

What = kind of solutions? ----------------------- The
current = technical solutions considered to achieve moving
network = to nearby moving network communications are of
two kinds: = IP routing protocols for n-hop path management
and 1-hop = link-scoped IP protocol enhancements.  The
1-hop = link-scoped protocols include the protocols for
route = establishment involving ICMP Router Advertisements.
The = n-hop path management protocols include n-hop path
establishment protocols (e.g. Babel, OSPF) and n-hop path
search protocols (most notably AODV and derivates).

In this proposed Working Group the focus is on = 1-hop
protocols, and leverage from other Working Groups = for the
n-hop situations.

In = some of the moving network applications the window of
opportunity for exchanging data with the immediate
infrastructure may be very short.  For example, a car
driving near a road-side unit may have only 5s to
exchange with that RSU (depending on speed, RSU range and
number). (ephemeral connections).

What kind of requirements? --------------------------
The requirements for mechanisms for moving network to
nearby moving network communications are focusing on low
delays of the data paths, reduced number of messages for
path establishment, application friendly, resilience to
attacks, compatibility with DHCP and Mobile IP.

In addition, some moving network to nearby = moving
network applications involve IP multicast = mechanisms
(e.g. virtual siren); thus C-ACC the 1-hop IP = moving
network to nearby moving netowrk mechanisms will = need to
gracefully support IP multicast.

Due to the inherent characteristics of safety-related
communications, all new moving network to nearby moving
network mechanisms must afford authenticity and
confidentiality where necessary.  Dynamically
establishing ephemeral communication paths between
automobiles in public areas must offer privacy safeguards
for the end users (passengers).

Establishing 1-hop IP V2V paths must not break the
existing on-board protocols and applications which
communicate with the Internet, possibly via multiple
radios.

In a moving network = deployed in an automobile, typically
one exit point = connects the moving network to other
moving networks. = However, in a more general manner (and
to support = reliability) any new mechanism of moving
network to nearby = moving network communications should
support multi-homing: = one router to use multiple
interfaces towards outside the = moving network, or
multiple routers.

Current version of Internet protocols
------------------------------------- The group will only
work on IPv6 solutions.

What = SDOs may need this work?
----------------------------- The = requirements and
standards for moving network to nearby = moving network
communications, often involving IPv6, and = novel V2V and
V2Infra concepts, are developed mainly at = ISO TC204
"Intelligent Transport Systems", 3GPP, ETSI, = NHTSA and
IEEE.  For Vehicle-to-Internet = communications, 3GPP LTE
and other cellular technologies = represent the long-range
connectivity method; for = Vehicle-to-Vehicle
communications, LTE Direct is currently = specified, as
well as OCB mode of IEEE 802.11. =  Several use-cases
exhibit a need for IPv6 data = exchanges between vehicles:
ETSI's Cooperative Adaptive = Cruise Control and
Platooning.  The IEEE developed a = popular link for
short-range communications - IEEE 802.11p = "WAVE".  The
NHTSA wrote a set of requirements for = V2V
communications.

Work = Items ---------- - use-cases for moving network to
nearby = moving network communications - Problem Statement
for = moving network to nearby moving network
communications = including V2V, V2I and DNS. - Security and
Privacy = Requirements for moving network to nearby moving
network = communications - Solutions, which might include
new = protocols or extensions to existing protocols.  With
MIB. - IPv6-over foo, where foo is pertinent for moving
network to nearby moving network communications (e.g.
802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research
Papers in the V2V domain, identifying which uses IP.

Timeline -------- -


_______________________________________________ = its
mailing list its@ietf.org <mailto:its@ietf.org>
https://www.ietf.org/mailman/listinfo/its


--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Mr. Jaehoon (Paul) Jeong,
Ph.D. = Assistant Professor Department of Software
Sungkyunkwan = University Office: +82-31-299-4957 Email:
jaehoon.paul@gmail.com = <mailto:jaehoon.paul@gmail.com>,
pauljeong@skku.edu = <mailto:pauljeong@skku.edu> Personal
Homepage:
http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>



--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. Jaehoon (Paul) Jeong,
Ph.D. Assistant Professor Department of Software
Sungkyunkwan University Office: +82-31-299-4957 Email:
jaehoon.paul@gmail.com = <mailto:jaehoon.paul@gmail.com>,
pauljeong@skku.edu = <mailto:pauljeong@skku.edu> Personal
Homepage:
http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>


_______________________________________________ its = mailing
list its@ietf.org <mailto:its@ietf.org>
https://www.ietf.org/mailman/listinfo/its

= --Apple-Mail=_1A23261A-9F45-4D12-9C53-E1B4B4A14C5D-- From nobody Mon Apr 18 07:51:56 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B5E12DCF0 for ; Mon, 18 Apr 2016 07:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfVb-r67ISiv for ; Mon, 18 Apr 2016 07:51:54 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8E1D12DB32 for ; Mon, 18 Apr 2016 07:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5726; q=dns/txt; s=iport; t=1460991113; x=1462200713; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HOqgVOqK05IpV8QdZ9oezp/q9rCLf28KdOwkWSbBZYY=; b=SVFc2/eYGif0pHFaL7j9I+l+V4bpFpkiRKbrDddmzcomNZvr6pmekyeJ CWy/dh9T4K3zHVGTyOcR7aRBdpPQXX6Y/Ei/s2+9J9W5NAg1McwVDLZb6 FUzNKayeBMHrhgofhMoU6h6HUQ7598QFzifD3uIu//+PGlTFBjKRcDRGU Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgA88xRX/4ENJK1dgmtNgVAGrkeGZ?= =?us-ascii?q?oRzAQ2BcYYOAoEzOBQBAQEBAQEBZSeEQgEBBHIHEAIBCBIFKAchERQDBggCBA4?= =?us-ascii?q?FG4d5AxK2BQ2FEgEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIYRLgkGHVAWOC4lSM?= =?us-ascii?q?QGMGIF1gWeEToMphTOHTodcAR4BAUKDaGyIPH4BAQE?= X-IronPort-AV: E=Sophos; i="5.24,502,1454976000"; d="scan'208,217"; a="92699186" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Apr 2016 14:51:52 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3IEpqEW021919 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Apr 2016 14:51:53 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Apr 2016 09:51:52 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Mon, 18 Apr 2016 09:51:52 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandre Petrescu Thread-Topic: [its] charter ITS - proposed work items Thread-Index: AQHRmT+qNMEnGW0uWUWMZTSYQj+ZY5+PqjmAgAAFfACAACXagIAAFUOAgAAEY4D//8BygA== Date: Mon, 18 Apr 2016 14:51:52 +0000 Message-ID: References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> In-Reply-To: <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.219] Content-Type: multipart/alternative; boundary="_000_D33A3FE5214F71sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 14:51:55 -0000 --_000_D33A3FE5214F71sgundaveciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alex - Inline .. To: Alexandre Petrescu > Cc: "its@ietf.org" > Subject: Re: [its] charter ITS - proposed work items ITSers, We work on a more rigorous ITS charter text. Now we propose four work items: 1. "Problem statement for IP in V2V and V2I" including "IP addressing architecture for V2V and V2I" and including "Gap Analysis: IP protocols suited and gaps" and including "Use-cases for IP in V2V and V2I moving network to nearby moving or fixed network" [Sri] Agree. This is a good starting point. Use-Cases document is needed. O= n the Gap Analysis document, it should be stated as how the gaps are captur= ed and in relation to what technology. Is it NEMO, MANET, some other protoc= ols ? 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" [Sri] If my starting point is #1, not sure how to read this ? Prefix exchan= ges appears more like a solution. In MANET there is exchange of prefixes, i= n NEMO we don't inject those prefixes and so I do not know if this work ite= m is valid at this time. 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], including connectivity in fast and asymmetric conditions, coverage area vs speed diagrams, below-IP congestion management. 4. "List of papers and _products_ using IP in V2V and V2I" [Sri] Not clear what the deliverable is. What do you think? Please respond by next Monday, April 18th. --_000_D33A3FE5214F71sgundaveciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <839F0F9697F5504D888DD493EE0940DE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Alex R= 11; Inline ..



To: Alexandre Petrescu <<= a href=3D"mailto:alexandre.petrescu@gmail.com">alexandre.petrescu@gmail.com= >
Cc: "its@ietf.org" <it= s@ietf.org>
Subject: Re: [its] charter I= TS - proposed work items


ITSers,

We work on a more rigorous ITS charter text.

Now we propose four work items:

1. "Problem statement for IP in V2V and V2I"
    including "IP addressing architecture for V2V and V2I"
    and including "Gap Analysis: IP protocols suited and gaps"
    and including "Use-cases for IP in V2V and V2I moving network to
                   nearby moving or fixed network"

[Sri] Agree. This is a good =
starting point. Use-Cases document is needed. On the Gap Analysis document,=
 it should be stated as how the gaps are captured and in relation to what t=
echnology. Is it NEMO, MANET, some other protocols ? 


2. "Threat Analysis for IP prefix exchanges in V2V and V2I context&quo=
t;

[Sri] If my starting point i=
s #1, not sure how to read this ? Prefix exchanges appears more like a solu=
tion. In MANET there is exchange of prefixes, in NEMO we don’t inject=
 those prefixes and so I do not know if this work item is valid at this tim=
e.

3. "IP over DSRC (802.1=
1-OCB)" typical IP-over-foo document[*],
    including connectivity in fast and asymmetric conditions, coverage
    area vs speed diagrams, below-IP congestion management.



4. "List of papers and _products_ using IP in V2V and V2I"

[Sri] Not clear what the del=
iverable is.


What do you think?

Please respond by next Monday, April 18th.

--_000_D33A3FE5214F71sgundaveciscocom_-- From nobody Mon Apr 18 08:22:39 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89ABD12DE82 for ; Mon, 18 Apr 2016 08:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P62Pdm9aNnTq for ; Mon, 18 Apr 2016 08:22:35 -0700 (PDT) Received: from mail-pa0-x241.google.com (mail-pa0-x241.google.com [IPv6:2607:f8b0:400e:c03::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B7A12DDC0 for ; Mon, 18 Apr 2016 08:22:35 -0700 (PDT) Received: by mail-pa0-x241.google.com with SMTP id i5so2515127pag.3 for ; Mon, 18 Apr 2016 08:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=L1hynrekNLcnzdITVFav9GQ9vu/t+gn0r/HWTfBmgUE=; b=03R5ao78eDX66GPmIOG0pP7FQArCgkYP2Q1hgciQCNwDytol70Yj6ngQEcCf9afgZP nSSXUDUrK9ECCydhc9QMYfbq9Ka369RthxQbofJRkkDplDxvuuhqak0xxpop+69cDIqG iMU8NFY2ClxzSRZiSOiY1QiMRRIiaHdLXtGWIVf3ZH6TlG0LGMtGfItrIlykHvN53v9P J3Ri8DL3mpRBQVsOLtBArDgPVJfwXPKhLBDg2Blz64MHqNosp/QRvZTXaKrIJRn292WU SaoC9a71SGvkvcERmgwxfQTDuihY9LD4fev5peirL6/YPp1pCHd5LwRqExt8c1/n6sHk 4LOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=L1hynrekNLcnzdITVFav9GQ9vu/t+gn0r/HWTfBmgUE=; b=JyCwhJyhux+Ypm1rR2jUeAlefjOKaa3P4re1in4+TUpZ/SnMUKZ5o3vmmeo24OaRF4 HJjHLfiRr2q6IV6iHCuGbntu4p+adntkgoUJQvLuvBtOG46rX19s6dRJS880dLkiaS7s hpktyj2gIQiEEFSYb+yjEJvkQbiF1lRVqmKKtwv2sVCHjPS+Xf0NpMeQOdeal1zMPTYB +VzRmUYEW4D0n/ZXTVmCW1nYar/MuB3uAVgioYNIps1tU/m4VeNeAHuSlauPC9BeRlGc 06pUg596aX/sQmeKGeafU2nGqcnFBwW7l6eOal+FLvZ6bttrctXO26If/RoLK04uQizw 2g8Q== X-Gm-Message-State: AOPr4FWlgqFrK7uHo4Uo6aiZW2YDwSMCrKWr21BQ1mYh1/klzH/wCdLrPMeHiZ8BYtBtfw== X-Received: by 10.66.79.197 with SMTP id l5mr19239643pax.61.1460992955383; Mon, 18 Apr 2016 08:22:35 -0700 (PDT) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id d78sm22061827pfb.61.2016.04.18.08.22.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Apr 2016 08:22:34 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_1BD43AEB-7F67-4557-85C3-8B03AE3A6ED3" From: Jong-Hyouk Lee In-Reply-To: Date: Tue, 19 Apr 2016 00:22:30 +0900 Message-Id: References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> To: "Sri Gundavelli (sgundave)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Alexandre Petrescu , "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 15:22:37 -0000 --Apple-Mail=_1BD43AEB-7F67-4557-85C3-8B03AE3A6ED3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Sri, Just one comment regarding IP prefix exchanges. Plz see inline. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) = wrote: >=20 > Alex =E2=80=93 Inline .. >=20 >=20 >=20 > To: Alexandre Petrescu > > Cc: "its@ietf.org " > > Subject: Re: [its] charter ITS - proposed work items >=20 >=20 > ITSers, >=20 > We work on a more rigorous ITS charter text. >=20 > Now we propose four work items: >=20 > 1. "Problem statement for IP in V2V and V2I" > including "IP addressing architecture for V2V and V2I" > and including "Gap Analysis: IP protocols suited and gaps" > and including "Use-cases for IP in V2V and V2I moving network to > nearby moving or fixed network" >=20 > [Sri] Agree. This is a good starting point. Use-Cases document is = needed. On the Gap Analysis document, it should be stated as how the = gaps are captured and in relation to what technology. Is it NEMO, MANET, = some other protocols ?=20 >=20 >=20 > 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" >=20 > [Sri] If my starting point is #1, not sure how to read this ? Prefix = exchanges appears more like a solution. In MANET there is exchange of = prefixes, in NEMO we don=E2=80=99t inject those prefixes and so I do not = know if this work item is valid at this time. You are right. That is a missing part. We need to have a solution for = "IP prefix exchanges in V2V and V2I=E2=80=9D The need of IP prefix = exchanges is clear and well presented in PS documents for IP in V2V and = V2I. Then, there are 2 documents already existing as below: 1. = https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 The above 2 documents are the early effort to establish IP direction = communications between vehicles and also between a vehicle and a road = side unit.=20 I officially request that we should have a solution for IP prefix = exchanges as a work item. Cheers! >=20 > 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], > including connectivity in fast and asymmetric conditions, coverage > area vs speed diagrams, below-IP congestion management. >=20 >=20 >=20 > 4. "List of papers and _products_ using IP in V2V and V2I" >=20 > [Sri] Not clear what the deliverable is. >=20 >=20 > What do you think? >=20 > Please respond by next Monday, April 18th. >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_1BD43AEB-7F67-4557-85C3-8B03AE3A6ED3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Sri,

Just one comment regarding IP prefix exchanges. Plz see = inline.
--
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) = <sgundave@cisco.com> wrote:

Alex =E2=80=93 Inline ..



To: Alexandre = Petrescu <alexandre.petrescu@gmail.com>
Cc: "its@ietf.org" <its@ietf.org>
Subject: Re: = [its] charter ITS - proposed work items


ITSers,

We work on a more rigorous ITS charter text.

Now we propose four work items:

1. "Problem statement for IP in V2V and V2I"
    including "IP addressing architecture for V2V and V2I"
    and including "Gap Analysis: IP protocols suited and gaps"
    and including "Use-cases for IP in V2V and V2I moving network to
                   nearby moving or fixed network"

[Sri] Agree. =
This is a good starting point. Use-Cases document is needed. On the Gap =
Analysis document, it should be stated as how the gaps are captured and =
in relation to what technology. Is it NEMO, MANET, some other protocols =
? 


2. "Threat Analysis for IP prefix exchanges in V2V and V2I context"

[Sri] If my =
starting point is #1, not sure how to read this ? Prefix exchanges =
appears more like a solution. In MANET there is exchange of prefixes, in =
NEMO we don=E2=80=99t inject those prefixes and so I do not know if this =
work item is valid at this =
time.

You are right. That is a missing part. We need to = have a solution for "IP prefix exchanges in V2V and V2I=E2=80=9D The = need of IP prefix exchanges is clear and well presented in PS documents = for IP in V2V and V2I. Then, there are 2 documents already existing as = below:

The above 2 documents are = the early effort to establish IP direction communications between = vehicles and also between a vehicle and a road side = unit. 

I officially request = that we should have a solution for IP prefix exchanges as a work = item.

Cheers!

3. "IP over =
DSRC (802.11-OCB)" typical IP-over-foo document[*],
    including connectivity in fast and asymmetric conditions, coverage
    area vs speed diagrams, below-IP congestion management.



4. "List of papers and _products_ using IP in V2V and V2I"

[Sri] Not =
clear what the deliverable is.


What do you think?

Please respond by next Monday, April 18th.

_______________________________________________
its = mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

= --Apple-Mail=_1BD43AEB-7F67-4557-85C3-8B03AE3A6ED3-- From nobody Mon Apr 18 08:56:58 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F34012E194 for ; Mon, 18 Apr 2016 08:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRWovZhA0zdL for ; Mon, 18 Apr 2016 08:56:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC31B12E192 for ; Mon, 18 Apr 2016 08:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12859; q=dns/txt; s=iport; t=1460995005; x=1462204605; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NQ8PMMWP7dRx/vcEGfP+XLWeSs+uny4PKoXlBWYE+DM=; b=fKbsx1UeRmiPkqKd7TsNaUS3C1ri4xh+BDdfH7D5KH7ubvVl0v9TXhzS WxPh1vrxupHesCLlQJma3ChIEzZFl+gGk2PKv6zr3Thu7WWeKMyFfMBTk 9mGhfAQF4NM+MQzf1/kLfmChthSBifkchl7aCf4R6nLZOCxpeh8yrUOCt 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAgBjAxVX/5RdJa1dgmtNU30GrkkHh?= =?us-ascii?q?l+EcwENgXEXAQqFbAKBNTgUAQEBAQEBAWUnhEEBAQEDAQEBAWsEBwULAgEIEQE?= =?us-ascii?q?CAQIoByEGCxQDBggCBA4FG4d5AwoIDrYrDYR2AQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBEQSGIYRLgkGBThEBPg2FKQWOC4NgAYEyhD8BBSsBhXeGIYF1gWeEToMphTO?= =?us-ascii?q?HTodcAR4BAUKDaGyIBjZ+AQEB?= X-IronPort-AV: E=Sophos; i="5.24,503,1454976000"; d="scan'208,217"; a="93076900" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2016 15:56:44 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3IFuiXV032676 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Apr 2016 15:56:44 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Apr 2016 10:56:43 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Mon, 18 Apr 2016 10:56:43 -0500 From: "Sri Gundavelli (sgundave)" To: Jong-Hyouk Lee Thread-Topic: [its] charter ITS - proposed work items Thread-Index: AQHRmT+qNMEnGW0uWUWMZTSYQj+ZY5+PqjmAgAAFfACAACXagIAAFUOAgAAEY4D//8BygIAAfekA//+UNYA= Date: Mon, 18 Apr 2016 15:56:43 +0000 Message-ID: References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.219] Content-Type: multipart/alternative; boundary="_000_D33A517E214FCDsgundaveciscocom_" MIME-Version: 1.0 Archived-At: Cc: Alexandre Petrescu , "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 15:56:56 -0000 --_000_D33A517E214FCDsgundaveciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jong-Hyouk, > I officially request that we should have a solution for IP prefix exchang= es as a work item. This is one specific approach. The description for the work item can be bit= more generic. Sri From: Jong-Hyouk Lee > Date: Monday, April 18, 2016 at 8:22 AM To: Sri Gundavelli > Cc: Alexandre Petrescu >, "its@ietf.org" > Subject: Re: [its] charter ITS - proposed work items Hi Sri, Just one comment regarding IP prefix exchanges. Plz see inline. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) > wrote: Alex - Inline .. To: Alexandre Petrescu > Cc: "its@ietf.org" > Subject: Re: [its] charter ITS - proposed work items ITSers, We work on a more rigorous ITS charter text. Now we propose four work items: 1. "Problem statement for IP in V2V and V2I" including "IP addressing architecture for V2V and V2I" and including "Gap Analysis: IP protocols suited and gaps" and including "Use-cases for IP in V2V and V2I moving network to nearby moving or fixed network" [Sri] Agree. This is a good starting point. Use-Cases document is needed. O= n the Gap Analysis document, it should be stated as how the gaps are captur= ed and in relation to what technology. Is it NEMO, MANET, some other protoc= ols ? 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" [Sri] If my starting point is #1, not sure how to read this ? Prefix exchan= ges appears more like a solution. In MANET there is exchange of prefixes, i= n NEMO we don't inject those prefixes and so I do not know if this work ite= m is valid at this time. You are right. That is a missing part. We need to have a solution for "IP p= refix exchanges in V2V and V2I" The need of IP prefix exchanges is clear an= d well presented in PS documents for IP in V2V and V2I. Then, there are 2 d= ocuments already existing as below: 1. https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 The above 2 documents are the early effort to establish IP direction commun= ications between vehicles and also between a vehicle and a road side unit. I officially request that we should have a solution for IP prefix exchanges= as a work item. Cheers! 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], including connectivity in fast and asymmetric conditions, coverage area vs speed diagrams, below-IP congestion management. 4. "List of papers and _products_ using IP in V2V and V2I" [Sri] Not clear what the deliverable is. What do you think? Please respond by next Monday, April 18th. _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its --_000_D33A517E214FCDsgundaveciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Jong-Hyouk,

> I officially request that we should have a solution for IP prefix= exchanges as a work item.

This is one specific approach. The description for the work item can b= e bit more generic.


Sri


From: Jong-Hyouk Lee <jonghyouk@gmail.com>
Date: Monday, April 18, 2016 at 8:2= 2 AM
To: Sri Gundavelli <sgundave@cisco.com>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com&g= t;, "its@ietf.org" <its@ietf.org>
Subject: Re: [its] charter ITS - pr= oposed work items

Hi Sri,

Just one comment regarding IP prefix exchanges. Plz see inl= ine.
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: jonghyouk@gmail.c= om
#webpage: https://sites.google.com/site/hurryon

On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) <= ;sgundave@cisco.com>= ; wrote:

Alex – Inline ..



To: Alexandre Pet= rescu <alexan= dre.petrescu@gmail.com>
Cc: "its@ietf.org" <its@ietf.org>
Subject: Re: [its= ] charter ITS - proposed work items


ITSers,

We work on a more rigorous ITS charter text.

Now we propose four work items:

1. "Problem statement for IP in V2V and V2I"
    including "IP addressing architecture for V2V and V2I"
    and including "Gap Analysis: IP protocols suited and gaps"
    and including "Use-cases for IP in V2V and V2I moving network to
                   nearby moving or fixed network"

[Sri] Agree. This=
 is a good starting point. Use-Cases document is needed. On the Gap Analysi=
s document, it should be stated as how the gaps are captured and in relatio=
n to what technology. Is it NEMO, MANET, some other protocols ? 





2. "Threat Analysis for IP prefix exchanges in V2V and V2I context&quo=
t;



[Sri] If my start=
ing point is #1, not sure how to read this ? Prefix exchanges appears more =
like a solution. In MANET there is exchange of prefixes, in NEMO we donR=
17;t inject those prefixes and so I do not know if this work item is valid =
at this time.

You are right. That is a missing part. We need to have a solution for = "IP prefix exchanges in V2V and V2I” The need of IP prefix excha= nges is clear and well presented in PS documents for IP in V2V and V2I. The= n, there are 2 documents already existing as below:

The above 2 documents are the early effort to establish IP direction c= ommunications between vehicles and also between a vehicle and a road side u= nit. 

I officially request that we should have a solution for IP prefix exch= anges as a work item.






Cheers!

3. "IP over =
DSRC (802.11-OCB)" typical IP-over-foo document[*],
    including connectivity in fast and asymmetric conditions, coverage
    area vs speed diagrams, below-IP congestion management.



4. "List of papers and _products_ using IP in V2V and V2I"

[Sri] Not clear w=
hat the deliverable is.


What do you think?

Please respond by next Monday, April 18th.

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/= mailman/listinfo/its

 --_000_D33A517E214FCDsgundaveciscocom_-- From nobody Mon Apr 18 09:11:27 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F5612E1D5 for ; Mon, 18 Apr 2016 09:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoZEnjPK3x09 for ; Mon, 18 Apr 2016 09:11:24 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A673612E1AB for ; Mon, 18 Apr 2016 09:11:24 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id u185so23944056iod.2 for ; Mon, 18 Apr 2016 09:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Wbcswsd1yG1YSI/yDzxyFcYz7+LoHK9iT53Mtsot8ic=; b=EMfa+Jru3dvBF6+J5gpqWerhJoGEedYW3PsYpKr80S7Ogvh3C2wxdUaqWKINFv2Yf3 alHov34ER5ZGZsNaCOe/ZRaxEbOBi8Ps/Q7E2XvZU03B88Im6sgv9umpV/zWtf/WZV1z 23L6QEMffx0noP11O2xGCo8yL71PHdNYKtKgBkvy9kR5ZEJW5Ybrml3GlywnY9okhhvo +ZGiXXmW8p7pZc/kJWCBBhaq76eJw318jIrx6ZOWgUGq36cY0BdW2AsKB30wrecq+5m6 4x6nT7JwYkYSo+PMDBfXaPk7w9Yd6rBG1bu1njRD2GFRt+p7VV5p5tnEGwywz3Ty+rd2 SqnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Wbcswsd1yG1YSI/yDzxyFcYz7+LoHK9iT53Mtsot8ic=; b=M2fUDtvIzGSyciOVPDDIkht4S/JE/iBGFCX2l3Cz9OHdw/LpyEGy8a2BHGIWwVXnY1 pwrBkEiAAfHIA0KWb0tqAYA8A+G9NmEGHaH+diBabWONFFHr8IDAsxyPXR7xgXxWUJ6f J7Zs21AVhYFIRhlKhstOjNR78EzqVHaUEabRS6dqN9QxaDH9UbGXz/Ix/R7hBT4cbRcL jFhUXTLYNIMGMvGosUQimofLoky6QhB1LGAJoniBpr/OV4ev482Um6fxaX3kiYFU5n0u dvlF38UCWOu+vXii62cado1rzBDJVGrDvAaGSBem67OP5WyiENj0goeHDtEdTSbbLOnn dFKA== X-Gm-Message-State: AOPr4FV6nJ+pUOazJ09yDkzZHm64gxxNhHmCRDVuAhloZ6GJ9VcO+uNV4u+6DgWH4gzSratQ/BAXWyFk6Gq51Q== MIME-Version: 1.0 X-Received: by 10.107.162.17 with SMTP id l17mr42155194ioe.42.1460995883878; Mon, 18 Apr 2016 09:11:23 -0700 (PDT) Received: by 10.79.78.213 with HTTP; Mon, 18 Apr 2016 09:11:23 -0700 (PDT) In-Reply-To: <6CE69D10-658F-4E46-ACCB-4ED46BA5577E@cisco.com> References: <6CE69D10-658F-4E46-ACCB-4ED46BA5577E@cisco.com> Date: Tue, 19 Apr 2016 00:11:23 +0800 Message-ID: From: Dapeng Liu To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a11409936ad5c310530c49cb0 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] Liaison statement: Liaison from ISO/TC204 to IETF X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 16:11:26 -0000 --001a11409936ad5c310530c49cb0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, Thanks for sending the ISO/TC204 liaison link. To ITSer: Here is the link to the slides that the liaison letter mentioned= =EF=BC=9A https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf slide number 3: >From IETF to ISO =E2=97=8F Get feedback and advices on the use of IETF prot= ocols in ISO standards (particularly IPv6, Security) slide number 13: =E2=97=8F Direct communication between ITS stations (adhoc) =E2=80=93 Gener= ically applicable IETF standard is sought on this otherwise ISO will develop its own Thanks, Dapeng Liu 2016-04-16 23:05 GMT+08:00 Carlos Pignataro (cpignata) = : > ITS, > > FYI: > Liaison from ISO/TC204 to IETF > > https://datatracker.ietf.org/liaison/1468/ > > Thanks! > > =E2=80=94 Carlos. > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --=20 ------ Best Regards, Dapeng Liu --001a11409936ad5c310530c49cb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

Thanks for sending the ISO/T= C204 liaison link.


To ITSer: Here i= s the link to the slides that the liaison letter mentioned=EF=BC=9A


slide number 3:=C2=A0
From= IETF to ISO =E2=97=8F Get feedback and advices on the use of IETF protocols in ISO standards (particularly IPv6, Security)

slide number 13:
=E2=97=8F Direct communication between ITS stat= ions (adhoc) =E2=80=93 Generically applicable IETF standard is sought on this otherwise ISO will develop its own


<= div>Thanks,
Dapeng Liu

=
2016-04-16 23:05 GMT+08:00 Carlos Pignataro (cpi= gnata) <cpignata@cisco.com>:
ITS,

FYI:
Liaison from ISO/TC204 to IETF

https://datatracker.ietf.org/liaison/1468/

Thanks!

=E2=80=94 Carlos.

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its




--

------
Best Regards,
Dapeng Liu
--001a11409936ad5c310530c49cb0-- From nobody Mon Apr 18 10:00:51 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C0112E2F4 for ; Mon, 18 Apr 2016 10:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1YSDR618O8T for ; Mon, 18 Apr 2016 10:00:47 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B4012E2F8 for ; Mon, 18 Apr 2016 10:00:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3IH0g21020698; Mon, 18 Apr 2016 19:00:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6028720A735; Mon, 18 Apr 2016 19:02:08 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5263D20A6C3; Mon, 18 Apr 2016 19:02:08 +0200 (CEST) Received: from [132.166.84.172] ([132.166.84.172]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3IH0fUU021452; Mon, 18 Apr 2016 19:00:41 +0200 To: "Sri Gundavelli (sgundave)" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> From: Alexandre Petrescu Message-ID: <571512B9.3050206@gmail.com> Date: Mon, 18 Apr 2016 19:00:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 17:00:49 -0000 Sri, Thanks for the reply. Le 18/04/2016 16:51, Sri Gundavelli (sgundave) a crit : > Alex Inline .. > > > > To: Alexandre Petrescu > Cc: "its@ietf.org > " > Subject: > Re: [its] charter ITS - proposed work items > > > ITSers, We work on a more rigorous ITS charter text. Now we propose > four work items: 1. "Problem statement for IP in V2V and V2I" > including "IP addressing architecture for V2V and V2I" and including > "Gap Analysis: IP protocols suited and gaps" and including "Use-cases > for IP in V2V and V2I moving network to nearby moving or fixed > network" > > [Sri] Agree. This is a good starting point. Use-Cases document is > needed. Noted. > On the Gap Analysis document, "Gap Analysis" would be a section, not a document, we agree. > it should be stated as how the gaps are captured and in relation to > what technology. Is it NEMO, MANET, some other protocols ? For MANET - it's AODVv2. We have gap analysis text about AODVv2. For NEMO - the 'gap analysis' perspective is that NEMO can not solve the problem: as you say, NEMO does not inject routes. _If_ there is interest about NEMO in a V2V context then we must make sure that any new solution developped by this group does not stop NEMO from working. For example, one does not want a default route present within a car to point to another car, but to point to the "NEMO tunnel", otherwise NEMO breaks. Similar principle - dont break existing protocols - may apply to other related protocols, like LISP, although recently we have been told that LISP can be completely independent of any new solution designed here. How about a PMIP gap analysis: would PMIP continue working even though vehicles were exchanging routes? Explaining that makes sense in a 'gap analysis' section. What do you think? > 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" > > [Sri] If my starting point is #1, not sure how to read this ? Prefix > exchanges appears more like a solution. Yes. > In MANET there is exchange of prefixes, Intuitively, one may think so at first. But in details: AODVv2 is not doing prefix exchange, but route discovery by sending messages to explore paths. OLSR is a way too complex protocol and implementations for the simple 1-hop topologies in V2V (e.g. OLSR 2-hop sets are useless here). For the moment we have a subsection on AODVv2 gap analysis. There is little tract (if any) in the ITS community for more MANET than just that. > in NEMO we dont inject those prefixes and so I do not know if this > work item is valid at this time. Right - with NEMO we dont inject routes, that's why we dont consider NEMO to solve the problem statement. Something else is needed. [...] Alex > > > What do you think? Please respond by next Monday, April 18th. > > From nobody Mon Apr 18 10:01:25 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C589712E303 for ; Mon, 18 Apr 2016 10:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.333 X-Spam-Level: X-Spam-Status: No, score=-4.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7z1VBCsf0HD for ; Mon, 18 Apr 2016 10:01:17 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31B112E2FB for ; Mon, 18 Apr 2016 10:01:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3IH1C4N020842; Mon, 18 Apr 2016 19:01:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 18C6520A735; Mon, 18 Apr 2016 19:02:39 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0A7A720A71F; Mon, 18 Apr 2016 19:02:39 +0200 (CEST) Received: from [132.166.84.172] ([132.166.84.172]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3IH1CMq021754; Mon, 18 Apr 2016 19:01:12 +0200 To: Jong-Hyouk Lee , "Sri Gundavelli (sgundave)" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> From: Alexandre Petrescu Message-ID: <571512D8.5000709@gmail.com> Date: Mon, 18 Apr 2016 19:01:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 17:01:25 -0000 Le 18/04/2016 17:22, Jong-Hyouk Lee a écrit : > Hi Sri, > > Just one comment regarding IP prefix exchanges. Plz see inline. > -- > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > Protocol Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com > #webpage: https://sites.google.com/site/hurryon > >> On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) >> > wrote: >> >> Alex – Inline .. >> >> >> >> To: Alexandre Petrescu > > >> Cc: "its@ietf.org " > > >> Subject: Re: [its] charter ITS - proposed work items >> >> >> ITSers, We work on a more rigorous ITS charter text. Now we propose >> four work items: 1. "Problem statement for IP in V2V and V2I" >> including "IP addressing architecture for V2V and V2I" and including >> "Gap Analysis: IP protocols suited and gaps" and including "Use-cases >> for IP in V2V and V2I moving network to nearby moving or fixed network" >> [Sri] Agree. This is a good starting point. Use-Cases document is >> needed. On the Gap Analysis document, it should be stated as how the >> gaps are captured and in relation to what technology. Is it NEMO, >> MANET, some other protocols ? >> >> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" >> [Sri] If my starting point is #1, not sure how to read this ? Prefix >> exchanges appears more like a solution. In MANET there is exchange of >> prefixes, in NEMO we don’t inject those prefixes and so I do not know >> if this work item is valid at this time. > > You are right. That is a missing part. We need to have a solution for > "IP prefix exchanges in V2V and V2I” The need of IP prefix exchanges is > clear and well presented in PS documents for IP in V2V and V2I. Then, > there are 2 documents already existing as below: > > 1. https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 > 2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 > > The above 2 documents are the early effort to establish IP direction > communications between vehicles and also between a vehicle and a road > side unit. > > I officially request that we should have a solution for IP prefix > exchanges as a work item. Noted. Alex > > Cheers! >> >> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], >> including connectivity in fast and asymmetric conditions, coverage >> area vs speed diagrams, below-IP congestion management. >> >> 4. "List of papers and _products_ using IP in V2V and V2I" >> [Sri] Not clear what the deliverable is. >> >> What do you think? Please respond by next Monday, April 18th. >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > From nobody Mon Apr 18 10:13:03 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A534412E33D for ; Mon, 18 Apr 2016 10:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.353 X-Spam-Level: X-Spam-Status: No, score=-4.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIXMnLvOnej1 for ; Mon, 18 Apr 2016 10:12:57 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4A912DCEE for ; Mon, 18 Apr 2016 10:12:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3IHCqA5022089; Mon, 18 Apr 2016 19:12:52 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B5CF320A78E; Mon, 18 Apr 2016 19:14:18 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A6B9320A7AE; Mon, 18 Apr 2016 19:14:18 +0200 (CEST) Received: from [132.166.84.80] ([132.166.84.80]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3IHCpuB025703; Mon, 18 Apr 2016 19:12:52 +0200 To: "Sri Gundavelli (sgundave)" , Jong-Hyouk Lee References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> From: Alexandre Petrescu Message-ID: <57151593.4010807@gmail.com> Date: Mon, 18 Apr 2016 19:12:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 17:13:02 -0000 Le 18/04/2016 17:56, Sri Gundavelli (sgundave) a crit : > Hi Jong-Hyouk, > > > I officially request that we should have a solution for IP prefix > exchanges as a work item. > > This is one specific approach. The description for the work item can be > bit more generic. Thanks, but I would need a title for it. How about: "Solution for 1-hop IP V2V"? "Solution to establish a 1-hop IP path between nearby moving networks or between nearby moving networks and an immediate fixed network" "Solution for Moving/Fixed Network Discovery and 1-hop Path Establishment"? "Solution for end-to-end path establishment in a star topology with 1-hop fragile core and n-hop stable edges"? Alex > > > Sri > > > From: Jong-Hyouk Lee > > Date: Monday, April 18, 2016 at 8:22 AM > To: Sri Gundavelli > > Cc: Alexandre Petrescu >, "its@ietf.org > " > > Subject: Re: [its] charter ITS - proposed work items > > Hi Sri, > > Just one comment regarding IP prefix exchanges. Plz see inline. > -- > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > Protocol Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com > #webpage: https://sites.google.com/site/hurryon > >> On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) >> > wrote: >> >> Alex Inline .. >> >> >> >> To: Alexandre Petrescu > > >> Cc: "its@ietf.org " > > >> Subject: Re: [its] charter ITS - proposed work items >> >> >> ITSers, We work on a more rigorous ITS charter text. Now we propose >> four work items: 1. "Problem statement for IP in V2V and V2I" >> including "IP addressing architecture for V2V and V2I" and including >> "Gap Analysis: IP protocols suited and gaps" and including "Use-cases >> for IP in V2V and V2I moving network to nearby moving or fixed network" >> [Sri] Agree. This is a good starting point. Use-Cases document is >> needed. On the Gap Analysis document, it should be stated as how the >> gaps are captured and in relation to what technology. Is it NEMO, >> MANET, some other protocols ? >> >> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" >> [Sri] If my starting point is #1, not sure how to read this ? Prefix >> exchanges appears more like a solution. In MANET there is exchange of >> prefixes, in NEMO we dont inject those prefixes and so I do not know >> if this work item is valid at this time. > > You are right. That is a missing part. We need to have a solution for > "IP prefix exchanges in V2V and V2I The need of IP prefix exchanges is > clear and well presented in PS documents for IP in V2V and V2I. Then, > there are 2 documents already existing as below: > > 1. https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 > 2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 > > The above 2 documents are the early effort to establish IP direction > communications between vehicles and also between a vehicle and a road > side unit. > > I officially request that we should have a solution for IP prefix > exchanges as a work item. > > > > > > > Cheers! >> >> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], >> including connectivity in fast and asymmetric conditions, coverage >> area vs speed diagrams, below-IP congestion management. >> >> 4. "List of papers and _products_ using IP in V2V and V2I" >> [Sri] Not clear what the deliverable is. >> >> What do you think? Please respond by next Monday, April 18th. >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > From nobody Mon Apr 18 15:11:34 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3A612E890 for ; Mon, 18 Apr 2016 15:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr91fTeE0iyI for ; Mon, 18 Apr 2016 15:11:27 -0700 (PDT) Received: from mail.cec.uchile.cl (mail1.cec.uchile.cl [200.9.100.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9865812E893 for ; Mon, 18 Apr 2016 15:11:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.cec.uchile.cl (Postfix) with ESMTP id 85622347688; Mon, 18 Apr 2016 19:11:21 -0300 (CLST) X-Virus-Scanned: by amavisd-new at ing.uchile.cl Received: from mail.cec.uchile.cl ([127.0.0.1]) by localhost (mail1.cec.uchile.cl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47FUElTqsa_f; Mon, 18 Apr 2016 19:11:21 -0300 (CLST) Received: from scespedesHP (186-105-102-78.baf.movistar.cl [186.105.102.78]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cec.uchile.cl (Postfix) with ESMTP id 2C08A34767C; Mon, 18 Apr 2016 19:11:20 -0300 (CLST) From: =?UTF-8?Q?Sandra_C=C3=A9spedes?= To: "'Nabil Benamar'" , "'Alexandre Petrescu'" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> In-Reply-To: Date: Mon, 18 Apr 2016 19:11:20 -0300 Organization: Universidad de Chile Message-ID: <04ae01d199bf$3d2938d0$b77baa70$@ing.uchile.cl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04AF_01D199A6.17E96E50" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFt54qCPzaRhlgKe35lrbFRjfOAYQFS/geMAQE6Hj0B9Z2NrAFvPFpVAgXLDlYCka3YAQKrpoYkn+/NvRA= Content-Language: es-cl X-Antivirus: avast! (VPS 160418-0, 18-04-2016), Outbound message X-Antivirus-Status: Clean Archived-At: Cc: its@ietf.org Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 22:11:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04AF_01D199A6.17E96E50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 Regards, Sandra C=C3=A9spedes. De: its [mailto:its-bounces@ietf.org] En nombre de Nabil Benamar Enviado el: lunes, 18 de abril de 2016 4:55 Para: Alexandre Petrescu CC: its@ietf.org Asunto: Re: [its] charter ITS - proposed work items Hi All, I agree on the current charter since these are the points discussed during = the BoF! However there were some replies in this list mentioning to probabl= y add IoT as an exemple of IP based communications. I think that we should= keep the focus on vehicular communications/networks and do not diverge fro= m this topic. IoT is fundamentally different from vehicular networks in man= y aspects such as routing, energy consumption, mac layer, etc... Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Thu, Apr 14, 2016 at 9:42 AM, Alexandre Petrescu > wrote: ITSers, We work on a more rigorous ITS charter text. Now we propose four work items: 1. "Problem statement for IP in V2V and V2I" including "IP addressing architecture for V2V and V2I" and including "Gap Analysis: IP protocols suited and gaps" and including "Use-cases for IP in V2V and V2I moving network to nearby moving or fixed network" 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], including connectivity in fast and asymmetric conditions, coverage area vs speed diagrams, below-IP congestion management. 4. "List of papers and _products_ using IP in V2V and V2I" What do you think? Please respond by next Monday, April 18th. Alex and Dapeng [*] a typical IP-over-foo document is, for example, RFC2464 "Transmission of IPv6 Packets over Ethernet Networks", where "foo" is instantiated as "Ethernet". Other IPv6-over-foo documents are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and more. Le 14/04/2016 09:42, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : Paul, Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of IP V2V = but not see the need (so far), I referred to the automotive SDOs (led by automotive industries)=E2=80=A6, although there are always =E2=80=98minority reports= =E2=80=99 J Cheers, J=C3=A9r=C3=B4me *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com ] *Sent:* Thursday 14 April 2016 09:36 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:* Alexandre Petrescu; its@ietf.org *Subject:* Re: [its] charter ITS J=C3=A9r=C3=B4me, I missed that you are also an academic person. I got it :-) I understand your points for industry activity related to vehicular networking. Your observation seems true. BTW, I will invite you to my team for the draft for a list of academic papers for V2V and V2I by a personal message. Thanks. Paul On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri >> wrote= : Hi Paul, Thanks for your feedback. Do not get me wrong, I am an academic and with my team, we also work on IP-based V2V and V2I, in particular related to mobility management with DMM, but also in the context of vehicular IoT. I just have the feeling that people are perfectly aware of the fact that IP _can_ be used for V2V and V2I, but does not =E2=80=98_need_=E2=80=99 to = be used as other solutions already perfectly fit their need. Listing papers will not change this awareness. So, as a complement to academic papers, it would help to be able to pin-point which industrial activities are using or are strongly planning (short term I mean) to use pure IPv6 system in vehicles. My feeling here is we have a different eco-system that the Automotive industry (and automotive industry-related SDO)..more likely the IoT industry=E2=80=A6and as such, we should not need to have the (direct) involvement of automotive industry in the Charter. If we can make this clear by an industry-based =E2=80=98survey=E2=80=99, that would help make t= he case for the WG. Btw, you can count on me your draft..we can add some IP-based V2V and V2I for mobility management and also IoT. Cheers, J=C3=A9r=C3=B4me *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com >] *Sent:* Thursday 14 April 2016 03:22 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [its] charter ITS Hi J=C3=A9r=C3=B4me, I have an opinion on your comment 5) below. I think that a list of high-quality papers about IP-based V2V and V2I can teach very useful lessons to software designers of IP in V2V and V2I in the industry. Multiple people are working for this IP-based V2V and V2I (including Sandra Cespedes and me) in academia and more people(including Nabil Benamar) are willing to work for this area. I think we need to utilize the list of such papers as the ground for our ITS group through a WI. Note that the draft of the list will include the summary of the main ideas of the papers. For the industry current activities for this area, I believe that you can share them as references through our ITS mailing list rather than through a WI. Could you join my team that are making efforts for a list of such papers? Thanks. Best Regards, Paul On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri >> wrote= : Dear ITSers, Dear Alex, Here are some comments on the updated charter: 1)Can we keep a reference to IEEE 802.11p, considering it does not exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of course. 2)Should we really keep C-ACC (or Platooning) in the charter explicitly as use case, considering it is a seriously controversial aspect with some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry mentions traffic efficiency/infotainment applications, such as in-signage applications... a.We might have to aim at less controversial use cases to attract automotive industries 3)One potential WI I could think of (rather a basic one): _definition of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive context_ a.To me, this is a fundamental brick in the larger IETF WG ITS house.. 4)I would suggest to be more explicit in the foreseen challenges of this WG, instead of mentioning general use case (which end up be controversial) a.Example: maintaining IPv6 connectivity in fast and asymmetric wireless links; also under quickly changing topologies (actually suggested by Dick Roy on the chat room) b.Example: IPv6 addressing in link-local scope.. c.Example: guaranteeing privacy in IPv6 moving networks etc.. 5)Before listing academic papers referring to IPv6 in vehicles, I would suggest to first try to list commercial products/solutions that are in vehicles and are using IPv6, possibly suffering from a silo limitations (ex. restricted to a single technology, single use case=E2=80=A6) a.I think we need to get to products first, before academic visions My two cents.. Best Regards, J=C3=A9r=C3=B4me *From:*its [mailto:its-bounces@ietf.org >] *On Behalf Of *Alexandre Petrescu *Sent:* Wednesday 06 April 2016 23:45 *To:* its@ietf.org > *Subject:* [its] charter ITS ITSers, Please see below the current charter. - the two Problem Statements drafts V2V and V2I joined, so there is less text in charter. - added an Item on "List of Research papers..." Erik: did I understand you correctly that there should be some item on discussing whether link-local addressing is sufficient, whether prefix exchange is necessary? Dino: should LISP be included in the gap analysis draft which includes C-ACC use-case? OR should we separate a dedicated I-D only with gap analysis including ND, MIP, AODVv2, LISP? Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle interface illustrated good enough by the words "moving network to nearby moving network communications"? Or is it better to say "the 1-IP-hop between nearby moving networks must be self-configured"? Nabil, Sandra: is it ok to have a working group item "List of Research Papers for IP in V2V and V2I communications"? Other comments? Alex ------------------------------------------------------------------ ITS (name to change) Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: WG forming Chairs: TBD Assigned Area Director: TBD Mailing list Address: its@ietf.org > 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: Goal ---- The goal of this group is to standardize IP-based protocols for establishing direct and secure connectivity between moving networks, some of which could be fixed permanently or temporarily. Moving Network to Nearby Moving Network Communications ------------------------------------------------------ The group is concerned with all situations involving moving network to nearby moving network communications. For example: vehicle-to-vehicle communications, nomadic user wearing a PAN and communicating to a homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a train, or train-to-intersection signalling. Example from the automobile communications space ------------------------------------------------ Automobiles and vehicles of all types are increasingly connected to the Internet, either as vehicle-to-vehicle, vehicle-to-infra or vehicle-to-Internet. Entertainment apps enhancing comfort, reliable data exchanges for road safety, and automated driving are features coming in automobiles to hit the roads from now to year 2020. Highlighting increased safety as an immediate result of hyper-connectivity applied to vehicles, public authorities worldwide are increasingly mandating secure communication technology requirements in vehicles. Emergency apps for new instrumented ambulances carry many benefits both to the users and to society in general. Why IP? ------- Today, there are several deployed Vehicle-to-Internet technologies, including car tethering through driver's cellular smartphone. However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are still being developed. To improve on a situation of link-specific data exchanges, and enable independent application sets to share the same links, IP data exchanges are needed. Enabling IP communication between vehicles (V2V), and between vehicles and the immediate infrastructure (V2I), will provide (0) ability to reach the rest of the world on the Internet (1) short and deterministic delays, (2) fast forwarding through scalable paths of routers, (3) ease of reuse of existing Internet applications in a vehicular environment. Moving network to nearby moving network communications involve link layers such as: 802.11p OCB (Outside the Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light Communications), IrDA, LTE-D. Only the IP protocols are capable of running on each of these links and establish IP paths across them in an interoperable manner. Scenarios? ---------- There are a few scenarios exhibiting the need to communicate from one moving network to another nearby moving network. In the automobile space, the Cooperative Adaptive Cruise Control and Platooning features consider that vehicles close to each other exchange data describing their kinematic status. At the cross-roads, the moving network inside a vehicle exchanges data with the moving network in the red-light pole. Several public safety scenarios involve moving networks. Distinct organizations deploy different moving networks (in-vehicle, on-person) at an incident scene. These networks need to interoperate in order to more effectively understand and deal with the incident scene. In connected rail scenarios the moving network deployed in trains communicate with other moving networks at the cross-points. What kind of solutions? ----------------------- The current technical solutions considered to achieve moving network to nearby moving network communications are of two kinds: IP routing protocols for n-hop path management and 1-hop link-scoped IP protocol enhancements. The 1-hop link-scoped protocols include the protocols for route establishment involving ICMP Router Advertisements. The n-hop path management protocols include n-hop path establishment protocols (e.g. Babel, OSPF) and n-hop path search protocols (most notably AODV and derivates). In this proposed Working Group the focus is on 1-hop protocols, and leverage from other Working Groups for the n-hop situations. In some of the moving network applications the window of opportunity for exchanging data with the immediate infrastructure may be very short. For example, a car driving near a road-side unit may have only 5s to exchange with that RSU (depending on speed, RSU range and number). (ephemeral connections). What kind of requirements? -------------------------- The requirements for mechanisms for moving network to nearby moving network communications are focusing on low delays of the data paths, reduced number of messages for path establishment, application friendly, resilience to attacks, compatibility with DHCP and Mobile IP. In addition, some moving network to nearby moving network applications involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the 1-hop IP moving network to nearby moving netowrk mechanisms will need to gracefully support IP multicast. Due to the inherent characteristics of safety-related communications, all new moving network to nearby moving network mechanisms must afford authenticity and confidentiality where necessary. Dynamically establishing ephemeral communication paths between automobiles in public areas must offer privacy safeguards for the end users (passengers). Establishing 1-hop IP V2V paths must not break the existing on-board protocols and applications which communicate with the Internet, possibly via multiple radios. In a moving network deployed in an automobile, typically one exit point connects the moving network to other moving networks. However, in a more general manner (and to support reliability) any new mechanism of moving network to nearby moving network communications should support multi-homing: one router to use multiple interfaces towards outside the moving network, or multiple routers. Current version of Internet protocols ------------------------------------- The group will only work on IPv6 solutions. What SDOs may need this work? ----------------------------- The requirements and standards for moving network to nearby moving network communications, often involving IPv6, and novel V2V and V2Infra concepts, are developed mainly at ISO TC204 "Intelligent Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For Vehicle-to-Internet communications, 3GPP LTE and other cellular technologies represent the long-range connectivity method; for Vehicle-to-Vehicle communications, LTE Direct is currently specified, as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning. The IEEE developed a popular link for short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V communications. Work Items ---------- - use-cases for moving network to nearby moving network communications - Problem Statement for moving network to nearby moving network communications including V2V, V2I and DNS. - Security and Privacy Requirements for moving network to nearby moving network communications - Solutions, which might include new protocols or extensions to existing protocols. With MIB. - IPv6-over foo, where foo is pertinent for moving network to nearby moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in the V2V domain, identifying which uses IP. Timeline -------- - _______________________________________________ its mailing list its@ietf.org > https://www.ietf.org/mailman/listinfo/its -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its --- El software de antivirus Avast ha analizado este correo electr=C3=B3nico en= busca de virus. https://www.avast.com/antivirus ------=_NextPart_000_04AF_01D199A6.17E96E50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

+1

 

Regards,

= Sandra C=C3=A9spedes.

=

 

De: its [mailto:its-bounces@ietf= =2Eorg] En nombre de Nabil Benamar
Enviado el: lunes, 18 d= e abril de 2016 4:55
Para: Alexandre Petrescu <alexandre.petre= scu@gmail.com>
CC: its@ietf.org
Asunto: Re: [its] ch= arter ITS - proposed work items

<= o:p> 

Hi All,

<= div>

 

I agree on the= current charter since these are the points discussed during the BoF! Howev= er there were some replies in this list mentioning to probably add IoT as a= n exemple of IP based communications.  I think that we should keep the= focus on vehicular communications/networks and do not diverge from this to= pic. IoT is fundamentally different from vehicular networks in many aspects= such as routing, energy consumption, mac layer, etc...


Best regards=

Nabil Benamar

-------------------<= /p>

=D9=86=D8=A8=D9=8A= =D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88

 = ;

On Thu, Apr 14, 2016 at 9:42 AM, Alexa= ndre Petrescu <alexandre.petrescu@gmail.com> wrote:

ITSers,
We work on a more rigorous ITS charter text.

Now we propose fou= r work items:

1. "Problem statement for IP in V2V and V2I"=
   including "IP addressing architecture for V2V and V2I= "
   and including "Gap Analysis: IP protocols suite= d and gaps"
   and including "Use-cases for IP in V2= V and V2I moving network to
            &n= bsp;     nearby moving or fixed network"

2. "Thr= eat Analysis for IP prefix exchanges in V2V and V2I context"

3.= "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*],
=    including connectivity in fast and asymmetric conditions, cove= rage
   area vs speed diagrams, below-IP congestion management= =2E

4. "List of papers and _products_ using IP in V2V and V2I&q= uot;

What do you think?

Please respond by next Monday, April = 18th.

Alex and Dapeng
[*] a typical IP-over-foo document is, for = example, RFC2464
    "Transmission of IPv6 Packets over E= thernet Networks", where
    "foo" is instantia= ted as "Ethernet".  Other IPv6-over-foo documents
  =   are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over P= PP" and more.

Le 14/04/2016 09:42, J=C3=A9r=C3=B4me H=C3=A4rri = a =C3=A9crit :

Paul,

Than= ks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of IP V2V but = not see
the need (so far), I referred to the automotive SDOs (led by aut= omotive
industries)=E2=80=A6, although there are always =E2=80=98minorit= y reports=E2=80=99 J

Cheers,

J=C3=A9r=C3=B4me

*From:*M= r. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com]
*Sent:* Thursday 14 April 201= 6 09:36
*To:* J=C3=A9r=C3=B4me H=C3=A4rri
*Cc:* Alexandre Petrescu; <= a href=3D"mailto:its@ietf.org" target=3D"_blank">its@ietf.org
*Subje= ct:* Re: [its] charter ITS

J=C3=A9r=C3=B4me,

I missed that yo= u are also an academic person.

I got it :-)

I understand your= points for industry activity related to vehicular
networking.

Yo= ur observation seems true.

BTW, I will invite you to my team for the= draft for a list of academic
papers for V2V and V2I

by a persona= l message.

Thanks.

Paul

On Thu, Apr 14, 2016 at 4:09 P= M, J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr
<mailto:jerome.haerri@eurecom.f= r>> wrote:

Hi Paul,

Thanks for your feedback. Do no= t get me wrong, I am an academic and with
my team, we also work on IP-ba= sed V2V and V2I, in particular related to
mobility management with DMM, = but also in the context of vehicular IoT.

I just have the feeling th= at people are perfectly aware of the fact that
IP _can_ be used for V2V = and V2I, but does not =E2=80=98_need_=E2=80=99 to be used as
other solut= ions already perfectly fit their need. Listing papers will
not change th= is awareness.

So, as a complement to academic papers, it would help = to be able to
pin-point which industrial activities are using or are str= ongly planning
(short term I mean) to use pure IPv6 system in vehicles.<= br>
My feeling here is we have a different eco-system that the Automotiv= e
industry (and automotive industry-related SDO)..more likely the IoTindustry=E2=80=A6and as such, we should not need to have the (direct)
i= nvolvement of automotive industry in the Charter. If we can make this
cl= ear by an industry-based =E2=80=98survey=E2=80=99, that would help make the= case for
the WG.

Btw, you can count on me your draft..we can add= some IP-based V2V and
V2I for mobility management and also IoT.

= Cheers,

J=C3=A9r=C3=B4me

*From:*Mr. Jaehoon Paul Jeong [mailt= o:jaehoon.paul@= gmail.com
<mailto:jaehoon.paul@gmail.com>]
*Sent:* Thursday 14 April 2= 016 03:22
*To:* J=C3=A9r=C3=B4me H=C3=A4rri
*Cc:* Alexandre Petrescu;= its@ietf.org <mai= lto:its@ietf.org><= br>*Subject:* Re: [its] charter ITS

Hi J=C3=A9r=C3=B4me,

I ha= ve an opinion on your comment 5) below.

I think that a list of high-= quality papers about IP-based V2V and V2I

can teach very useful less= ons to software designers of IP in V2V and V2I

in the industry.
<= br>Multiple people are working for this IP-based V2V and V2I

(includ= ing Sandra Cespedes and me) in academia and

more people(including Na= bil Benamar) are willing to work for this area.

I think we need to u= tilize the list of such papers as the ground for our
ITS group

th= rough a WI. Note that the draft of the list will include the summary
of = the main

ideas of the papers.

For the industry current activi= ties for this area, I believe that you
can share them

as referenc= es through our ITS mailing list rather than through a WI.

Could you = join my team that are making efforts for a list of such papers?

Than= ks.

Best Regards,

Paul

On Thu, Apr 7, 2016 at 8:11 AM,= J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr
<mailto:jerome.haerri@eurecom.fr<= /a>>> wrote:

Dear ITSers,  Dear Alex,

Here are som= e comments on the updated charter:

1)Can we keep a reference to IEEE= 802.11p, considering it does not exist
anymore? It is now fully integra= ted into IEEE 802.11-2012 as OCB mode
(and 10Mhz @5.9Ghz) of course.
=
2)Should we really keep C-ACC (or Platooning) in the charter explicitly=
as use case, considering it is a seriously controversial aspect withsome SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry
me= ntions traffic efficiency/infotainment applications, such as
in-signage = applications...

a.We might have to aim at less controversial use cas= es to attract
automotive industries

3)One potential WI I could th= ink of (rather a basic one): _definition of
a vehicular wireless =E2=80= =98link=E2=80=99 in an automotive context_

a.To me, this is  a = fundamental brick in the larger IETF WG ITS house..

4)I would sugges= t to be more explicit in the foreseen challenges of this
WG, instead of = mentioning general use case (which end up be controversial)

a.Exampl= e: maintaining IPv6 connectivity in fast and asymmetric wireless
links; = also under quickly changing topologies (actually suggested by
Dick Roy o= n the chat room)

b.Example: IPv6 addressing in link-local scope..
c.Example: guaranteeing privacy in IPv6 moving networks etc..

5= )Before listing academic papers referring to IPv6 in vehicles, I would
s= uggest to first try to list commercial products/solutions that are in
ve= hicles and are using IPv6, possibly suffering from a silo limitations
(e= x. restricted to a single technology, single use case=E2=80=A6)

a.I = think we need to get to products first, before academic visions

My t= wo cents..

Best Regards,

J=C3=A9r=C3=B4me

*From:*its [= mailto:its-bounce= s@ietf.org <mailto:its-bounces@ietf.org>]
*On Behalf Of *Alexandre Petrescu=
*Sent:* Wednesday 06 April 2016 23:45
*To:* its@ietf.org <mailto:its@ietf.org>
*Subject:* [its] chart= er ITS

ITSers,

Please see below the current charter.

-= the two Problem Statements drafts V2V and V2I joined, so there is less
= text in charter.
- added an Item on "List of Research papers...&quo= t;

Erik: did I understand you correctly that there should be some it= em on
discussing whether link-local addressing is sufficient, whether pr= efix
exchange is necessary?

Dino: should LISP be included in the = gap analysis draft which includes
C-ACC use-case?  OR should we sep= arate a dedicated I-D only with gap
analysis including ND, MIP, AODVv2, = LISP?

Person from mediatek: is the 'zeroconf' need in the vehicle-to= -vehicle
interface illustrated good enough by the words "moving net= work to nearby
moving network communications"?  Or is it bette= r to say "the 1-IP-hop
between nearby moving networks must be self-= configured"?

Nabil, Sandra: is it ok to have a working group it= em "List of Research
Papers for IP in V2V and V2I communications&qu= ot;?

Other comments?

Alex

----------------------------= --------------------------------------

        &= nbsp;     ITS (name to change)
        &nb= sp;           Charter
      &nbs= p;       April 6th, 2016
http://ietf.org/mailman/listinfo/its=


Intelligent Transportation Systems (its)
-------------------= ---------------------
Current Status: WG forming

Chairs:
 = ;   TBD

Assigned Area Director:
    TBD

Mai= ling list
    Address: its@ietf.org <mailto:its@ietf.org>
    To Subscribe: https://ww= w.ietf.org/mailman/listinfo/its
    Archive:
http://www.ietf.org/mail-archive/web/its/current/maillist.html<= br>
Additional web page
    TBD

Charter:

Goal=
----
The goal of this group is to standardize IP-based protocols for=
establishing direct and secure connectivity between moving networks,some of which could be fixed permanently or temporarily.

Moving Net= work to Nearby Moving Network Communications
---------------------------= ---------------------------
The group is concerned with all situations i= nvolving moving network to
nearby moving network communications.  F= or example: vehicle-to-vehicle
communications, nomadic user wearing a PA= N and communicating to a
homenet, vehicle-to-infrastructure communicatio= ns, wagon-to-wagon in a
train, or train-to-intersection signalling.
<= br>Example from the automobile communications space
--------------------= ----------------------------
Automobiles and vehicles of all types are i= ncreasingly connected to
the Internet, either as vehicle-to-vehicle, veh= icle-to-infra or
vehicle-to-Internet.  Entertainment apps enhancing= comfort, reliable
data exchanges for road safety, and automated driving= are features
coming in automobiles to hit the roads from now to year 20= 20.
Highlighting increased safety as an immediate result of
hyper-con= nectivity applied to vehicles, public authorities worldwide
are increasi= ngly mandating secure communication technology
requirements in vehicles.=

Emergency apps for new instrumented ambulances carry many benefits<= br>both to the users and to society in general.

Why IP?
-------Today, there are several deployed Vehicle-to-Internet technologies,
in= cluding car tethering through driver's cellular smartphone.
However, Veh= icle-to-Vehicle and Vehicle-to-Infrastructure
communications are still b= eing developed.  To improve on a situation
of link-specific data ex= changes, and enable independent application
sets to share the same links= , IP data exchanges are needed.  Enabling
IP communication between = vehicles (V2V), and between vehicles and the
immediate infrastructure (V= 2I), will provide (0) ability to reach the
rest of the world on the Inte= rnet (1) short and deterministic delays,
(2) fast forwarding through sca= lable paths of routers, (3) ease of
reuse of existing Internet applicati= ons in a vehicular environment.

Moving network to nearby moving netw= ork communications involve link
layers such as: 802.11p OCB (Outside the= Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC (= Visible Light
Communications), IrDA, LTE-D.  Only the IP protocols = are capable of
running on each of these links and establish IP paths acr= oss them in
an interoperable manner.

Scenarios?
----------
= There are a few scenarios exhibiting the need to communicate from one
mo= ving network to another nearby moving network.

In the automobile spa= ce, the Cooperative Adaptive Cruise Control and
Platooning features cons= ider that vehicles close to each other
exchange data describing their ki= nematic status.  At the cross-roads,
the moving network inside a ve= hicle exchanges data with the moving
network in the red-light pole.
<= br>Several public safety scenarios involve moving networks.  Distinct<= br>organizations deploy different moving networks (in-vehicle, on-person)at an incident scene.  These networks need to interoperate in order = to
more effectively understand and deal with the incident scene.

= In connected rail scenarios the moving network deployed in trains
commun= icate with other moving networks at the cross-points.

What kind of s= olutions?
-----------------------
The current technical solutions con= sidered to achieve moving network
to nearby moving network communication= s are of two kinds: IP routing
protocols for n-hop path management and 1= -hop link-scoped IP protocol
enhancements.  The 1-hop link-scoped p= rotocols include the protocols
for route establishment involving ICMP Ro= uter Advertisements.  The
n-hop path management protocols include n= -hop path establishment
protocols (e.g. Babel, OSPF) and n-hop path sear= ch protocols (most
notably AODV and derivates).

In this proposed = Working Group the focus is on 1-hop protocols, and
leverage from other W= orking Groups for the n-hop situations.

In some of the moving networ= k applications the window of opportunity
for exchanging data with the im= mediate infrastructure may be very
short.  For example, a car drivi= ng near a road-side unit may have only
5s to exchange with that RSU (dep= ending on speed, RSU range and
number). (ephemeral connections).

= What kind of requirements?
--------------------------
The requirement= s for mechanisms for moving network to nearby moving
network communicati= ons are focusing on low delays of the data paths,
reduced number of mess= ages for path establishment, application
friendly, resilience to attacks= , compatibility with DHCP and Mobile
IP.

In addition, some moving= network to nearby moving network applications
involve IP multicast mech= anisms (e.g. virtual siren); thus C-ACC the
1-hop IP moving network to n= earby moving netowrk mechanisms will need
to gracefully support IP multi= cast.

Due to the inherent characteristics of safety-related communic= ations,
all new moving network to nearby moving network mechanisms must = afford
authenticity and confidentiality where necessary.  Dynamical= ly
establishing ephemeral communication paths between automobiles in
= public areas must offer privacy safeguards for the end users
(passengers= ).

Establishing 1-hop IP V2V paths must not break the existing on-bo= ard
protocols and applications which communicate with the Internet,
p= ossibly via multiple radios.

In a moving network deployed in an auto= mobile, typically one exit
point connects the moving network to other mo= ving networks.  However,
in a more general manner (and to support r= eliability) any new
mechanism of moving network to nearby moving network= communications
should support multi-homing: one router to use multiple = interfaces
towards outside the moving network, or multiple routers.
<= br>Current version of Internet protocols
-------------------------------= ------
The group will only work on IPv6 solutions.

What SDOs may = need this work?
-----------------------------
The requirements and st= andards for moving network to nearby moving
network communications, ofte= n involving IPv6, and novel V2V and
V2Infra concepts, are developed main= ly at ISO TC204 "Intelligent
Transport Systems", 3GPP, ETSI, N= HTSA and IEEE.  For
Vehicle-to-Internet communications, 3GPP LTE an= d other cellular
technologies represent the long-range connectivity meth= od; for
Vehicle-to-Vehicle communications, LTE Direct is currently speci= fied,
as well as OCB mode of IEEE 802.11.  Several use-cases exhibi= t a need
for IPv6 data exchanges between vehicles: ETSI's Cooperative Ad= aptive
Cruise Control and Platooning.  The IEEE developed a popular= link for
short-range communications - IEEE 802.11p "WAVE".&nb= sp; The NHTSA wrote a
set of requirements for V2V communications.
Work Items
----------
- use-cases for moving network to nearby movin= g network communications
- Problem Statement for moving network to nearb= y moving network
communications
   including V2V, V2I and D= NS.
- Security and Privacy Requirements for moving network to
  =  nearby moving network communications
- Solutions, which might incl= ude new protocols or extensions to
   existing protocols. = ; With MIB.
- IPv6-over foo, where foo is pertinent for moving network t= o nearby
   moving network communications (e.g. 802.11 OCB, VL= C, LTE-D, 802.11ad)
- List of Research Papers in the V2V domain, identif= ying which uses IP.

Timeline
--------
-


___________= ____________________________________
its mailing list
its@ietf.org <mailto:its@ietf.org>
https://www.ietf= =2Eorg/mailman/listinfo/its



--

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaeh= oon (Paul) Jeong, Ph.D.
Assistant Professor
Department of SoftwareSungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com= >,
paulje= ong@skku.edu <mailto:pauljeong@skku.edu>
Personal Homepage: http://iotlab.= skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/peop= le-jaehoon-jeong.php>



--

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon= (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Su= ngkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>,
pauljeong= @skku.edu <mailto:pauljeong@skku.edu>
Personal Homepage: http://iotlab.skk= u.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-= jaehoon-jeong.php>

<= br>_______________________________________________
its mailing list
<= a href=3D"mailto:its@ietf.org" target=3D"_blank">its@ietf.org
https://w= ww.ietf.org/mailman/listinfo/its

 



3D"Avast

El software de antivirus Avast ha analizado este correo electr=C3=B3nic= o en busca de virus.
www.avast.= com


------=_NextPart_000_04AF_01D199A6.17E96E50-- From nobody Mon Apr 18 15:51:13 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F08312E8D3 for ; Mon, 18 Apr 2016 15:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmWzFQwu7Cvn for ; Mon, 18 Apr 2016 15:51:10 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB9012E86E for ; Mon, 18 Apr 2016 15:51:10 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id p185so13789307pfb.3 for ; Mon, 18 Apr 2016 15:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=QBA8PDsVuOHRG3Rll4hThMUMclsu9OC7ShP8qbjixNA=; b=W1zocHzwlS87ucjR32Mwqh4WZ1NBSkx7pvORP4ppVNJSWulOHyGlIr1iB6pE8Eo7Hw iOf8o54NIflTq1dJZEGTFL+ZWS3vnopFYkGDWEejdUyq7xj8SlWURtvQWKeQYBkZuqVj 0SbsxxD3Vo2o+vaW0VuTD0l9GneAcPB1dr4EL80FVbOTqSKUGqeX2wNkCoPrXR/XcYIk ekJ00peHPwx5GsHrKBDxMFyDHpzJfORMao3PARsBX4B1rFqIne0eKNT18lEhxeBnivy1 jk0TIgQ12GenEjjYBcffejxYG1J9BOYgwX190SlG10IXWJUUnNihRHjdf3l+hsmQcFaD 39mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=QBA8PDsVuOHRG3Rll4hThMUMclsu9OC7ShP8qbjixNA=; b=kE1qc5RHSYaNWjRYq17PeWClOc3AU58VBdadXiaT7NFzGps+rQzhIvsywXWCsPWuoM ElQ1PvGE4R13W/ukBlQFFw2fQ+3Sz3WnoLeEZdAxoJ7F75wp0tYXZp9owBkOBGTbRHVe Ft9BtxD+4EGFaUjxREfyuh8CwNczTixiatou5ZKnGMiKy99BdT85CsTRDQLOzINO8Ca4 s4gYHgjttmMB/VPRW/fl6/YMirZMR4EF+KzQK6SG4RG4P3qWByQhGnug2uERGaj5aqEG HfIDEiMgvJrd4On+ZvN5esrpPetrHvaE1DYRekBCBu1YCpaW/TrjwN0Rkg7J0otHOkXF J7jw== X-Gm-Message-State: AOPr4FXAiLG4eQJPz1c+P9tN5pOPq/7b2uHnHUCexdBJ/PbLVrUrd+uZJNECVEBwzorYKw== X-Received: by 10.98.28.206 with SMTP id c197mr28221398pfc.131.1461019870078; Mon, 18 Apr 2016 15:51:10 -0700 (PDT) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id f12sm86002021pfd.87.2016.04.18.15.51.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Apr 2016 15:51:09 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_DAB051E1-FCB7-4BD4-AF13-518404BFB729" From: Jong-Hyouk Lee In-Reply-To: <57151593.4010807@gmail.com> Date: Tue, 19 Apr 2016 07:51:06 +0900 Message-Id: References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> To: Alexandre Petrescu , Thierry Ernst X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "its@ietf.org" , "Sri Gundavelli \(sgundave\)" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 22:51:12 -0000 --Apple-Mail=_DAB051E1-FCB7-4BD4-AF13-518404BFB729 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Alex, -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 19, 2016, at 2:12 AM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 18/04/2016 17:56, Sri Gundavelli (sgundave) a =E9crit : >> Hi Jong-Hyouk, >>=20 >> > I officially request that we should have a solution for IP prefix >> exchanges as a work item. >>=20 >> This is one specific approach. The description for the work item can = be >> bit more generic. >=20 > Thanks, but I would need a title for it. >=20 > How about: >=20 > "Solution for 1-hop IP V2V"? >=20 > "Solution to establish a 1-hop IP path between nearby moving networks = or between nearby moving networks and an immediate fixed network" >=20 > "Solution for Moving/Fixed Network Discovery and 1-hop Path > Establishment"? >=20 > "Solution for end-to-end path establishment in a star topology > with 1-hop fragile core and n-hop stable edges=94? We may refer the ISO/TC204 liaison link: = https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf As presented at the slide #13 above: ISO/TC204 calls "Direct = communication between ITS stations=94 Its need has been well presented = and as expressed at the slides, ISO/TC204 says=85"Generically applicable = IETF standard is sought on this otherwise ISO will develop its own=94 = Thierry would have a better idea. Let me him in this loop. Note that the request of the development of a solution for direct = communication between ITS stations has a long history and as you may = know because of this request the mnpp protocol = (https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 = ) was developed as = a result of FP7 EU project, Geonet (design and development of = Geoneworking over IPv6). At that time, there was no place to make it as = RFC at the IETF due to not matured ITS activities at the IETF. Cheers. >=20 > Alex >=20 >>=20 >>=20 >> Sri >>=20 >>=20 >> From: Jong-Hyouk Lee > >> Date: Monday, April 18, 2016 at 8:22 AM >> To: Sri Gundavelli > >> Cc: Alexandre Petrescu > >, "its@ietf.org >> " > >> Subject: Re: [its] charter ITS - proposed work items >>=20 >> Hi Sri, >>=20 >> Just one comment regarding IP prefix exchanges. Plz see inline. >> -- >> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >> Protocol Engineering Lab., Sangmyung University >>=20 >> #email: jonghyouk@gmail.com >> #webpage: https://sites.google.com/site/hurryon >>=20 >>> On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) >>> > wrote: >>>=20 >>> Alex =96 Inline .. >>>=20 >>>=20 >>>=20 >>> To: Alexandre Petrescu >> > >>> Cc: "its@ietf.org " >> > >>> Subject: Re: [its] charter ITS - proposed work items >>>=20 >>>=20 >>> ITSers, We work on a more rigorous ITS charter text. Now we propose >>> four work items: 1. "Problem statement for IP in V2V and V2I" >>> including "IP addressing architecture for V2V and V2I" and including >>> "Gap Analysis: IP protocols suited and gaps" and including = "Use-cases >>> for IP in V2V and V2I moving network to nearby moving or fixed = network" >>> [Sri] Agree. This is a good starting point. Use-Cases document is >>> needed. On the Gap Analysis document, it should be stated as how the >>> gaps are captured and in relation to what technology. Is it NEMO, >>> MANET, some other protocols ? >>>=20 >>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" >>> [Sri] If my starting point is #1, not sure how to read this ? Prefix >>> exchanges appears more like a solution. In MANET there is exchange = of >>> prefixes, in NEMO we don=92t inject those prefixes and so I do not = know >>> if this work item is valid at this time. >>=20 >> You are right. That is a missing part. We need to have a solution for >> "IP prefix exchanges in V2V and V2I=94 The need of IP prefix = exchanges is >> clear and well presented in PS documents for IP in V2V and V2I. Then, >> there are 2 documents already existing as below: >>=20 >> 1. = https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 >> 2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 >>=20 >> The above 2 documents are the early effort to establish IP direction >> communications between vehicles and also between a vehicle and a road >> side unit. >>=20 >> I officially request that we should have a solution for IP prefix >> exchanges as a work item. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Cheers! >>>=20 >>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], >>> including connectivity in fast and asymmetric conditions, coverage >>> area vs speed diagrams, below-IP congestion management. >>>=20 >>> 4. "List of papers and _products_ using IP in V2V and V2I" >>> [Sri] Not clear what the deliverable is. >>>=20 >>> What do you think? Please respond by next Monday, April 18th. >>>=20 >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>=20 --Apple-Mail=_DAB051E1-FCB7-4BD4-AF13-518404BFB729 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Alex,
--
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Apr 19, 2016, at 2:12 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:



Le 18/04/2016 17:56, Sri Gundavelli (sgundave) = a =E9crit :
Hi = Jong-Hyouk,

> I officially request that = we should have a solution for IP prefix
exchanges as a = work item.

This is one specific approach. = The description for the work item can be
bit more = generic.

Thanks, but I would = need a title for it.

How about:

"Solution for 1-hop IP V2V"?

"Solution to establish a 1-hop IP path between nearby moving = networks or between nearby moving networks and an immediate fixed = network"

"Solution for Moving/Fixed Network = Discovery and 1-hop Path
Establishment"?

"Solution for end-to-end path establishment in a star = topology
with 1-hop fragile core and n-hop stable = edges=94?



Note that = the request of the development of a solution for direct communication = between ITS stations has a long history and as you may know because of = this request the mnpp protocol (https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00) was = developed as a result of FP7 EU project, Geonet (design and development = of Geoneworking over IPv6). At that time, there was no place to make it = as RFC at the IETF due to not matured ITS activities at the = IETF.

Cheers.


Alex



Sri


From: Jong-Hyouk Lee <jonghyouk@gmail.com = <mailto:jonghyouk@gmail.com>>
Date: = Monday, April 18, 2016 at 8:22 AM
To: Sri Gundavelli = <sgundave@cisco.com <mailto:sgundave@cisco.com>>
Cc: = Alexandre Petrescu <alexandre.petrescu@gmail.com
<mailto:alexandre.petrescu@gmail.com>>, "its@ietf.org
<mailto:its@ietf.org>" <its@ietf.org <mailto:its@ietf.org>>Subject: Re: [its] charter ITS - proposed work items

Hi Sri,

Just one = comment regarding IP prefix exchanges. Plz see inline.
--Jong-Hyouk Lee, living somewhere between /dev/null and = /dev/random
Protocol Engineering Lab., Sangmyung = University

#email: jonghyouk@gmail.com = <mailto:jonghyouk@gmail.com>
#webpage: https://sites.google.com/site/hurryon

On Apr 18, 2016, at = 11:51 PM, Sri Gundavelli (sgundave)
<sgundave@cisco.com = <mailto:sgundave@cisco.com>> wrote:

Alex =96 Inline ..



To: Alexandre Petrescu <alexandre.petrescu@gmail.com
<mailto:alexandre.petrescu@gmail.com>>
Cc: "its@ietf.org <mailto:its@ietf.org>" <its@ietf.org
<mailto:its@ietf.org>>
Subject: Re: = [its] charter ITS - proposed work items


ITSers, We work on a more rigorous ITS charter text. Now we = propose
four work items: 1. "Problem statement for IP in = V2V and V2I"
including "IP addressing architecture for V2V = and V2I" and including
"Gap Analysis: IP protocols suited = and gaps" and including "Use-cases
for IP in V2V and V2I = moving network to nearby moving or fixed network"
[Sri] = Agree. This is a good starting point. Use-Cases document is
needed. On the Gap Analysis document, it should be stated as = how the
gaps are captured and in relation to what = technology. Is it NEMO,
MANET, some other protocols ?

2. "Threat Analysis for IP prefix exchanges in = V2V and V2I context"
[Sri] If my starting point is #1, not = sure how to read this ? Prefix
exchanges appears more like = a solution. In MANET there is exchange of
prefixes, in = NEMO we don=92t inject those prefixes and so I do not know
if this work item is valid at this time.

You are right. That is a missing = part. We need to have a solution for
"IP prefix exchanges = in V2V and V2I=94 The need of IP prefix exchanges is
clear = and well presented in PS documents for IP in V2V and V2I. Then,
there are 2 documents already existing as below:

1. https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-ro= uting-00
2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00

The above 2 documents are the early effort to = establish IP direction
communications between vehicles and = also between a vehicle and a road
side unit.

I officially request that we should have a = solution for IP prefix
exchanges as a work item.





Cheers!

3. "IP over DSRC (802.11-OCB)" typical = IP-over-foo document[*],
including connectivity in fast = and asymmetric conditions, coverage
area vs speed = diagrams, below-IP congestion management.

4. = "List of papers and _products_ using IP in V2V and V2I"
[Sri] Not clear what the deliverable is.

What do you think? Please respond by next Monday, April = 18th.

_______________________________________________
its mailing list
its@ietf.org <mailto:its@ietf.org>
https://www.ietf.org/mailman/listinfo/its


= --Apple-Mail=_DAB051E1-FCB7-4BD4-AF13-518404BFB729-- From nobody Tue Apr 19 00:26:13 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1460912E9DC for ; Tue, 19 Apr 2016 00:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI-IybHKlU9Y for ; Tue, 19 Apr 2016 00:26:07 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD9D12EA5D for ; Tue, 19 Apr 2016 00:26:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,505,1454972400"; d="png'150?scan'150,208,217,150";a="3690631" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 19 Apr 2016 09:26:04 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 316C59F7; Tue, 19 Apr 2016 09:26:04 +0200 (CEST) From: =?UTF-8?Q?_J=C3=A9r=C3=B4me_H=C3=A4rri_=28EURECOM=29_?= To: "'Nabil Benamar'" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <04ae01d199bf$3d2938d0$b77baa70$@ing.uchile.cl> In-Reply-To: <04ae01d199bf$3d2938d0$b77baa70$@ing.uchile.cl> Date: Tue, 19 Apr 2016 09:26:03 +0200 Organization: EURECOM Message-ID: <004b01d19a0c$bb4632c0$31d29840$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_004C_01D19A1D.7EDD5AA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt54qCPzaRhlgKe35lrbFRjfOAYQFS/geMAQE6Hj0B9Z2NrAFvPFpVAgXLDlYCka3YAQKrpoYkAR0RobsB5OhxTQ== Content-Language: en-us Archived-At: Cc: 'Alexandre Petrescu' , its@ietf.org, =?UTF-8?Q?'Sandra_C=C3=A9spedes'?= Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 07:26:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004C_01D19A1D.7EDD5AA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_004D_01D19A1D.7EDD5AA0" ------=_NextPart_001_004D_01D19A1D.7EDD5AA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Nabil, Dear All, =20 I am one of the supporters of having IoT in the charter, and I disagree = with your statement on IoT.=20 =20 There are plenty of interpretation of what IoT is or is not...the same = stands for vehicular communications... =20 IoT will be transiting via vehicular communication - we have a testbed, = where IoT traffic from embedded sensors (CAN or non-CAN) are sent to an = IoT server on Internet via ITS-G5/DSRC communication. IoT here is the = architecture (oneM2M) that is above a specific technology, not a = technology itself (you are maybe referring to SigFox or LTE-sensors I = guess)..so, our system works if we use another technology and would even = need to work if we have multiple technologies on the path between the = sensors and the =E2=80=98cloud=E2=80=99=E2=80=A6here, IPv6 take all of = its sense. =20 The IoT differences in =E2=80=98routing, energy consumption, mac = layer=E2=80=99 as you said are actually either fully relevant to the = charter, as referring to IPv6-over-foo or fully irrelevant to IPv6 (as = based on IoT application-level traffic).=20 =20 Instead of debating whether we should add IoT or keep vehicular = communication, we should debate of what kind of traffic (M2M-like, = stream?, unicast/multicast etc..) will be transiting through IPv6 = communication from a =E2=80=98vehicle=E2=80=99 to either Internet or = another =E2=80=98vehicle=E2=80=99.=20 =20 And I would like to mention that my suggestion is not to reduce the = focus, but actually to focus on an aspect, where IPv6 does not have a = competitor and can really make a difference. Said simple: if the charter addresses primarily IPv6 for critical safety = communications, this will be difficult to sell, as other simpler = solutions already work without IPv6.=20 =20 I would therefore support and even propose to have a draft formulating = the problem related to =E2=80=9CIoT-over-IPv6 on moving = networks=E2=80=9D.=20 =20 Best Regards, =20 J=C3=A9r=C3=B4me =20 Envoy=C3=A9 de mon iPad =20 =20 De: its [ mailto:its-bounces@ietf.org] En = nombre de Nabil Benamar Enviado el: lunes, 18 de abril de 2016 4:55 Para: Alexandre Petrescu < = alexandre.petrescu@gmail.com> CC: its@ietf.org Asunto: Re: [its] charter ITS - proposed work items =20 Hi All, =20 I agree on the current charter since these are the points discussed = during the BoF! However there were some replies in this list mentioning = to probably add IoT as an exemple of IP based communications. I think = that we should keep the focus on vehicular communications/networks and = do not diverge from this topic. IoT is fundamentally different from = vehicular networks in many aspects such as routing, energy consumption, = mac layer, etc... Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 =20 http://nabilbenamar.ipv6-lab.net/ =20 On Thu, Apr 14, 2016 at 9:42 AM, Alexandre Petrescu = wrote: ITSers, We work on a more rigorous ITS charter text. Now we propose four work items: 1. "Problem statement for IP in V2V and V2I" including "IP addressing architecture for V2V and V2I" and including "Gap Analysis: IP protocols suited and gaps" and including "Use-cases for IP in V2V and V2I moving network to nearby moving or fixed network" 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], including connectivity in fast and asymmetric conditions, coverage area vs speed diagrams, below-IP congestion management. 4. "List of papers and _products_ using IP in V2V and V2I" What do you think? Please respond by next Monday, April 18th. Alex and Dapeng [*] a typical IP-over-foo document is, for example, RFC2464 "Transmission of IPv6 Packets over Ethernet Networks", where "foo" is instantiated as "Ethernet". Other IPv6-over-foo documents are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and more. Le 14/04/2016 09:42, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : Paul, Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of IP = V2V but not see the need (so far), I referred to the automotive SDOs (led by automotive industries)=E2=80=A6, although there are always =E2=80=98minority = reports=E2=80=99 J Cheers, J=C3=A9r=C3=B4me *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] *Sent:* Thursday 14 April 2016 09:36 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:* Alexandre Petrescu; its@ietf.org *Subject:* Re: [its] charter ITS J=C3=A9r=C3=B4me, I missed that you are also an academic person. I got it :-) I understand your points for industry activity related to vehicular networking. Your observation seems true. BTW, I will invite you to my team for the draft for a list of academic papers for V2V and V2I by a personal message. Thanks. Paul On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri = > wrote: Hi Paul, Thanks for your feedback. Do not get me wrong, I am an academic and with my team, we also work on IP-based V2V and V2I, in particular related to mobility management with DMM, but also in the context of vehicular IoT. I just have the feeling that people are perfectly aware of the fact that IP _can_ be used for V2V and V2I, but does not =E2=80=98_need_=E2=80=99 = to be used as other solutions already perfectly fit their need. Listing papers will not change this awareness. So, as a complement to academic papers, it would help to be able to pin-point which industrial activities are using or are strongly planning (short term I mean) to use pure IPv6 system in vehicles. My feeling here is we have a different eco-system that the Automotive industry (and automotive industry-related SDO)..more likely the IoT industry=E2=80=A6and as such, we should not need to have the (direct) involvement of automotive industry in the Charter. If we can make this clear by an industry-based =E2=80=98survey=E2=80=99, that would help = make the case for the WG. Btw, you can count on me your draft..we can add some IP-based V2V and V2I for mobility management and also IoT. Cheers, J=C3=A9r=C3=B4me *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com ] *Sent:* Thursday 14 April 2016 03:22 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:* Alexandre Petrescu; its@ietf.org *Subject:* Re: [its] charter ITS Hi J=C3=A9r=C3=B4me, I have an opinion on your comment 5) below. I think that a list of high-quality papers about IP-based V2V and V2I can teach very useful lessons to software designers of IP in V2V and V2I in the industry. Multiple people are working for this IP-based V2V and V2I (including Sandra Cespedes and me) in academia and more people(including Nabil Benamar) are willing to work for this area. I think we need to utilize the list of such papers as the ground for our ITS group through a WI. Note that the draft of the list will include the summary of the main ideas of the papers. For the industry current activities for this area, I believe that you can share them as references through our ITS mailing list rather than through a WI. Could you join my team that are making efforts for a list of such = papers? Thanks. Best Regards, Paul On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri = > wrote: Dear ITSers, Dear Alex, Here are some comments on the updated charter: 1)Can we keep a reference to IEEE 802.11p, considering it does not exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of course. 2)Should we really keep C-ACC (or Platooning) in the charter explicitly as use case, considering it is a seriously controversial aspect with some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry mentions traffic efficiency/infotainment applications, such as in-signage applications... a.We might have to aim at less controversial use cases to attract automotive industries 3)One potential WI I could think of (rather a basic one): _definition of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive context_ a.To me, this is a fundamental brick in the larger IETF WG ITS house.. 4)I would suggest to be more explicit in the foreseen challenges of this WG, instead of mentioning general use case (which end up be = controversial) a.Example: maintaining IPv6 connectivity in fast and asymmetric wireless links; also under quickly changing topologies (actually suggested by Dick Roy on the chat room) b.Example: IPv6 addressing in link-local scope.. c.Example: guaranteeing privacy in IPv6 moving networks etc.. 5)Before listing academic papers referring to IPv6 in vehicles, I would suggest to first try to list commercial products/solutions that are in vehicles and are using IPv6, possibly suffering from a silo limitations (ex. restricted to a single technology, single use case=E2=80=A6) a.I think we need to get to products first, before academic visions My two cents.. Best Regards, J=C3=A9r=C3=B4me *From:*its [mailto:its-bounces@ietf.org ] *On Behalf Of *Alexandre Petrescu *Sent:* Wednesday 06 April 2016 23:45 *To:* its@ietf.org *Subject:* [its] charter ITS ITSers, Please see below the current charter. - the two Problem Statements drafts V2V and V2I joined, so there is less text in charter. - added an Item on "List of Research papers..." Erik: did I understand you correctly that there should be some item on discussing whether link-local addressing is sufficient, whether prefix exchange is necessary? Dino: should LISP be included in the gap analysis draft which includes C-ACC use-case? OR should we separate a dedicated I-D only with gap analysis including ND, MIP, AODVv2, LISP? Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle interface illustrated good enough by the words "moving network to nearby moving network communications"? Or is it better to say "the 1-IP-hop between nearby moving networks must be self-configured"? Nabil, Sandra: is it ok to have a working group item "List of Research Papers for IP in V2V and V2I communications"? Other comments? Alex ------------------------------------------------------------------ ITS (name to change) Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: WG forming Chairs: TBD Assigned Area Director: TBD Mailing list Address: its@ietf.org 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: Goal ---- The goal of this group is to standardize IP-based protocols for establishing direct and secure connectivity between moving networks, some of which could be fixed permanently or temporarily. Moving Network to Nearby Moving Network Communications ------------------------------------------------------ The group is concerned with all situations involving moving network to nearby moving network communications. For example: vehicle-to-vehicle communications, nomadic user wearing a PAN and communicating to a homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a train, or train-to-intersection signalling. Example from the automobile communications space ------------------------------------------------ Automobiles and vehicles of all types are increasingly connected to the Internet, either as vehicle-to-vehicle, vehicle-to-infra or vehicle-to-Internet. Entertainment apps enhancing comfort, reliable data exchanges for road safety, and automated driving are features coming in automobiles to hit the roads from now to year 2020. Highlighting increased safety as an immediate result of hyper-connectivity applied to vehicles, public authorities worldwide are increasingly mandating secure communication technology requirements in vehicles. Emergency apps for new instrumented ambulances carry many benefits both to the users and to society in general. Why IP? ------- Today, there are several deployed Vehicle-to-Internet technologies, including car tethering through driver's cellular smartphone. However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are still being developed. To improve on a situation of link-specific data exchanges, and enable independent application sets to share the same links, IP data exchanges are needed. Enabling IP communication between vehicles (V2V), and between vehicles and the immediate infrastructure (V2I), will provide (0) ability to reach the rest of the world on the Internet (1) short and deterministic delays, (2) fast forwarding through scalable paths of routers, (3) ease of reuse of existing Internet applications in a vehicular environment. Moving network to nearby moving network communications involve link layers such as: 802.11p OCB (Outside the Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light Communications), IrDA, LTE-D. Only the IP protocols are capable of running on each of these links and establish IP paths across them in an interoperable manner. Scenarios? ---------- There are a few scenarios exhibiting the need to communicate from one moving network to another nearby moving network. In the automobile space, the Cooperative Adaptive Cruise Control and Platooning features consider that vehicles close to each other exchange data describing their kinematic status. At the cross-roads, the moving network inside a vehicle exchanges data with the moving network in the red-light pole. Several public safety scenarios involve moving networks. Distinct organizations deploy different moving networks (in-vehicle, on-person) at an incident scene. These networks need to interoperate in order to more effectively understand and deal with the incident scene. In connected rail scenarios the moving network deployed in trains communicate with other moving networks at the cross-points. What kind of solutions? ----------------------- The current technical solutions considered to achieve moving network to nearby moving network communications are of two kinds: IP routing protocols for n-hop path management and 1-hop link-scoped IP protocol enhancements. The 1-hop link-scoped protocols include the protocols for route establishment involving ICMP Router Advertisements. The n-hop path management protocols include n-hop path establishment protocols (e.g. Babel, OSPF) and n-hop path search protocols (most notably AODV and derivates). In this proposed Working Group the focus is on 1-hop protocols, and leverage from other Working Groups for the n-hop situations. In some of the moving network applications the window of opportunity for exchanging data with the immediate infrastructure may be very short. For example, a car driving near a road-side unit may have only 5s to exchange with that RSU (depending on speed, RSU range and number). (ephemeral connections). What kind of requirements? -------------------------- The requirements for mechanisms for moving network to nearby moving network communications are focusing on low delays of the data paths, reduced number of messages for path establishment, application friendly, resilience to attacks, compatibility with DHCP and Mobile IP. In addition, some moving network to nearby moving network applications involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the 1-hop IP moving network to nearby moving netowrk mechanisms will need to gracefully support IP multicast. Due to the inherent characteristics of safety-related communications, all new moving network to nearby moving network mechanisms must afford authenticity and confidentiality where necessary. Dynamically establishing ephemeral communication paths between automobiles in public areas must offer privacy safeguards for the end users (passengers). Establishing 1-hop IP V2V paths must not break the existing on-board protocols and applications which communicate with the Internet, possibly via multiple radios. In a moving network deployed in an automobile, typically one exit point connects the moving network to other moving networks. However, in a more general manner (and to support reliability) any new mechanism of moving network to nearby moving network communications should support multi-homing: one router to use multiple interfaces towards outside the moving network, or multiple routers. Current version of Internet protocols ------------------------------------- The group will only work on IPv6 solutions. What SDOs may need this work? ----------------------------- The requirements and standards for moving network to nearby moving network communications, often involving IPv6, and novel V2V and V2Infra concepts, are developed mainly at ISO TC204 "Intelligent Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For Vehicle-to-Internet communications, 3GPP LTE and other cellular technologies represent the long-range connectivity method; for Vehicle-to-Vehicle communications, LTE Direct is currently specified, as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning. The IEEE developed a popular link for short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V communications. Work Items ---------- - use-cases for moving network to nearby moving network communications - Problem Statement for moving network to nearby moving network communications including V2V, V2I and DNS. - Security and Privacy Requirements for moving network to nearby moving network communications - Solutions, which might include new protocols or extensions to existing protocols. With MIB. - IPv6-over foo, where foo is pertinent for moving network to nearby moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in the V2V domain, identifying which uses IP. Timeline -------- - _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 =20 Email: jaehoon.paul@gmail.com , pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 =20 Email: jaehoon.paul@gmail.com , pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its =20 =20 _____ =20 = Avast logo El software de antivirus Avast ha analizado este correo electr=C3=B3nico = en busca de virus.=20 www.avast.com = =20 =20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its ------=_NextPart_001_004D_01D19A1D.7EDD5AA0 Content-Type: text/html; boundary="Apple-Mail-FB2FC7B9-1261-44D7-8CFA-5AB6E3282405"; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear = Nabil, Dear All,

 

I am one of the supporters = of having IoT in the charter, and I disagree with your statement on IoT. =

 

There are plenty of interpretation of what IoT is or = is not...the same stands for vehicular = communications...

 

IoT will be = transiting via vehicular communication - we have a testbed, where IoT = traffic from embedded sensors (CAN or non-CAN) are sent to an IoT server = on Internet via ITS-G5/DSRC communication. IoT here is the architecture = (oneM2M) that is above a specific technology, not a technology itself = (you are maybe referring to SigFox or LTE-sensors I guess)..so, our = system works if we use another technology and would even need to work if = we have multiple technologies on the path between the sensors and = the=C2=A0 =E2=80=98cloud=E2=80=99=E2=80=A6here, IPv6 take all of its = sense.

 

The IoT differences in =E2=80=98routing, energy = consumption, mac layer=E2=80=99 as you said are actually either fully = relevant to the charter, as referring to IPv6-over-foo or fully = irrelevant to IPv6 (as based on IoT application-level traffic). =

 

Instead of debating whether we should add IoT or keep = vehicular communication, we should debate of what kind of traffic = (M2M-like, stream?, unicast/multicast etc..) will be transiting through = IPv6 communication from a =E2=80=98vehicle=E2=80=99 to either Internet = or another =E2=80=98vehicle=E2=80=99.

 

And I would like to mention that my suggestion is not = to reduce the focus, but actually to focus on an aspect, where IPv6 does = not have a competitor and can really make a difference.

Said simple: if the charter addresses primarily IPv6 = for critical safety communications, this will be difficult to sell, as = other simpler solutions already work without IPv6.

 

I would = therefore support and even propose to have a draft=C2=A0 formulating the = problem related to =E2=80=9CIoT-over-IPv6 on moving networks=E2=80=9D. =

 

Best = Regards,

 

J=C3=A9r=C3=B4me

 

Envoy=C3=A9 = de mon iPad

 

 

De:<= /b> = its [mailto:its-bounces@ietf.org] En = nombre de Nabil Benamar
Enviado el: lunes, 18 de abril de = 2016 4:55
Para: Alexandre Petrescu <alexandre.petrescu@gmail.com>
= CC: its@ietf.org
Asun= to: Re: [its] charter ITS - proposed work = items

 <= /o:p>

Hi = All,

 <= o:p>

I agree on = the current charter since these are the points discussed during the BoF! = However there were some replies in this list mentioning to probably add = IoT as an exemple of IP based communications.  I think that we = should keep the focus on vehicular communications/networks and do not = diverge from this topic. IoT is fundamentally different from vehicular = networks in many aspects such as routing, energy consumption, mac layer, = etc...


Best = regards

Nabil = Benamar

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

=D9=86=D8=A8=D9=8A=D9=84 = =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88

 

 <= /o:p>

On Thu, Apr = 14, 2016 at 9:42 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> = wrote:

ITSers,
<= br>We work on a more rigorous ITS charter text.

Now we propose = four work items:

1. "Problem statement for IP in V2V and = V2I"
   including "IP addressing architecture for = V2V and V2I"
   and including "Gap Analysis: IP = protocols suited and gaps"
   and including = "Use-cases for IP in V2V and V2I moving network to
    =               nearby moving or fixed = network"

2. "Threat Analysis for IP prefix exchanges in = V2V and V2I context"

3. "IP over DSRC = (802.11-OCB)" typical IP-over-foo document[*],
  =  including connectivity in fast and asymmetric conditions, = coverage
   area vs speed diagrams, below-IP congestion = management.

4. "List of papers and _products_ using IP in = V2V and V2I"

What do you think?

Please respond by = next Monday, April 18th.

Alex and Dapeng
[*] a typical = IP-over-foo document is, for example, RFC2464
    = "Transmission of IPv6 Packets over Ethernet Networks", = where
    "foo" is instantiated as = "Ethernet".  Other IPv6-over-foo documents
  =   are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 = over PPP" and more.

Le 14/04/2016 09:42, J=C3=A9r=C3=B4me = H=C3=A4rri a =C3=A9crit :

Paul,

Thank= s. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of IP V2V = but not see
the need (so far), I referred to the automotive SDOs (led = by automotive
industries)=E2=80=A6, although there are always = =E2=80=98minority reports=E2=80=99 = J

Cheers,

J=C3=A9r=C3=B4me

*From:*Mr. Jaehoon Paul = Jeong [mailto:jaehoon.paul@gmail.com]
*Sent:* Thursday 14 = April 2016 09:36
*To:* J=C3=A9r=C3=B4me H=C3=A4rri
*Cc:* Alexandre = Petrescu; its@ietf.org
*Subject:* Re: [its] charter = ITS

J=C3=A9r=C3=B4me,

I missed that you are also an = academic person.

I got it :-)

I understand your points for = industry activity related to vehicular
networking.

Your = observation seems true.

BTW, I will invite you to my team for the = draft for a list of academic
papers for V2V and V2I

by a = personal message.

Thanks.

Paul

On Thu, Apr 14, 2016 = at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr
<mailto:jerome.haerri@eurecom.fr>> wrote:

Hi = Paul,

Thanks for your feedback. Do not get me wrong, I am an = academic and with
my team, we also work on IP-based V2V and V2I, in = particular related to
mobility management with DMM, but also in the = context of vehicular IoT.

I just have the feeling that people are = perfectly aware of the fact that
IP _can_ be used for V2V and V2I, = but does not =E2=80=98_need_=E2=80=99 to be used as
other solutions = already perfectly fit their need. Listing papers will
not change this = awareness.

So, as a complement to academic papers, it would help = to be able to
pin-point which industrial activities are using or are = strongly planning
(short term I mean) to use pure IPv6 system in = vehicles.

My feeling here is we have a different eco-system that = the Automotive
industry (and automotive industry-related SDO)..more = likely the IoT
industry=E2=80=A6and as such, we should not need to = have the (direct)
involvement of automotive industry in the Charter. = If we can make this
clear by an industry-based = =E2=80=98survey=E2=80=99, that would help make the case for
the = WG.

Btw, you can count on me your draft..we can add some IP-based = V2V and
V2I for mobility management and also = IoT.

Cheers,

J=C3=A9r=C3=B4me

*From:*Mr. Jaehoon = Paul Jeong [mailto:jaehoon.paul@gmail.com
<mailto:jaehoon.paul@gmail.com>]
*Sent:* Thursday 14 = April 2016 03:22
*To:* J=C3=A9r=C3=B4me H=C3=A4rri
*Cc:* Alexandre = Petrescu; its@ietf.org <mailto:its@ietf.org>
*Subject:* Re: [its] charter = ITS

Hi J=C3=A9r=C3=B4me,

I have an opinion on your comment = 5) below.

I think that a list of high-quality papers about = IP-based V2V and V2I

can teach very useful lessons to software = designers of IP in V2V and V2I

in the industry.

Multiple = people are working for this IP-based V2V and V2I

(including = Sandra Cespedes and me) in academia and

more people(including = Nabil Benamar) are willing to work for this area.

I think we need = to utilize the list of such papers as the ground for our
ITS = group

through a WI. Note that the draft of the list will include = the summary
of the main

ideas of the papers.

For the = industry current activities for this area, I believe that you
can = share them

as references through our ITS mailing list rather than = through a WI.

Could you join my team that are making efforts for = a list of such papers?

Thanks.

Best = Regards,

Paul

On Thu, Apr 7, 2016 at 8:11 AM, = J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr
<mailto:jerome.haerri@eurecom.fr>> = wrote:

Dear ITSers,  Dear Alex,

Here are some = comments on the updated charter:

1)Can we keep a reference to = IEEE 802.11p, considering it does not exist
anymore? It is now fully = integrated into IEEE 802.11-2012 as OCB mode
(and 10Mhz @5.9Ghz) of = course.

2)Should we really keep C-ACC (or Platooning) in the = charter explicitly
as use case, considering it is a seriously = controversial aspect with
some SDOs (ex. In Automotive SDOs)? In the = ISO presentation, Thierry
mentions traffic efficiency/infotainment = applications, such as
in-signage applications...

a.We might = have to aim at less controversial use cases to attract
automotive = industries

3)One potential WI I could think of (rather a basic = one): _definition of
a vehicular wireless =E2=80=98link=E2=80=99 in = an automotive context_

a.To me, this is  a fundamental brick = in the larger IETF WG ITS house..

4)I would suggest to be more = explicit in the foreseen challenges of this
WG, instead of mentioning = general use case (which end up be controversial)

a.Example: = maintaining IPv6 connectivity in fast and asymmetric wireless
links; = also under quickly changing topologies (actually suggested by
Dick = Roy on the chat room)

b.Example: IPv6 addressing in link-local = scope..

c.Example: guaranteeing privacy in IPv6 moving networks = etc..

5)Before listing academic papers referring to IPv6 in = vehicles, I would
suggest to first try to list commercial = products/solutions that are in
vehicles and are using IPv6, possibly = suffering from a silo limitations
(ex. restricted to a single = technology, single use case=E2=80=A6)

a.I think we need to get to = products first, before academic visions

My two = cents..

Best Regards,

J=C3=A9r=C3=B4me

*From:*its = [mailto:its-bounces@ietf.org <mailto:its-bounces@ietf.org>]
*On Behalf Of = *Alexandre Petrescu
*Sent:* Wednesday 06 April 2016 23:45
*To:* its@ietf.org = <mailto:its@ietf.org>
*Subject:* [its] charter = ITS

ITSers,

Please see below the current charter.

- = the two Problem Statements drafts V2V and V2I joined, so there is = less
text in charter.
- added an Item on "List of Research = papers..."

Erik: did I understand you correctly that there = should be some item on
discussing whether link-local addressing is = sufficient, whether prefix
exchange is necessary?

Dino: should = LISP be included in the gap analysis draft which includes
C-ACC = use-case?  OR should we separate a dedicated I-D only with = gap
analysis including ND, MIP, AODVv2, LISP?

Person from = mediatek: is the 'zeroconf' need in the vehicle-to-vehicle
interface = illustrated good enough by the words "moving network to = nearby
moving network communications"?  Or is it better to = say "the 1-IP-hop
between nearby moving networks must be = self-configured"?

Nabil, Sandra: is it ok to have a working = group item "List of Research
Papers for IP in V2V and V2I = communications"?

Other = comments?

Alex

--------------------------------------------= ----------------------

            =   ITS (name to change)
            =         Charter
        =       April 6th, 2016
http://ietf.org/mailman/listinfo/its


Int= elligent Transportation Systems = (its)
----------------------------------------
Current Status: WG = forming

Chairs:
    TBD

Assigned Area = Director:
    TBD

Mailing list
    = Address: its@ietf.org <mailto:its@ietf.org>
    To Subscribe: https://www.ietf.org/mailman/listinfo/its
 =   Archive:
http://www.ietf.org/mail-archive/web/its/current/mailli= st.html

Additional web page
    = TBD

Charter:

Goal
----
The goal of this group is to = standardize IP-based protocols for
establishing direct and secure = connectivity between moving networks,
some of which could be fixed = permanently or temporarily.

Moving Network to Nearby Moving = Network = Communications
------------------------------------------------------<= br>The group is concerned with all situations involving moving network = to
nearby moving network communications.  For example: = vehicle-to-vehicle
communications, nomadic user wearing a PAN and = communicating to a
homenet, vehicle-to-infrastructure communications, = wagon-to-wagon in a
train, or train-to-intersection = signalling.

Example from the automobile communications = space
------------------------------------------------
Automobiles = and vehicles of all types are increasingly connected to
the Internet, = either as vehicle-to-vehicle, vehicle-to-infra = or
vehicle-to-Internet.  Entertainment apps enhancing comfort, = reliable
data exchanges for road safety, and automated driving are = features
coming in automobiles to hit the roads from now to year = 2020.
Highlighting increased safety as an immediate result = of
hyper-connectivity applied to vehicles, public authorities = worldwide
are increasingly mandating secure communication = technology
requirements in vehicles.

Emergency apps for new = instrumented ambulances carry many benefits
both to the users and to = society in general.

Why IP?
-------
Today, there are = several deployed Vehicle-to-Internet technologies,
including car = tethering through driver's cellular smartphone.
However, = Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communications are = still being developed.  To improve on a situation
of = link-specific data exchanges, and enable independent application
sets = to share the same links, IP data exchanges are needed.  = Enabling
IP communication between vehicles (V2V), and between = vehicles and the
immediate infrastructure (V2I), will provide (0) = ability to reach the
rest of the world on the Internet (1) short and = deterministic delays,
(2) fast forwarding through scalable paths of = routers, (3) ease of
reuse of existing Internet applications in a = vehicular environment.

Moving network to nearby moving network = communications involve link
layers such as: 802.11p OCB (Outside the = Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC = (Visible Light
Communications), IrDA, LTE-D.  Only the IP = protocols are capable of
running on each of these links and establish = IP paths across them in
an interoperable = manner.

Scenarios?
----------
There are a few scenarios = exhibiting the need to communicate from one
moving network to another = nearby moving network.

In the automobile space, the Cooperative = Adaptive Cruise Control and
Platooning features consider that = vehicles close to each other
exchange data describing their kinematic = status.  At the cross-roads,
the moving network inside a vehicle = exchanges data with the moving
network in the red-light = pole.

Several public safety scenarios involve moving = networks.  Distinct
organizations deploy different moving = networks (in-vehicle, on-person)
at an incident scene.  These = networks need to interoperate in order to
more effectively understand = and deal with the incident scene.

In connected rail scenarios the = moving network deployed in trains
communicate with other moving = networks at the cross-points.

What kind of = solutions?
-----------------------
The current technical solutions = considered to achieve moving network
to nearby moving network = communications are of two kinds: IP routing
protocols for n-hop path = management and 1-hop link-scoped IP protocol
enhancements.  The = 1-hop link-scoped protocols include the protocols
for route = establishment involving ICMP Router Advertisements.  The
n-hop = path management protocols include n-hop path establishment
protocols = (e.g. Babel, OSPF) and n-hop path search protocols (most
notably AODV = and derivates).

In this proposed Working Group the focus is on = 1-hop protocols, and
leverage from other Working Groups for the n-hop = situations.

In some of the moving network applications the window = of opportunity
for exchanging data with the immediate infrastructure = may be very
short.  For example, a car driving near a road-side = unit may have only
5s to exchange with that RSU (depending on speed, = RSU range and
number). (ephemeral connections).

What kind of = requirements?
--------------------------
The requirements for = mechanisms for moving network to nearby moving
network communications = are focusing on low delays of the data paths,
reduced number of = messages for path establishment, application
friendly, resilience to = attacks, compatibility with DHCP and Mobile
IP.

In addition, = some moving network to nearby moving network applications
involve IP = multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP = moving network to nearby moving netowrk mechanisms will need
to = gracefully support IP multicast.

Due to the inherent = characteristics of safety-related communications,
all new moving = network to nearby moving network mechanisms must afford
authenticity = and confidentiality where necessary.  Dynamically
establishing = ephemeral communication paths between automobiles in
public areas = must offer privacy safeguards for the end = users
(passengers).

Establishing 1-hop IP V2V paths must not = break the existing on-board
protocols and applications which = communicate with the Internet,
possibly via multiple = radios.

In a moving network deployed in an automobile, typically = one exit
point connects the moving network to other moving = networks.  However,
in a more general manner (and to support = reliability) any new
mechanism of moving network to nearby moving = network communications
should support multi-homing: one router to use = multiple interfaces
towards outside the moving network, or multiple = routers.

Current version of Internet = protocols
-------------------------------------
The group will = only work on IPv6 solutions.

What SDOs may need this = work?
-----------------------------
The requirements and standards = for moving network to nearby moving
network communications, often = involving IPv6, and novel V2V and
V2Infra concepts, are developed = mainly at ISO TC204 "Intelligent
Transport Systems", 3GPP, = ETSI, NHTSA and IEEE.  For
Vehicle-to-Internet communications, = 3GPP LTE and other cellular
technologies represent the long-range = connectivity method; for
Vehicle-to-Vehicle communications, LTE = Direct is currently specified,
as well as OCB mode of IEEE = 802.11.  Several use-cases exhibit a need
for IPv6 data = exchanges between vehicles: ETSI's Cooperative Adaptive
Cruise = Control and Platooning.  The IEEE developed a popular link = for
short-range communications - IEEE 802.11p "WAVE".  = The NHTSA wrote a
set of requirements for V2V = communications.

Work Items
----------
- use-cases for = moving network to nearby moving network communications
- Problem = Statement for moving network to nearby moving = network
communications
   including V2V, V2I and = DNS.
- Security and Privacy Requirements for moving network = to
   nearby moving network communications
- Solutions, = which might include new protocols or extensions to
  =  existing protocols.  With MIB.
- IPv6-over foo, where foo = is pertinent for moving network to nearby
   moving network = communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)
- List of = Research Papers in the V2V domain, identifying which uses = IP.

Timeline
--------
-


_________________________= ______________________
its mailing list
its@ietf.org = <mailto:its@ietf.org>
https://www.ietf.org/mailman/listinfo/its


--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant = Professor
Department of Software
Sungkyunkwan = University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>,
pauljeong@skku.edu <mailto:pauljeong@skku.edu>
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
= <http://cpslab.skku.edu/people-jaehoon-jeong.php>=



--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, = Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan = University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>,
pauljeong@skku.edu <mailto:pauljeong@skku.edu>
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
= <http://cpslab.skku.edu/people-jaehoon-jeong.php>=


________= _______________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

 <= /o:p>

 

3D"Avast

El software = de antivirus Avast ha analizado este correo electr=C3=B3nico en busca de = virus.
www.a= vast.com

 

_______________________________________________
its = mailing list
its@ietf.org
https://www.ietf.org/m= ailman/listinfo/its

------=_NextPart_001_004D_01D19A1D.7EDD5AA0-- ------=_NextPart_000_004C_01D19A1D.7EDD5AA0 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAfmSURBVFhH tVdrbBTXFT73zp31jN8PDKYGEoyLDTghkWMjFwwiGKM+eKgSSRtQ2v5qIyohJSlRpcSbdaOqihQp VUpUEHGUVDSIqqWlKE0dNwkxkVtv7FiVCesEObSEd8wa1usd79y5t9+M1w9o41qNe631zsy9e893 vvOdc8+ISCRCM42WsvCDxOkAZdH61k8if59x8f8wKWY0viLM6Tr9gIoon+L0CNb6nzkdkwDgaS52 rmq9HOmZsODEaZFlUC2NESNNa1vqw6K1OyLnEsEUA5waNNFLLYXh1a3DkbhvxCKaD/rzyMWNplL6 J/kgh/8vAJSilTybFpPCh0D4+JhHRmCcAMSg0eBuTsckA5zTJRDtj5xJC5oayF/hM0DkxC0EY45G OBxmtU0786dCoOgkPLwGHx+EHhbCY6YVPcR846EAROyFy5GRObJPyD7dEf3o4UkAEN+VJ8vCr3Gb 9sLPveQRMZ8RfOOj8Xf0ixpv7z87XyRkrinzLroisUqbVH1LGnKCAhBlLWmYmVRIvt45no3RIVwd +aIAxJj6qmeyr0Biz3kitJ9p+cxUGtaHQ3SettJN6obxX2qX9rFcqqYRGqAN9MPWIxEXcQNG8ulT nwfGjy3m2PQ1YdSTyJmIgtD937mSRDZjym66b+WJKQYuUkWQanm0vfXjyOmWReEhCPAPeNbpG389 Glu3cfvubZox3t4VOy4EDStTFDfdU/nO8c7OvOzs0u2keHLD9t0NEDS9FY0dM+28M65M7l3/we6i Dhk7pThPcq2XMU6btOaBnqaLsB7099o/fyy1vOTCk3po7a/Cd72XQAgu+guhwx8rbpTBvTQz2VKP 0Yck5TJMvZNrld6rNH9ck3KITK0YC3lM3anGkm9zxh6Blno1IwBULzLOGxTXA5B4kFvTNVBLJp1Z kJP8drElf3L0w6qBcO17UejArwL4x+bJlHrIgecWo1cNrUsVsaAqgto6bWgfqGV6+gF3zM0HyIMA u1l63s+a66qf74gOtHLSXyal3zBIH0Ys1t8KQFO+cvlngnShSqeeG1UFy1EXzuKDgoig+iCEfT0h V92wzb8qpVkeZ5QKwHG2Dgh7kLn1HQ9vvd70m4OptDM/rcEzZ7yovbO/nCzrECe5AxutYlqkNcmg qE0xwIgnUmIMGTfKSL4mNfsucn8MIQiEFwwnJfLotGAhkIrEBArZ1dUVYmbxAuTsfkhsw/K2NkF5 RdhXC675u4r0PsMObdZadsLrj7EZ1+TAuJl1ewh0yFRCcJYvySoxmQem4L2HvMhQYFu2dhDlQMt+ ZJgeA6QVuBq2snjMcbxg08xsrifTJ7gQBjd4qZL0NfzgFHB7pkPnpMV+cXsISmxbDiFG+YzUEybJ U6CrFnY+m9gy7tDNbY3lox09A6Q1mQZjSaXEFqwZjMedm3a20LsaGtJDhw/rD6pq0zwU2qIUf7np 3sqLb74/cAiuI9PYYLyIUtmpcTcEyu5SXO5AMNZgo+GEJ44VKGPTkoJ4B7zfhwD8Y9wl5uVkjzyL 8vk30A1P2aDSeg0ILYDsn6ooouQlh3I6orFnqbKuF+w4TFM9Y94O/Oa3CFodNHJUMf1Adko8ivtd 2PVFXwN70O08FqjBofWHNr7x6Nanj/5Jv3rfEjCwkJK02refVuaBEHP3AMkYwHQL4kc8wysjT484 Ts7Jmrrl3uWe2MsAtosJNgp9RA1Sf4EMHweYrzOtu0wyDjlaLmPEigHgpfEQMPpWIHG/5mfTkm8s Hvw+jLcBzFM4FxlSc3XLvHAVrYm80t51tgcFKCkdkk2Nlefbo2dbbNsYbaorH/U3u3Jn6QsLB691 QMA3bDK8xrrKT9v7YucwVWgLeb6xpnqoPdr/BKRljY7aQ+MAOJUHme5SbxAVDtodasazhiDJDLIB 4pWWpeHvoAj3T4jM/26uqzw//X5XSYlLJSW39I3N91T7ACZHc13Nten3AkaHUeYKwcAzlEYjYtPb 6AAbcQaMs+KDyoE+Rmh/y4rwjtYzc3ckjzNA1K3TtJEp6mi9Gkm0fCn8I1S/PdqjJcwIzkJCn+CD 2EQJasLV76d78J+uj0cvLMilePn9dTW9/nxXV6FIiu7vZdnpXzfW1CRvZUDTT5lHv0M/kAgmFtHz 6P3egiz8rNjvNyaZ0PiMbJkNAIsSixXxMqwNACTk+6Vc6Lvj8fjh2wELGD4Jajvp8vhUpuvtxbM+ PUx7WIhWBY2YHw6iO/6b9xlaLcXF/Pau/rtIWDdQPi3p6q6ioopQezS20iQacaW0mhtq+oJSjLj+ 2/nuP0OH9CYTGQD+QjatX5wBSVrxHIOrtdwUd3CX/kwkPcb03W4qWQGV57tKXRUi5J8F4wA+b+Bc /yjIkPFm1a++s+qKueAKJ19Ca9aEc+WYa5LLJff8hoQZyiPOFmPBYIatGUkdzlA/sSg9mxDgfPbr i40U+kQLaQpXQBLGVcXVORSgKqWpYMKnGRlANlyZPC+DRmvyfWFGHMJUQ8xVf/RI1JBpjaDGWOjH LmTZvGcsRRU4ET8FyKB4zQwgTTFt0HX0iMWZQ7lvNgxcSsX7EGx1Tea9WyrXjUp5WuBNZ6DzxMFU 086dbfE46aKizGE044Z78bJyAIUpRN9EIXKggddnA8A/ETPrcJQP47I86Jy2NQZv4jem7zEjA614 eWiR4adxIG2G8bbpL66zATKbNf8CtKtM41O+pTwAAAAASUVORK5CYII= ------=_NextPart_000_004C_01D19A1D.7EDD5AA0-- From nobody Tue Apr 19 00:43:31 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F7812E56B for ; Tue, 19 Apr 2016 00:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8X8-PrzlplZ for ; Tue, 19 Apr 2016 00:43:25 -0700 (PDT) Received: from mail-pa0-x243.google.com (mail-pa0-x243.google.com [IPv6:2607:f8b0:400e:c03::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88AA612D97E for ; Tue, 19 Apr 2016 00:43:25 -0700 (PDT) Received: by mail-pa0-x243.google.com with SMTP id zy2so1029268pac.2 for ; Tue, 19 Apr 2016 00:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=/EZfO3zUybVlAJteD9MCP6ZNlmQqk9JnehpATgTWJCg=; b=AkqhkeRoZcL/bztJK32i9JU5WXrvLlbNENu18xVBAvuWLkzU6mgaIZy3XQL0WrSoH0 9qCHJlRL+IhRS3pBfPAGbjwdDxFudiU+jvjaGCBAhpUCLdfajQ7zC+TmXjXtelnlvCUa E//Q63w0vLR8MKopPXP46oiY1pZencH5p37S2F4WW5kcmRFv3bsYF2A6jqlY2oazpg+r vmvXWAcTPs+CQi2hRqR/JXIWKRQLG6ESHa31J1+VVtjpYQaA2EaVp+Cz0dvm74w5ZNQk 0lBESho0bv75Z5ks6KQJ7ritDgDpwgXLsnvUTBAmnn0m+npoE1zEMrBUMwpfGZXkNIJh Y9iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=/EZfO3zUybVlAJteD9MCP6ZNlmQqk9JnehpATgTWJCg=; b=BPp0v75EI12C5F8TVb7jJuS3WXA8vKEsWpFU052uBGCQ/BFUacWQRJap0yXzVlg13l LMZzycm5WJGK0K8Az3Mp9IAGalGeWLcR0RUzoDrmlkLC0kbU9EjdcxJBgJCOwz2hQ8p3 ueCwoOxboyJvRf+RabRjlGgDbL2BUQlc1gqW9iqcUsMaQ6Le75SCCzv7REX1+cCzY6FM NuU0/npVqKfBijnKXkBbnnsQdT4Ekge09hbCaY7G6ZTvnjpcYWtbBqJjt44+AWYDhc59 odP9yXJ0i8imFRsNBbunrhNHJp8lvlvkjCqWkQm1Yvc0WlecoRZEvsGC/lGlNat9hQ/G Rppw== X-Gm-Message-State: AOPr4FXgl+mTQiA7tCFYIVUzpXr8iGIt3/fd/OpmguqHCjEL6LEpKLuJ6UsUOyqOOmfcwg== X-Received: by 10.66.145.35 with SMTP id sr3mr2060722pab.82.1461051805084; Tue, 19 Apr 2016 00:43:25 -0700 (PDT) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id s63sm32844868pfb.71.2016.04.19.00.43.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Apr 2016 00:43:23 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_CDB00E7C-A00E-48D1-A979-59DA4845B52C" From: Jong-Hyouk Lee In-Reply-To: <004b01d19a0c$bb4632c0$31d29840$@eurecom.fr> Date: Tue, 19 Apr 2016 16:43:19 +0900 Message-Id: <5FB65917-A5F3-4C77-807D-11C243FC31F0@gmail.com> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <04ae01d199bf$3d2938d0$b77baa70$@ing.uchile.cl> <004b01d19a0c$bb4632c0$31d29840$@eurecom.fr> To: =?utf-8?Q?=22J=C3=A9r=C3=B4me_H=C3=A4rri_=28EURECOM=29=22?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Nabil Benamar , Alexandre Petrescu , its@ietf.org, =?utf-8?Q?Sandra_C=C3=A9spedes?= Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 07:43:30 -0000 --Apple-Mail=_CDB00E7C-A00E-48D1-A979-59DA4845B52C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 19, 2016, at 4:26 PM, J=C3=A9r=C3=B4me H=C3=A4rri (EURECOM) = wrote: >=20 > Dear Nabil, Dear All, > =20 > I am one of the supporters of having IoT in the charter, and I = disagree with your statement on IoT.=20 > =20 > There are plenty of interpretation of what IoT is or is not...the same = stands for vehicular communications... > =20 > IoT will be transiting via vehicular communication - we have a = testbed, where IoT traffic from embedded sensors (CAN or non-CAN) are = sent to an IoT server on Internet via ITS-G5/DSRC communication. IoT = here is the architecture (oneM2M) that is above a specific technology, = not a technology itself (you are maybe referring to SigFox or = LTE-sensors I guess)..so, our system works if we use another technology = and would even need to work if we have multiple technologies on the path = between the sensors and the =E2=80=98cloud=E2=80=99=E2=80=A6here, IPv6 = take all of its sense. > =20 > The IoT differences in =E2=80=98routing, energy consumption, mac = layer=E2=80=99 as you said are actually either fully relevant to the = charter, as referring to IPv6-over-foo or fully irrelevant to IPv6 (as = based on IoT application-level traffic).=20 > =20 > Instead of debating whether we should add IoT or keep vehicular = communication, we should debate of what kind of traffic (M2M-like, = stream?, unicast/multicast etc..) will be transiting through IPv6 = communication from a =E2=80=98vehicle=E2=80=99 to either Internet or = another =E2=80=98vehicle=E2=80=99.=20 > =20 > And I would like to mention that my suggestion is not to reduce the = focus, but actually to focus on an aspect, where IPv6 does not have a = competitor and can really make a difference. > Said simple: if the charter addresses primarily IPv6 for critical = safety communications, this will be difficult to sell, as other simpler = solutions already work without IPv6.=20 > =20 > I would therefore support and even propose to have a draft = formulating the problem related to =E2=80=9CIoT-over-IPv6 on moving = networks=E2=80=9D.=20 > =20 > Best Regards, > =20 > J=C3=A9r=C3=B4me > =20 >=20 > Envoy=C3=A9 de mon iPad >> =20 >> =20 >> De: its [mailto:its-bounces@ietf.org ] = En nombre de Nabil Benamar >> Enviado el: lunes, 18 de abril de 2016 4:55 >> Para: Alexandre Petrescu > >> CC: its@ietf.org >> Asunto: Re: [its] charter ITS - proposed work items >> =20 >> Hi All, >> =20 >> I agree on the current charter since these are the points discussed = during the BoF! However there were some replies in this list mentioning = to probably add IoT as an exemple of IP based communications. I think = that we should keep the focus on vehicular communications/networks and = do not diverge from this topic. IoT is fundamentally different from = vehicular networks in many aspects such as routing, energy consumption, = mac layer, etc... >>=20 >> Best regards >> Nabil Benamar >> ------------------- >> =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 >> =20 >> http://nabilbenamar.ipv6-lab.net/ >> =20 >> On Thu, Apr 14, 2016 at 9:42 AM, Alexandre Petrescu = > = wrote: >>> ITSers, >>>=20 >>> We work on a more rigorous ITS charter text. >>>=20 >>> Now we propose four work items: >>>=20 >>> 1. "Problem statement for IP in V2V and V2I" >>> including "IP addressing architecture for V2V and V2I" >>> and including "Gap Analysis: IP protocols suited and gaps" >>> and including "Use-cases for IP in V2V and V2I moving network to >>> nearby moving or fixed network" >>>=20 >>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" >>>=20 >>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], >>> including connectivity in fast and asymmetric conditions, = coverage >>> area vs speed diagrams, below-IP congestion management. >>>=20 >>> 4. "List of papers and _products_ using IP in V2V and V2I" >>>=20 >>> What do you think? >>>=20 >>> Please respond by next Monday, April 18th. >>>=20 >>> Alex and Dapeng >>> [*] a typical IP-over-foo document is, for example, RFC2464 >>> "Transmission of IPv6 Packets over Ethernet Networks", where >>> "foo" is instantiated as "Ethernet". Other IPv6-over-foo = documents >>> are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and = more. >>>=20 >>> Le 14/04/2016 09:42, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : >>>> Paul, >>>>=20 >>>> Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of = IP V2V but not see >>>> the need (so far), I referred to the automotive SDOs (led by = automotive >>>> industries)=E2=80=A6, although there are always =E2=80=98minority = reports=E2=80=99 J >>>>=20 >>>> Cheers, >>>>=20 >>>> J=C3=A9r=C3=B4me >>>>=20 >>>> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com = ] >>>> *Sent:* Thursday 14 April 2016 09:36 >>>> *To:* J=C3=A9r=C3=B4me H=C3=A4rri >>>> *Cc:* Alexandre Petrescu; its@ietf.org >>>> *Subject:* Re: [its] charter ITS >>>>=20 >>>> J=C3=A9r=C3=B4me, >>>>=20 >>>> I missed that you are also an academic person. >>>>=20 >>>> I got it :-) >>>>=20 >>>> I understand your points for industry activity related to vehicular >>>> networking. >>>>=20 >>>> Your observation seems true. >>>>=20 >>>> BTW, I will invite you to my team for the draft for a list of = academic >>>> papers for V2V and V2I >>>>=20 >>>> by a personal message. >>>>=20 >>>> Thanks. >>>>=20 >>>> Paul >>>>=20 >>>> On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri = >>>> >> wrote: >>>>=20 >>>> Hi Paul, >>>>=20 >>>> Thanks for your feedback. Do not get me wrong, I am an academic and = with >>>> my team, we also work on IP-based V2V and V2I, in particular = related to >>>> mobility management with DMM, but also in the context of vehicular = IoT. >>>>=20 >>>> I just have the feeling that people are perfectly aware of the fact = that >>>> IP _can_ be used for V2V and V2I, but does not =E2=80=98_need_=E2=80=99= to be used as >>>> other solutions already perfectly fit their need. Listing papers = will >>>> not change this awareness. >>>>=20 >>>> So, as a complement to academic papers, it would help to be able to >>>> pin-point which industrial activities are using or are strongly = planning >>>> (short term I mean) to use pure IPv6 system in vehicles. >>>>=20 >>>> My feeling here is we have a different eco-system that the = Automotive >>>> industry (and automotive industry-related SDO)..more likely the IoT >>>> industry=E2=80=A6and as such, we should not need to have the = (direct) >>>> involvement of automotive industry in the Charter. If we can make = this >>>> clear by an industry-based =E2=80=98survey=E2=80=99, that would = help make the case for >>>> the WG. >>>>=20 >>>> Btw, you can count on me your draft..we can add some IP-based V2V = and >>>> V2I for mobility management and also IoT. >>>>=20 >>>> Cheers, >>>>=20 >>>> J=C3=A9r=C3=B4me >>>>=20 >>>> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com = >>>> >] >>>> *Sent:* Thursday 14 April 2016 03:22 >>>> *To:* J=C3=A9r=C3=B4me H=C3=A4rri >>>> *Cc:* Alexandre Petrescu; its@ietf.org = > >>>> *Subject:* Re: [its] charter ITS >>>>=20 >>>> Hi J=C3=A9r=C3=B4me, >>>>=20 >>>> I have an opinion on your comment 5) below. >>>>=20 >>>> I think that a list of high-quality papers about IP-based V2V and = V2I >>>>=20 >>>> can teach very useful lessons to software designers of IP in V2V = and V2I >>>>=20 >>>> in the industry. >>>>=20 >>>> Multiple people are working for this IP-based V2V and V2I >>>>=20 >>>> (including Sandra Cespedes and me) in academia and >>>>=20 >>>> more people(including Nabil Benamar) are willing to work for this = area. >>>>=20 >>>> I think we need to utilize the list of such papers as the ground = for our >>>> ITS group >>>>=20 >>>> through a WI. Note that the draft of the list will include the = summary >>>> of the main >>>>=20 >>>> ideas of the papers. >>>>=20 >>>> For the industry current activities for this area, I believe that = you >>>> can share them >>>>=20 >>>> as references through our ITS mailing list rather than through a = WI. >>>>=20 >>>> Could you join my team that are making efforts for a list of such = papers? >>>>=20 >>>> Thanks. >>>>=20 >>>> Best Regards, >>>>=20 >>>> Paul >>>>=20 >>>> On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri = >>>> >> wrote: >>>>=20 >>>> Dear ITSers, Dear Alex, >>>>=20 >>>> Here are some comments on the updated charter: >>>>=20 >>>> 1)Can we keep a reference to IEEE 802.11p, considering it does not = exist >>>> anymore? It is now fully integrated into IEEE 802.11-2012 as OCB = mode >>>> (and 10Mhz @5.9Ghz) of course. >>>>=20 >>>> 2)Should we really keep C-ACC (or Platooning) in the charter = explicitly >>>> as use case, considering it is a seriously controversial aspect = with >>>> some SDOs (ex. In Automotive SDOs)? In the ISO presentation, = Thierry >>>> mentions traffic efficiency/infotainment applications, such as >>>> in-signage applications... >>>>=20 >>>> a.We might have to aim at less controversial use cases to attract >>>> automotive industries >>>>=20 >>>> 3)One potential WI I could think of (rather a basic one): = _definition of >>>> a vehicular wireless =E2=80=98link=E2=80=99 in an automotive = context_ >>>>=20 >>>> a.To me, this is a fundamental brick in the larger IETF WG ITS = house.. >>>>=20 >>>> 4)I would suggest to be more explicit in the foreseen challenges of = this >>>> WG, instead of mentioning general use case (which end up be = controversial) >>>>=20 >>>> a.Example: maintaining IPv6 connectivity in fast and asymmetric = wireless >>>> links; also under quickly changing topologies (actually suggested = by >>>> Dick Roy on the chat room) >>>>=20 >>>> b.Example: IPv6 addressing in link-local scope.. >>>>=20 >>>> c.Example: guaranteeing privacy in IPv6 moving networks etc.. >>>>=20 >>>> 5)Before listing academic papers referring to IPv6 in vehicles, I = would >>>> suggest to first try to list commercial products/solutions that are = in >>>> vehicles and are using IPv6, possibly suffering from a silo = limitations >>>> (ex. restricted to a single technology, single use case=E2=80=A6) >>>>=20 >>>> a.I think we need to get to products first, before academic visions >>>>=20 >>>> My two cents.. >>>>=20 >>>> Best Regards, >>>>=20 >>>> J=C3=A9r=C3=B4me >>>>=20 >>>> *From:*its [mailto:its-bounces@ietf.org = >] >>>> *On Behalf Of *Alexandre Petrescu >>>> *Sent:* Wednesday 06 April 2016 23:45 >>>> *To:* its@ietf.org > >>>> *Subject:* [its] charter ITS >>>>=20 >>>> ITSers, >>>>=20 >>>> Please see below the current charter. >>>>=20 >>>> - the two Problem Statements drafts V2V and V2I joined, so there is = less >>>> text in charter. >>>> - added an Item on "List of Research papers..." >>>>=20 >>>> Erik: did I understand you correctly that there should be some item = on >>>> discussing whether link-local addressing is sufficient, whether = prefix >>>> exchange is necessary? >>>>=20 >>>> Dino: should LISP be included in the gap analysis draft which = includes >>>> C-ACC use-case? OR should we separate a dedicated I-D only with = gap >>>> analysis including ND, MIP, AODVv2, LISP? >>>>=20 >>>> Person from mediatek: is the 'zeroconf' need in the = vehicle-to-vehicle >>>> interface illustrated good enough by the words "moving network to = nearby >>>> moving network communications"? Or is it better to say "the = 1-IP-hop >>>> between nearby moving networks must be self-configured"? >>>>=20 >>>> Nabil, Sandra: is it ok to have a working group item "List of = Research >>>> Papers for IP in V2V and V2I communications"? >>>>=20 >>>> Other comments? >>>>=20 >>>> Alex >>>>=20 >>>> ------------------------------------------------------------------ >>>>=20 >>>> ITS (name to change) >>>> Charter >>>> April 6th, 2016 >>>> http://ietf.org/mailman/listinfo/its = >>>>=20 >>>>=20 >>>> Intelligent Transportation Systems (its) >>>> ---------------------------------------- >>>> Current Status: WG forming >>>>=20 >>>> Chairs: >>>> TBD >>>>=20 >>>> Assigned Area Director: >>>> TBD >>>>=20 >>>> Mailing list >>>> Address: its@ietf.org = > >>>> To Subscribe: https://www.ietf.org/mailman/listinfo/its = >>>> Archive: >>>> http://www.ietf.org/mail-archive/web/its/current/maillist.html = >>>>=20 >>>> Additional web page >>>> TBD >>>>=20 >>>> Charter: >>>>=20 >>>> Goal >>>> ---- >>>> The goal of this group is to standardize IP-based protocols for >>>> establishing direct and secure connectivity between moving = networks, >>>> some of which could be fixed permanently or temporarily. >>>>=20 >>>> Moving Network to Nearby Moving Network Communications >>>> ------------------------------------------------------ >>>> The group is concerned with all situations involving moving network = to >>>> nearby moving network communications. For example: = vehicle-to-vehicle >>>> communications, nomadic user wearing a PAN and communicating to a >>>> homenet, vehicle-to-infrastructure communications, wagon-to-wagon = in a >>>> train, or train-to-intersection signalling. >>>>=20 >>>> Example from the automobile communications space >>>> ------------------------------------------------ >>>> Automobiles and vehicles of all types are increasingly connected to >>>> the Internet, either as vehicle-to-vehicle, vehicle-to-infra or >>>> vehicle-to-Internet. Entertainment apps enhancing comfort, = reliable >>>> data exchanges for road safety, and automated driving are features >>>> coming in automobiles to hit the roads from now to year 2020. >>>> Highlighting increased safety as an immediate result of >>>> hyper-connectivity applied to vehicles, public authorities = worldwide >>>> are increasingly mandating secure communication technology >>>> requirements in vehicles. >>>>=20 >>>> Emergency apps for new instrumented ambulances carry many benefits >>>> both to the users and to society in general. >>>>=20 >>>> Why IP? >>>> ------- >>>> Today, there are several deployed Vehicle-to-Internet technologies, >>>> including car tethering through driver's cellular smartphone. >>>> However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure >>>> communications are still being developed. To improve on a = situation >>>> of link-specific data exchanges, and enable independent application >>>> sets to share the same links, IP data exchanges are needed. = Enabling >>>> IP communication between vehicles (V2V), and between vehicles and = the >>>> immediate infrastructure (V2I), will provide (0) ability to reach = the >>>> rest of the world on the Internet (1) short and deterministic = delays, >>>> (2) fast forwarding through scalable paths of routers, (3) ease of >>>> reuse of existing Internet applications in a vehicular environment. >>>>=20 >>>> Moving network to nearby moving network communications involve link >>>> layers such as: 802.11p OCB (Outside the Context of a Basic Service >>>> Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light >>>> Communications), IrDA, LTE-D. Only the IP protocols are capable of >>>> running on each of these links and establish IP paths across them = in >>>> an interoperable manner. >>>>=20 >>>> Scenarios? >>>> ---------- >>>> There are a few scenarios exhibiting the need to communicate from = one >>>> moving network to another nearby moving network. >>>>=20 >>>> In the automobile space, the Cooperative Adaptive Cruise Control = and >>>> Platooning features consider that vehicles close to each other >>>> exchange data describing their kinematic status. At the = cross-roads, >>>> the moving network inside a vehicle exchanges data with the moving >>>> network in the red-light pole. >>>>=20 >>>> Several public safety scenarios involve moving networks. Distinct >>>> organizations deploy different moving networks (in-vehicle, = on-person) >>>> at an incident scene. These networks need to interoperate in order = to >>>> more effectively understand and deal with the incident scene. >>>>=20 >>>> In connected rail scenarios the moving network deployed in trains >>>> communicate with other moving networks at the cross-points. >>>>=20 >>>> What kind of solutions? >>>> ----------------------- >>>> The current technical solutions considered to achieve moving = network >>>> to nearby moving network communications are of two kinds: IP = routing >>>> protocols for n-hop path management and 1-hop link-scoped IP = protocol >>>> enhancements. The 1-hop link-scoped protocols include the = protocols >>>> for route establishment involving ICMP Router Advertisements. The >>>> n-hop path management protocols include n-hop path establishment >>>> protocols (e.g. Babel, OSPF) and n-hop path search protocols (most >>>> notably AODV and derivates). >>>>=20 >>>> In this proposed Working Group the focus is on 1-hop protocols, and >>>> leverage from other Working Groups for the n-hop situations. >>>>=20 >>>> In some of the moving network applications the window of = opportunity >>>> for exchanging data with the immediate infrastructure may be very >>>> short. For example, a car driving near a road-side unit may have = only >>>> 5s to exchange with that RSU (depending on speed, RSU range and >>>> number). (ephemeral connections). >>>>=20 >>>> What kind of requirements? >>>> -------------------------- >>>> The requirements for mechanisms for moving network to nearby moving >>>> network communications are focusing on low delays of the data = paths, >>>> reduced number of messages for path establishment, application >>>> friendly, resilience to attacks, compatibility with DHCP and Mobile >>>> IP. >>>>=20 >>>> In addition, some moving network to nearby moving network = applications >>>> involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC = the >>>> 1-hop IP moving network to nearby moving netowrk mechanisms will = need >>>> to gracefully support IP multicast. >>>>=20 >>>> Due to the inherent characteristics of safety-related = communications, >>>> all new moving network to nearby moving network mechanisms must = afford >>>> authenticity and confidentiality where necessary. Dynamically >>>> establishing ephemeral communication paths between automobiles in >>>> public areas must offer privacy safeguards for the end users >>>> (passengers). >>>>=20 >>>> Establishing 1-hop IP V2V paths must not break the existing = on-board >>>> protocols and applications which communicate with the Internet, >>>> possibly via multiple radios. >>>>=20 >>>> In a moving network deployed in an automobile, typically one exit >>>> point connects the moving network to other moving networks. = However, >>>> in a more general manner (and to support reliability) any new >>>> mechanism of moving network to nearby moving network communications >>>> should support multi-homing: one router to use multiple interfaces >>>> towards outside the moving network, or multiple routers. >>>>=20 >>>> Current version of Internet protocols >>>> ------------------------------------- >>>> The group will only work on IPv6 solutions. >>>>=20 >>>> What SDOs may need this work? >>>> ----------------------------- >>>> The requirements and standards for moving network to nearby moving >>>> network communications, often involving IPv6, and novel V2V and >>>> V2Infra concepts, are developed mainly at ISO TC204 "Intelligent >>>> Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For >>>> Vehicle-to-Internet communications, 3GPP LTE and other cellular >>>> technologies represent the long-range connectivity method; for >>>> Vehicle-to-Vehicle communications, LTE Direct is currently = specified, >>>> as well as OCB mode of IEEE 802.11. Several use-cases exhibit a = need >>>> for IPv6 data exchanges between vehicles: ETSI's Cooperative = Adaptive >>>> Cruise Control and Platooning. The IEEE developed a popular link = for >>>> short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote = a >>>> set of requirements for V2V communications. >>>>=20 >>>> Work Items >>>> ---------- >>>> - use-cases for moving network to nearby moving network = communications >>>> - Problem Statement for moving network to nearby moving network >>>> communications >>>> including V2V, V2I and DNS. >>>> - Security and Privacy Requirements for moving network to >>>> nearby moving network communications >>>> - Solutions, which might include new protocols or extensions to >>>> existing protocols. With MIB. >>>> - IPv6-over foo, where foo is pertinent for moving network to = nearby >>>> moving network communications (e.g. 802.11 OCB, VLC, LTE-D, = 802.11ad) >>>> - List of Research Papers in the V2V domain, identifying which uses = IP. >>>>=20 >>>> Timeline >>>> -------- >>>> - >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/its = >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>>> Assistant Professor >>>> Department of Software >>>> Sungkyunkwan University >>>> Office: +82-31-299-4957 >>>> Email: jaehoon.paul@gmail.com = >, >>>> pauljeong@skku.edu = > >>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php = >>>> > >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>>> Assistant Professor >>>> Department of Software >>>> Sungkyunkwan University >>>> Office: +82-31-299-4957 >>>> Email: jaehoon.paul@gmail.com = >, >>>> pauljeong@skku.edu = > >>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php = >>>> > >>>>=20 >>>=20 >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its = >> =20 >> =20 >>=20 >> = =09 >> El software de antivirus Avast ha analizado este correo electr=C3=B3nic= o en busca de virus.=20 >> www.avast.com = >> =20 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its = _______________________________= ________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its = --Apple-Mail=_CDB00E7C-A00E-48D1-A979-59DA4845B52C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1
--
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Apr 19, 2016, at 4:26 PM, J=C3=A9r=C3=B4me H=C3=A4rri = (EURECOM) <jerome.haerri@eurecom.fr> wrote:

Dear Nabil, Dear = All,
 
I am one of the = supporters of having IoT in the charter, and I disagree with your = statement on IoT. 
 
There = are plenty of interpretation of what IoT is or is not...the same stands = for vehicular communications...
 
IoT will be transiting via vehicular = communication - we have a testbed, where IoT traffic from embedded = sensors (CAN or non-CAN) are sent to an IoT server on Internet via = ITS-G5/DSRC communication. IoT here is the architecture (oneM2M) that is = above a specific technology, not a technology itself (you are maybe = referring to SigFox or LTE-sensors I guess)..so, our system works if we = use another technology and would even need to work if we have multiple = technologies on the path between the sensors and the  = =E2=80=98cloud=E2=80=99=E2=80=A6here, IPv6 take all of its sense.
 
The = IoT differences in =E2=80=98routing, energy consumption, mac layer=E2=80=99= as you said are actually either fully relevant to the charter, as = referring to IPv6-over-foo or fully irrelevant to IPv6 (as based on IoT = application-level traffic). 
 
Instead of debating whether we should add IoT or keep = vehicular communication, we should debate of what kind of traffic = (M2M-like, stream?, unicast/multicast etc..) will be transiting through = IPv6 communication from a =E2=80=98vehicle=E2=80=99 to either Internet = or another =E2=80=98vehicle=E2=80=99. 
 
And I would like to mention that my suggestion is not to = reduce the focus, but actually to focus on an aspect, where IPv6 does = not have a competitor and can really make a difference.
Said simple: if the charter addresses primarily IPv6 for = critical safety communications, this will be difficult to sell, as other = simpler solutions already work without IPv6. 
 
I = would therefore support and even propose to have a draft  = formulating the problem related to =E2=80=9CIoT-over-IPv6 on moving = networks=E2=80=9D. 
 
Best Regards,
 
J=C3=A9r=C3=B4me
 

Envoy=C3=A9 de mon = iPad
 
 
De: its = [mailto:its-bounces@ietf.org] En nombre de Nabil Benamar
Enviado el: lunes, 18 de abril de 2016 = 4:55
Para: Alexandre Petrescu = <alexandre.petrescu@gmail.com>
CC: its@ietf.org
Asunto: Re: [its] charter ITS - = proposed work items
 
Hi All,
 
I agree on the current charter since these are the points = discussed during the BoF! However there were some replies in this list = mentioning to probably add IoT as an exemple of IP based = communications.  I think that we should keep the focus on vehicular = communications/networks and do not diverge from this topic. IoT is = fundamentally different from vehicular networks in many aspects such as = routing, energy consumption, mac layer, etc...

Best regards
Nabil Benamar
-------------------
=D9=86=D8=A8=D9=8A=D9=84= =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88
 
http://nabilbenamar.ipv6-lab.net/
 
On Thu, Apr 14, 2016 at 9:42 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
ITSers,

We work on a more rigorous ITS charter = text.

Now we propose four work items:

1. "Problem statement for IP in V2V and = V2I"
   including "IP addressing architecture = for V2V and V2I"
   and including "Gap Analysis: = IP protocols suited and gaps"
   and including = "Use-cases for IP in V2V and V2I moving network to
  =                 nearby moving or = fixed network"

2. "Threat Analysis for IP = prefix exchanges in V2V and V2I context"

3. = "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*],
   including connectivity in fast and asymmetric = conditions, coverage
   area vs speed diagrams, = below-IP congestion management.

4. "List of = papers and _products_ using IP in V2V and V2I"

What do you think?

Please = respond by next Monday, April 18th.

Alex = and Dapeng
[*] a typical IP-over-foo document is, for = example, RFC2464
    "Transmission of IPv6 = Packets over Ethernet Networks", where
    "foo" = is instantiated as "Ethernet".  Other IPv6-over-foo documents
    are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 = over PPP" and more.

Le 14/04/2016 09:42, = J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit :

Paul,

Thanks. Btw, when I mentioned =E2=80=98people=E2= =80=99 are aware of IP V2V but not see
the need (so far), = I referred to the automotive SDOs (led by automotive
industries)=E2=80=A6, although there are always =E2=80=98minori= ty reports=E2=80=99 J

Cheers,

J=C3=A9r=C3=B4me

*From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com]
*Sent:* Thursday 14 = April 2016 09:36
*To:* J=C3=A9r=C3=B4me H=C3=A4rri
*Cc:* Alexandre Petrescu; its@ietf.org
*Subject:* Re: [its] charter ITS

J=C3=A9r=C3=B4me,

I missed that = you are also an academic person.

I got it = :-)

I understand your points for industry = activity related to vehicular
networking.

Your observation seems true.

BTW, = I will invite you to my team for the draft for a list of academic
papers for V2V and V2I

by a = personal message.

Thanks.

Paul

On Thu, Apr 14, 2016 at = 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr
<mailto:jerome.haerri@eurecom.fr>> wrote:

Hi Paul,

Thanks for your = feedback. Do not get me wrong, I am an academic and with
my = team, we also work on IP-based V2V and V2I, in particular related to
mobility management with DMM, but also in the context of = vehicular IoT.

I just have the feeling that = people are perfectly aware of the fact that
IP _can_ be = used for V2V and V2I, but does not =E2=80=98_need_=E2=80=99 to be used = as
other solutions already perfectly fit their need. = Listing papers will
not change this awareness.

So, as a complement to academic papers, it = would help to be able to
pin-point which industrial = activities are using or are strongly planning
(short term = I mean) to use pure IPv6 system in vehicles.

My feeling here is we have a different eco-system that the = Automotive
industry (and automotive industry-related = SDO)..more likely the IoT
industry=E2=80=A6and as such, we = should not need to have the (direct)
involvement of = automotive industry in the Charter. If we can make this
clear by an industry-based =E2=80=98survey=E2=80=99, that = would help make the case for
the WG.

Btw, you can count on me your draft..we can add some IP-based = V2V and
V2I for mobility management and also IoT.

Cheers,

J=C3=A9r=C3= =B4me

*From:*Mr. Jaehoon Paul Jeong = [mailto:jaehoon.paul@gmail.com
<mailto:jaehoon.paul@gmail.com>]
*Sent:* = Thursday 14 April 2016 03:22
*To:* J=C3=A9r=C3=B4me = H=C3=A4rri
*Cc:* Alexandre Petrescu; its@ietf.org <mailto:its@ietf.org>
*Subject:* Re: [its] charter ITS

Hi J=C3=A9r=C3=B4me,

I have an = opinion on your comment 5) below.

I think = that a list of high-quality papers about IP-based V2V and V2I

can teach very useful lessons to software = designers of IP in V2V and V2I

in the = industry.

Multiple people are working for = this IP-based V2V and V2I

(including Sandra = Cespedes and me) in academia and

more = people(including Nabil Benamar) are willing to work for this area.

I think we need to utilize the list of such = papers as the ground for our
ITS group

through a WI. Note that the draft of the list will include = the summary
of the main

ideas = of the papers.

For the industry current = activities for this area, I believe that you
can share = them

as references through our ITS mailing = list rather than through a WI.

Could you = join my team that are making efforts for a list of such papers?

Thanks.

Best = Regards,

Paul

On= Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr
<mailto:jerome.haerri@eurecom.fr>> wrote:

Dear ITSers,  Dear Alex,

Here= are some comments on the updated charter:

1)Can we keep a reference to IEEE 802.11p, considering it = does not exist
anymore? It is now fully integrated into = IEEE 802.11-2012 as OCB mode
(and 10Mhz @5.9Ghz) of = course.

2)Should we really keep C-ACC (or = Platooning) in the charter explicitly
as use case, = considering it is a seriously controversial aspect with
some= SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry
mentions traffic efficiency/infotainment applications, such = as
in-signage applications...

a.We might have to aim at less controversial use cases to = attract
automotive industries

3)One potential WI I could think of (rather a basic one): = _definition of
a vehicular wireless =E2=80=98link=E2=80=99 = in an automotive context_

a.To me, this = is  a fundamental brick in the larger IETF WG ITS house..

4)I would suggest to be more explicit in the = foreseen challenges of this
WG, instead of mentioning = general use case (which end up be controversial)

a.Example: maintaining IPv6 connectivity in fast and = asymmetric wireless
links; also under quickly changing = topologies (actually suggested by
Dick Roy on the chat = room)

b.Example: IPv6 addressing in = link-local scope..

c.Example: guaranteeing = privacy in IPv6 moving networks etc..

5)Before listing academic papers referring to IPv6 in = vehicles, I would
suggest to first try to list commercial = products/solutions that are in
vehicles and are using = IPv6, possibly suffering from a silo limitations
(ex. = restricted to a single technology, single use case=E2=80=A6)

a.I think we need to get to products first, = before academic visions

My two cents..

Best Regards,

J=C3=A9r=C3=B4me

*From:*its = [mailto:its-bounces@ietf.org <mailto:its-bounces@ietf.org>]
*On Behalf Of = *Alexandre Petrescu
*Sent:* Wednesday 06 April 2016 = 23:45
*To:* its@ietf.org <mailto:its@ietf.org>
*Subject:* [its] charter ITS

ITSers,

Please see below the = current charter.

- the two Problem = Statements drafts V2V and V2I joined, so there is less
text = in charter.
- added an Item on "List of Research = papers..."

Erik: did I understand you = correctly that there should be some item on
discussing = whether link-local addressing is sufficient, whether prefix
exchange is necessary?

Dino: = should LISP be included in the gap analysis draft which includes
C-ACC use-case?  OR should we separate a dedicated I-D = only with gap
analysis including ND, MIP, AODVv2, LISP?

Person from mediatek: is the 'zeroconf' need = in the vehicle-to-vehicle
interface illustrated good = enough by the words "moving network to nearby
moving = network communications"?  Or is it better to say "the 1-IP-hop
between nearby moving networks must be self-configured"?

Nabil, Sandra: is it ok to have a working = group item "List of Research
Papers for IP in V2V and V2I = communications"?

Other comments?

Alex

---------------------------------------------------------------= ---

          =     ITS (name to change)
      =               Charter
              April 6th, = 2016
http://ietf.org/mailman/listinfo/its


Intelligent Transportation Systems (its)
----------------------------------------
Current = Status: WG forming

Chairs:
    TBD

Assigned Area = Director:
    TBD

Mailing list
    Address: its@ietf.org <mailto:its@ietf.org>
    To Subscribe: https://www.ietf.org/mailman/listinfo/its
    Archive:
http://www.ietf.org/mail-archive/web/its/current/maillist.html<= /a>

Additional web page
  =   TBD

Charter:

Goal
----
The goal of this group = is to standardize IP-based protocols for
establishing = direct and secure connectivity between moving networks,
some= of which could be fixed permanently or temporarily.

Moving Network to Nearby Moving Network Communications
------------------------------------------------------
The group is concerned with all situations involving moving = network to
nearby moving network communications.  For = example: vehicle-to-vehicle
communications, nomadic user = wearing a PAN and communicating to a
homenet, = vehicle-to-infrastructure communications, wagon-to-wagon in a
train, or train-to-intersection signalling.

Example from the automobile communications space
------------------------------------------------
Automobiles and vehicles of all types are increasingly = connected to
the Internet, either as vehicle-to-vehicle, = vehicle-to-infra or
vehicle-to-Internet.  = Entertainment apps enhancing comfort, reliable
data = exchanges for road safety, and automated driving are features
coming in automobiles to hit the roads from now to year = 2020.
Highlighting increased safety as an immediate result = of
hyper-connectivity applied to vehicles, public = authorities worldwide
are increasingly mandating secure = communication technology
requirements in vehicles.

Emergency apps for new instrumented ambulances = carry many benefits
both to the users and to society in = general.

Why IP?
-------
Today, there are several deployed Vehicle-to-Internet = technologies,
including car tethering through driver's = cellular smartphone.
However, Vehicle-to-Vehicle and = Vehicle-to-Infrastructure
communications are still being = developed.  To improve on a situation
of = link-specific data exchanges, and enable independent application
sets to share the same links, IP data exchanges are = needed.  Enabling
IP communication between vehicles = (V2V), and between vehicles and the
immediate = infrastructure (V2I), will provide (0) ability to reach the
rest of the world on the Internet (1) short and deterministic = delays,
(2) fast forwarding through scalable paths of = routers, (3) ease of
reuse of existing Internet = applications in a vehicular environment.

Moving network to nearby moving network communications = involve link
layers such as: 802.11p OCB (Outside the = Context of a Basic Service
Set), 802.15.4 with 6lowpan, = 802.11ac, VLC (Visible Light
Communications), IrDA, = LTE-D.  Only the IP protocols are capable of
running = on each of these links and establish IP paths across them in
an interoperable manner.

Scenarios?
----------
There are a = few scenarios exhibiting the need to communicate from one
moving network to another nearby moving network.

In the automobile space, the Cooperative = Adaptive Cruise Control and
Platooning features consider = that vehicles close to each other
exchange data describing = their kinematic status.  At the cross-roads,
the = moving network inside a vehicle exchanges data with the moving
network in the red-light pole.

Several public safety scenarios involve moving = networks.  Distinct
organizations deploy different = moving networks (in-vehicle, on-person)
at an incident = scene.  These networks need to interoperate in order to
more effectively understand and deal with the incident = scene.

In connected rail scenarios the = moving network deployed in trains
communicate with other = moving networks at the cross-points.

What = kind of solutions?
-----------------------
The= current technical solutions considered to achieve moving network
to nearby moving network communications are of two kinds: IP = routing
protocols for n-hop path management and 1-hop = link-scoped IP protocol
enhancements.  The 1-hop = link-scoped protocols include the protocols
for route = establishment involving ICMP Router Advertisements.  The
n-hop path management protocols include n-hop path = establishment
protocols (e.g. Babel, OSPF) and n-hop path = search protocols (most
notably AODV and derivates).

In this proposed Working Group the focus is on = 1-hop protocols, and
leverage from other Working Groups = for the n-hop situations.

In some of the = moving network applications the window of opportunity
for = exchanging data with the immediate infrastructure may be very
short.  For example, a car driving near a road-side unit = may have only
5s to exchange with that RSU (depending on = speed, RSU range and
number). (ephemeral connections).

What kind of requirements?
--------------------------
The requirements for = mechanisms for moving network to nearby moving
network = communications are focusing on low delays of the data paths,
reduced number of messages for path establishment, = application
friendly, resilience to attacks, compatibility = with DHCP and Mobile
IP.

In = addition, some moving network to nearby moving network applications
involve IP multicast mechanisms (e.g. virtual siren); thus = C-ACC the
1-hop IP moving network to nearby moving netowrk = mechanisms will need
to gracefully support IP = multicast.

Due to the inherent = characteristics of safety-related communications,
all new = moving network to nearby moving network mechanisms must afford
authenticity and confidentiality where necessary.  = Dynamically
establishing ephemeral communication paths = between automobiles in
public areas must offer privacy = safeguards for the end users
(passengers).
Establishing 1-hop IP V2V paths must not break the existing = on-board
protocols and applications which communicate with = the Internet,
possibly via multiple radios.

In a moving network deployed in an automobile, = typically one exit
point connects the moving network to = other moving networks.  However,
in a more general = manner (and to support reliability) any new
mechanism of = moving network to nearby moving network communications
should support multi-homing: one router to use multiple = interfaces
towards outside the moving network, or multiple = routers.

Current version of Internet = protocols
-------------------------------------
The group will only work on IPv6 solutions.

What SDOs may need this work?
-----------------------------
The requirements = and standards for moving network to nearby moving
network = communications, often involving IPv6, and novel V2V and
V2Infra concepts, are developed mainly at ISO TC204 = "Intelligent
Transport Systems", 3GPP, ETSI, NHTSA and = IEEE.  For
Vehicle-to-Internet communications, 3GPP = LTE and other cellular
technologies represent the = long-range connectivity method; for
Vehicle-to-Vehicle = communications, LTE Direct is currently specified,
as well = as OCB mode of IEEE 802.11.  Several use-cases exhibit a need
for IPv6 data exchanges between vehicles: ETSI's Cooperative = Adaptive
Cruise Control and Platooning.  The IEEE = developed a popular link for
short-range communications - = IEEE 802.11p "WAVE".  The NHTSA wrote a
set of = requirements for V2V communications.

Work = Items
----------
- use-cases for moving = network to nearby moving network communications
- Problem = Statement for moving network to nearby moving network
communications
   including V2V, V2I = and DNS.
- Security and Privacy Requirements for moving = network to
   nearby moving network = communications
- Solutions, which might include new = protocols or extensions to
   existing = protocols.  With MIB.
- IPv6-over foo, where foo is = pertinent for moving network to nearby
   moving = network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)
- List of Research Papers in the V2V domain, identifying = which uses IP.

Timeline
--------
-


_______________________________________________
its mailing list
its@ietf.org <mailto:its@ietf.org>
https://www.ietf.org/mailman/listinfo/its


--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>,
pauljeong@skku.edu <mailto:pauljeong@skku.edu>
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>



--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) = Jeong, Ph.D.
Assistant Professor
Department = of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>,
pauljeong@skku.edu <mailto:pauljeong@skku.edu>
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>


_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
 

 

<image001.png>

El software de antivirus Avast ha analizado este correo = electr=C3=B3nico en busca de virus. 
www.avast.com

 
_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
_______________________________________________
its mailing = list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
= --Apple-Mail=_CDB00E7C-A00E-48D1-A979-59DA4845B52C-- From nobody Tue Apr 19 04:52:57 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1525A12D5BA for ; Tue, 19 Apr 2016 04:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.333 X-Spam-Level: X-Spam-Status: No, score=-4.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tsj8k8ZsQ5h for ; Tue, 19 Apr 2016 04:52:53 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E07212D571 for ; Tue, 19 Apr 2016 04:52:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3JBqmR8029395; Tue, 19 Apr 2016 13:52:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6A5F6207276; Tue, 19 Apr 2016 13:54:15 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5C029207231; Tue, 19 Apr 2016 13:54:15 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3JBql8J032130; Tue, 19 Apr 2016 13:52:47 +0200 To: Jong-Hyouk Lee , Thierry Ernst References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> From: Alexandre Petrescu Message-ID: <57161C0F.7000908@gmail.com> Date: Tue, 19 Apr 2016 13:52:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" , "Sri Gundavelli \(sgundave\)" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 11:52:56 -0000 Le 19/04/2016 00:51, Jong-Hyouk Lee a crit : > Alex, -- Jong-Hyouk Lee, living somewhere between /dev/null and > /dev/random Protocol Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com #webpage: > https://sites.google.com/site/hurryon > >> On Apr 19, 2016, at 2:12 AM, Alexandre Petrescu >> > > wrote: >> >> >> >> Le 18/04/2016 17:56, Sri Gundavelli (sgundave) a crit : >>> Hi Jong-Hyouk, >>> >>>> I officially request that we should have a solution for IP >>>> prefix >>> exchanges as a work item. >>> >>> This is one specific approach. The description for the work item >>> can be bit more generic. >> >> Thanks, but I would need a title for it. >> >> How about: >> >> "Solution for 1-hop IP V2V"? >> >> "Solution to establish a 1-hop IP path between nearby moving >> networks or between nearby moving networks and an immediate fixed >> network" >> >> "Solution for Moving/Fixed Network Discovery and 1-hop Path >> Establishment"? >> >> "Solution for end-to-end path establishment in a star topology with >> 1-hop fragile core and n-hop stable edges? > > We may refer the ISO/TC204 liaison link: > https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf > > As presented at the slide #13 above: ISO/TC204 calls "Direct > communication between ITS stations What is an "ITS Station"? Can't we use "Mobile Router" instead? Alex > Its need has been well presented and as expressed at the slides, > ISO/TC204 says"Generically applicable IETF standard is sought on > this otherwise ISO will develop its own Thierry would have a better > idea. Let me him in this loop. > > Note that the request of the development of a solution for direct > communication between ITS stations has a long history and as you may > know because of this request the mnpp protocol > (https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00) was developed > as a result of FP7 EU project, Geonet (design and development of > Geoneworking over IPv6). At that time, there was no place to make it > as RFC at the IETF due to not matured ITS activities at the IETF. > > Cheers. > >> >> Alex >> >>> >>> >>> Sri >>> >>> >>> From: Jong-Hyouk Lee >> > Date: >>> Monday, April 18, 2016 at 8:22 AM To: Sri Gundavelli >>> >>> > Cc: Alexandre Petrescu >>> >> >>> >, "its@ietf.org >>> " >> > Subject: Re: [its] >>> charter ITS - proposed work items >>> >>> Hi Sri, >>> >>> Just one comment regarding IP prefix exchanges. Plz see inline. >>> -- Jong-Hyouk Lee, living somewhere between /dev/null and >>> /dev/random Protocol Engineering Lab., Sangmyung University >>> >>> #email: jonghyouk@gmail.com >>> #webpage: >>> https://sites.google.com/site/hurryon >>> >>>> On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) >>>> >>>> > wrote: >>>> >>>> Alex Inline .. >>>> >>>> >>>> >>>> To: Alexandre Petrescu >>> >>>> > Cc: "its@ietf.org >>>> " >>> > Subject: Re: [its] >>>> charter ITS - proposed work items >>>> >>>> >>>> ITSers, We work on a more rigorous ITS charter text. Now we >>>> propose four work items: 1. "Problem statement for IP in V2V >>>> and V2I" including "IP addressing architecture for V2V and V2I" >>>> and including "Gap Analysis: IP protocols suited and gaps" and >>>> including "Use-cases for IP in V2V and V2I moving network to >>>> nearby moving or fixed network" [Sri] Agree. This is a good >>>> starting point. Use-Cases document is needed. On the Gap >>>> Analysis document, it should be stated as how the gaps are >>>> captured and in relation to what technology. Is it NEMO, MANET, >>>> some other protocols ? >>>> >>>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>>> context" [Sri] If my starting point is #1, not sure how to read >>>> this ? Prefix exchanges appears more like a solution. In MANET >>>> there is exchange of prefixes, in NEMO we dont inject those >>>> prefixes and so I do not know if this work item is valid at >>>> this time. >>> >>> You are right. That is a missing part. We need to have a solution >>> for "IP prefix exchanges in V2V and V2I The need of IP prefix >>> exchanges is clear and well presented in PS documents for IP in >>> V2V and V2I. Then, there are 2 documents already existing as >>> below: >>> >>> 1. >>> https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 >>> >>> 2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 >>> >>> The above 2 documents are the early effort to establish IP >>> direction communications between vehicles and also between a >>> vehicle and a road side unit. >>> >>> I officially request that we should have a solution for IP >>> prefix exchanges as a work item. >>> >>> >>> >>> >>> >>> >>> Cheers! >>>> >>>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo >>>> document[*], including connectivity in fast and asymmetric >>>> conditions, coverage area vs speed diagrams, below-IP >>>> congestion management. >>>> >>>> 4. "List of papers and _products_ using IP in V2V and V2I" >>>> [Sri] Not clear what the deliverable is. >>>> >>>> What do you think? Please respond by next Monday, April 18th. >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>> > From nobody Tue Apr 19 05:16:37 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D65B12EB92 for ; Tue, 19 Apr 2016 05:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnD3TUfz1JFg for ; Tue, 19 Apr 2016 05:16:33 -0700 (PDT) Received: from mail-pa0-x244.google.com (mail-pa0-x244.google.com [IPv6:2607:f8b0:400e:c03::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806B912EAE3 for ; Tue, 19 Apr 2016 05:16:33 -0700 (PDT) Received: by mail-pa0-x244.google.com with SMTP id zy2so1663045pac.2 for ; Tue, 19 Apr 2016 05:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=01QqUSgyIdxlHzzN02W1p93daqFapxqgpFgQPM7CczU=; b=lV+D7OF7TnLSKREZjgxhuAc82bK0dF0Kov8t35+n7Dox7rZ7dEyPwB0ZQJvBdXGT66 7ZzzY206ABfdkMwWhQHNPK0zxpMS32Ychf/C6tRymjBxPJpreWkq1r0IwL5y463IelGo 1tJsMizl8snY1nLt6ETjwU+OmHzbo3rZfcfytc0N1aKy/obuNXULWhl2VhbJbsPQyEh3 l+tgOAEG8VbYAMxx779ycQcL2CdzTy9cqYgifINaCzOM9E443TREMi0OMGjNX7tybMvM QYAZdKKzrg5oAFXComcm0Kybu8j/29eBEsApdnJaTRZgau8Z1QaQyuzPBRakRVjeA29c gg8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=01QqUSgyIdxlHzzN02W1p93daqFapxqgpFgQPM7CczU=; b=g0z8ZTc8Vba5HWcNb8rOKzUYVV7wn622BrWWPrmZ1OBD6/389DpdsNMv6o2iKZZAYL oE85dTfNo4+ZV3NeOq93gyjulzHxAKzHFkbzy1O5RYE1lFd6a5LGMLAX/Th8m6BcAJjv bkcAEKl2d87iS09+pw5Ig9YKMJNw4iMB2xSyREJlIiwj7rqY0TkA+xd9zCTnfhQGvJqJ 3NiXM2FRsJR6aUs80BcH1e5CbqqL1jJWafCKeQ8oFbeNZ/yFfcBRRDHD9e4qrEP3CI5n u7EIDOZAI4SICbRztr2ZDHhncc+VTYI4OxMsepD8a6mkxNzKS3cPYdQFqC1buiQKico5 Z7Ow== X-Gm-Message-State: AOPr4FW6RaC/+jEPB9xla+LUCYRsvsjnqynZwUM10KLKZsukfXsF/GqI6VVpd7l9p2LMwQ== X-Received: by 10.66.153.209 with SMTP id vi17mr3641108pab.0.1461068193083; Tue, 19 Apr 2016 05:16:33 -0700 (PDT) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id a5sm30621422pat.19.2016.04.19.05.16.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Apr 2016 05:16:32 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=windows-1252 From: Jong-Hyouk Lee In-Reply-To: <57161C0F.7000908@gmail.com> Date: Tue, 19 Apr 2016 21:16:27 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> <57161C0F.7000908@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Thierry Ernst , "its@ietf.org" , "Sri Gundavelli \(sgundave\)" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 12:16:36 -0000 -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 19, 2016, at 8:52 PM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 19/04/2016 00:51, Jong-Hyouk Lee a =E9crit : >> Alex, -- Jong-Hyouk Lee, living somewhere between /dev/null and >> /dev/random Protocol Engineering Lab., Sangmyung University >>=20 >> #email: jonghyouk@gmail.com #webpage: >> https://sites.google.com/site/hurryon >>=20 >>> On Apr 19, 2016, at 2:12 AM, Alexandre Petrescu >>> >> > wrote: >>>=20 >>>=20 >>>=20 >>> Le 18/04/2016 17:56, Sri Gundavelli (sgundave) a =E9crit : >>>> Hi Jong-Hyouk, >>>>=20 >>>>> I officially request that we should have a solution for IP >>>>> prefix >>>> exchanges as a work item. >>>>=20 >>>> This is one specific approach. The description for the work item >>>> can be bit more generic. >>>=20 >>> Thanks, but I would need a title for it. >>>=20 >>> How about: >>>=20 >>> "Solution for 1-hop IP V2V"? >>>=20 >>> "Solution to establish a 1-hop IP path between nearby moving >>> networks or between nearby moving networks and an immediate fixed >>> network" >>>=20 >>> "Solution for Moving/Fixed Network Discovery and 1-hop Path >>> Establishment"? >>>=20 >>> "Solution for end-to-end path establishment in a star topology with >>> 1-hop fragile core and n-hop stable edges=94? >>=20 >> We may refer the ISO/TC204 liaison link: >> https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf >>=20 >> As presented at the slide #13 above: ISO/TC204 calls "Direct >> communication between ITS stations=94 >=20 > What is an "ITS Station"? Can't we use "Mobile Router" instead? Alex, come on! How don=92t you know the term used in ISO/TC204. ;) >=20 > Alex >=20 >> Its need has been well presented and as expressed at the slides, >> ISO/TC204 says=85"Generically applicable IETF standard is sought on >> this otherwise ISO will develop its own=94 Thierry would have a = better >> idea. Let me him in this loop. >>=20 >> Note that the request of the development of a solution for direct >> communication between ITS stations has a long history and as you may >> know because of this request the mnpp protocol >> (https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00) was developed >> as a result of FP7 EU project, Geonet (design and development of >> Geoneworking over IPv6). At that time, there was no place to make it >> as RFC at the IETF due to not matured ITS activities at the IETF. >>=20 >> Cheers. >>=20 >>>=20 >>> Alex >>>=20 >>>>=20 >>>>=20 >>>> Sri >>>>=20 >>>>=20 >>>> From: Jong-Hyouk Lee >>> > Date: >>>> Monday, April 18, 2016 at 8:22 AM To: Sri Gundavelli >>>> >>>> > Cc: Alexandre Petrescu >>>> >>> >>>> >, "its@ietf.org >>>> " >>> > Subject: Re: [its] >>>> charter ITS - proposed work items >>>>=20 >>>> Hi Sri, >>>>=20 >>>> Just one comment regarding IP prefix exchanges. Plz see inline. >>>> -- Jong-Hyouk Lee, living somewhere between /dev/null and >>>> /dev/random Protocol Engineering Lab., Sangmyung University >>>>=20 >>>> #email: jonghyouk@gmail.com >>>> #webpage: >>>> https://sites.google.com/site/hurryon >>>>=20 >>>>> On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) >>>>> >>>>> > wrote: >>>>>=20 >>>>> Alex =96 Inline .. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> To: Alexandre Petrescu >>>> >>>>> > Cc: "its@ietf.org >>>>> " >>>> > Subject: Re: [its] >>>>> charter ITS - proposed work items >>>>>=20 >>>>>=20 >>>>> ITSers, We work on a more rigorous ITS charter text. Now we >>>>> propose four work items: 1. "Problem statement for IP in V2V >>>>> and V2I" including "IP addressing architecture for V2V and V2I" >>>>> and including "Gap Analysis: IP protocols suited and gaps" and >>>>> including "Use-cases for IP in V2V and V2I moving network to >>>>> nearby moving or fixed network" [Sri] Agree. This is a good >>>>> starting point. Use-Cases document is needed. On the Gap >>>>> Analysis document, it should be stated as how the gaps are >>>>> captured and in relation to what technology. Is it NEMO, MANET, >>>>> some other protocols ? >>>>>=20 >>>>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>>>> context" [Sri] If my starting point is #1, not sure how to read >>>>> this ? Prefix exchanges appears more like a solution. In MANET >>>>> there is exchange of prefixes, in NEMO we don=92t inject those >>>>> prefixes and so I do not know if this work item is valid at >>>>> this time. >>>>=20 >>>> You are right. That is a missing part. We need to have a solution >>>> for "IP prefix exchanges in V2V and V2I=94 The need of IP prefix >>>> exchanges is clear and well presented in PS documents for IP in >>>> V2V and V2I. Then, there are 2 documents already existing as >>>> below: >>>>=20 >>>> 1. >>>> = https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 >>>>=20 >>>>=20 > 2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 >>>>=20 >>>> The above 2 documents are the early effort to establish IP >>>> direction communications between vehicles and also between a >>>> vehicle and a road side unit. >>>>=20 >>>> I officially request that we should have a solution for IP >>>> prefix exchanges as a work item. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Cheers! >>>>>=20 >>>>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo >>>>> document[*], including connectivity in fast and asymmetric >>>>> conditions, coverage area vs speed diagrams, below-IP >>>>> congestion management. >>>>>=20 >>>>> 4. "List of papers and _products_ using IP in V2V and V2I" >>>>> [Sri] Not clear what the deliverable is. >>>>>=20 >>>>> What do you think? Please respond by next Monday, April 18th. >>>>>=20 >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/its >>>>=20 >>=20 From nobody Tue Apr 19 05:35:42 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8589112DBDD for ; Tue, 19 Apr 2016 05:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.333 X-Spam-Level: X-Spam-Status: No, score=-4.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdKtT09NkeOt for ; Tue, 19 Apr 2016 05:35:39 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C30012DB53 for ; Tue, 19 Apr 2016 05:35:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3JCZXTA015328; Tue, 19 Apr 2016 14:35:33 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 152F3207337; Tue, 19 Apr 2016 14:37:01 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0431B20731E; Tue, 19 Apr 2016 14:37:01 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3JCZXgA016541; Tue, 19 Apr 2016 14:35:33 +0200 To: Jong-Hyouk Lee References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> <57161C0F.7000908@gmail.com> <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> From: Alexandre Petrescu Message-ID: <57162615.7030409@gmail.com> Date: Tue, 19 Apr 2016 14:35:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Thierry Ernst , "its@ietf.org" , "Sri Gundavelli \(sgundave\)" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 12:35:41 -0000 Le 19/04/2016 14:16, Jong-Hyouk Lee a crit : > > -- > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > Protocol Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com > #webpage: https://sites.google.com/site/hurryon > >> On Apr 19, 2016, at 8:52 PM, Alexandre Petrescu wrote: >> >> >> >> Le 19/04/2016 00:51, Jong-Hyouk Lee a crit : >>> Alex, -- Jong-Hyouk Lee, living somewhere between /dev/null and >>> /dev/random Protocol Engineering Lab., Sangmyung University >>> >>> #email: jonghyouk@gmail.com #webpage: >>> https://sites.google.com/site/hurryon >>> >>>> On Apr 19, 2016, at 2:12 AM, Alexandre Petrescu >>>> >>> > wrote: >>>> >>>> >>>> >>>> Le 18/04/2016 17:56, Sri Gundavelli (sgundave) a crit : >>>>> Hi Jong-Hyouk, >>>>> >>>>>> I officially request that we should have a solution for IP >>>>>> prefix >>>>> exchanges as a work item. >>>>> >>>>> This is one specific approach. The description for the work item >>>>> can be bit more generic. >>>> >>>> Thanks, but I would need a title for it. >>>> >>>> How about: >>>> >>>> "Solution for 1-hop IP V2V"? >>>> >>>> "Solution to establish a 1-hop IP path between nearby moving >>>> networks or between nearby moving networks and an immediate fixed >>>> network" >>>> >>>> "Solution for Moving/Fixed Network Discovery and 1-hop Path >>>> Establishment"? >>>> >>>> "Solution for end-to-end path establishment in a star topology with >>>> 1-hop fragile core and n-hop stable edges? >>> >>> We may refer the ISO/TC204 liaison link: >>> https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf >>> >>> As presented at the slide #13 above: ISO/TC204 calls "Direct >>> communication between ITS stations >> >> What is an "ITS Station"? Can't we use "Mobile Router" instead? > > Alex, come on! How dont you know the term used in ISO/TC204. ;) I know. But at IETF we use the term "Mobile Router" extensively. I guess we need a Terminology section which says: ITS Station == Mobile Router == modem(s) because some car manufacturers use the term "modem" extensively even today. Alex > >> >> Alex >> >>> Its need has been well presented and as expressed at the slides, >>> ISO/TC204 says"Generically applicable IETF standard is sought on >>> this otherwise ISO will develop its own Thierry would have a better >>> idea. Let me him in this loop. >>> >>> Note that the request of the development of a solution for direct >>> communication between ITS stations has a long history and as you may >>> know because of this request the mnpp protocol >>> (https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00) was developed >>> as a result of FP7 EU project, Geonet (design and development of >>> Geoneworking over IPv6). At that time, there was no place to make it >>> as RFC at the IETF due to not matured ITS activities at the IETF. >>> >>> Cheers. >>> >>>> >>>> Alex >>>> >>>>> >>>>> >>>>> Sri >>>>> >>>>> >>>>> From: Jong-Hyouk Lee >>>> > Date: >>>>> Monday, April 18, 2016 at 8:22 AM To: Sri Gundavelli >>>>> >>>>> > Cc: Alexandre Petrescu >>>>> >>>> >>>>> >, "its@ietf.org >>>>> " >>>> > Subject: Re: [its] >>>>> charter ITS - proposed work items >>>>> >>>>> Hi Sri, >>>>> >>>>> Just one comment regarding IP prefix exchanges. Plz see inline. >>>>> -- Jong-Hyouk Lee, living somewhere between /dev/null and >>>>> /dev/random Protocol Engineering Lab., Sangmyung University >>>>> >>>>> #email: jonghyouk@gmail.com >>>>> #webpage: >>>>> https://sites.google.com/site/hurryon >>>>> >>>>>> On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) >>>>>> >>>>>> > wrote: >>>>>> >>>>>> Alex Inline .. >>>>>> >>>>>> >>>>>> >>>>>> To: Alexandre Petrescu >>>>> >>>>>> > Cc: "its@ietf.org >>>>>> " >>>>> > Subject: Re: [its] >>>>>> charter ITS - proposed work items >>>>>> >>>>>> >>>>>> ITSers, We work on a more rigorous ITS charter text. Now we >>>>>> propose four work items: 1. "Problem statement for IP in V2V >>>>>> and V2I" including "IP addressing architecture for V2V and V2I" >>>>>> and including "Gap Analysis: IP protocols suited and gaps" and >>>>>> including "Use-cases for IP in V2V and V2I moving network to >>>>>> nearby moving or fixed network" [Sri] Agree. This is a good >>>>>> starting point. Use-Cases document is needed. On the Gap >>>>>> Analysis document, it should be stated as how the gaps are >>>>>> captured and in relation to what technology. Is it NEMO, MANET, >>>>>> some other protocols ? >>>>>> >>>>>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>>>>> context" [Sri] If my starting point is #1, not sure how to read >>>>>> this ? Prefix exchanges appears more like a solution. In MANET >>>>>> there is exchange of prefixes, in NEMO we dont inject those >>>>>> prefixes and so I do not know if this work item is valid at >>>>>> this time. >>>>> >>>>> You are right. That is a missing part. We need to have a solution >>>>> for "IP prefix exchanges in V2V and V2I The need of IP prefix >>>>> exchanges is clear and well presented in PS documents for IP in >>>>> V2V and V2I. Then, there are 2 documents already existing as >>>>> below: >>>>> >>>>> 1. >>>>> https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 >>>>> >>>>> >> 2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 >>>>> >>>>> The above 2 documents are the early effort to establish IP >>>>> direction communications between vehicles and also between a >>>>> vehicle and a road side unit. >>>>> >>>>> I officially request that we should have a solution for IP >>>>> prefix exchanges as a work item. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Cheers! >>>>>> >>>>>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo >>>>>> document[*], including connectivity in fast and asymmetric >>>>>> conditions, coverage area vs speed diagrams, below-IP >>>>>> congestion management. >>>>>> >>>>>> 4. "List of papers and _products_ using IP in V2V and V2I" >>>>>> [Sri] Not clear what the deliverable is. >>>>>> >>>>>> What do you think? Please respond by next Monday, April 18th. >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>> > > From nobody Tue Apr 19 05:40:10 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E5712D5D6 for ; Tue, 19 Apr 2016 05:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-Qbl70UzLk4 for ; Tue, 19 Apr 2016 05:40:01 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id BC09712D11E for ; Tue, 19 Apr 2016 05:40:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,506,1454972400"; d="scan'208";a="3692434" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 19 Apr 2016 14:39:59 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 7E6AEBA0; Tue, 19 Apr 2016 14:39:59 +0200 (CEST) From: =?iso-8859-1?B?Suly9G1lIEjkcnJp?= To: "'Alexandre Petrescu'" , "'Jong-Hyouk Lee'" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> <57161C0F.7000908@gmail.com> <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> <57162615.7030409@gmail.com> In-Reply-To: <57162615.7030409@gmail.com> Date: Tue, 19 Apr 2016 14:39:59 +0200 Organization: EURECOM Message-ID: <019001d19a38$95f543e0$c1dfcba0$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt54qCPzaRhlgKe35lrbFRjfOAYQFS/geMAQE6Hj0B9Z2NrAFvPFpVAgXLDlYCka3YAQMdMLXxAUzb8LECRGlilAG8xmrSAKyaAyQCPmMKCwFGVqWNAjGPs4QC/dmE9ALMOLvaAWKgvq0BEnePGwMxjKzlAkTIw3kBhQwK758V19XA Content-Language: en-us Archived-At: Cc: 'Thierry Ernst' , its@ietf.org, "'Sri Gundavelli \(sgundave\)'" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 12:40:08 -0000 Hi Alex, All, I would not say Mobile Router =3D=3D ITS-S =3D=3D Modem=20 We need to look at the functions. The ITS-S the overall 'system' = consisting of the ITS stack (at least at ETSI, but I guess similar at ISO), while = the MR is the routing layer and the modem is the Access Layer. But it could = be nice to try to come to a joint naming across SDOs...maybe another WI?? Cheers, J=E9r=F4me -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Tuesday 19 April 2016 14:36 To: Jong-Hyouk Lee Cc: Thierry Ernst; its@ietf.org; Sri Gundavelli (sgundave) Subject: Re: [its] charter ITS - proposed work items Le 19/04/2016 14:16, Jong-Hyouk Lee a =E9crit : > > -- > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random=20 > Protocol Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com > #webpage: https://sites.google.com/site/hurryon > >> On Apr 19, 2016, at 8:52 PM, Alexandre Petrescu wrote: >> >> >> >> Le 19/04/2016 00:51, Jong-Hyouk Lee a =E9crit : >>> Alex, -- Jong-Hyouk Lee, living somewhere between /dev/null and=20 >>> /dev/random Protocol Engineering Lab., Sangmyung University >>> >>> #email: jonghyouk@gmail.com #webpage: >>> https://sites.google.com/site/hurryon >>> >>>> On Apr 19, 2016, at 2:12 AM, Alexandre Petrescu=20 >>>> >>> > wrote: >>>> >>>> >>>> >>>> Le 18/04/2016 17:56, Sri Gundavelli (sgundave) a =E9crit : >>>>> Hi Jong-Hyouk, >>>>> >>>>>> I officially request that we should have a solution for IP prefix >>>>> exchanges as a work item. >>>>> >>>>> This is one specific approach. The description for the work item=20 >>>>> can be bit more generic. >>>> >>>> Thanks, but I would need a title for it. >>>> >>>> How about: >>>> >>>> "Solution for 1-hop IP V2V"? >>>> >>>> "Solution to establish a 1-hop IP path between nearby moving=20 >>>> networks or between nearby moving networks and an immediate fixed=20 >>>> network" >>>> >>>> "Solution for Moving/Fixed Network Discovery and 1-hop Path=20 >>>> Establishment"? >>>> >>>> "Solution for end-to-end path establishment in a star topology with = >>>> 1-hop fragile core and n-hop stable edges=94? >>> >>> We may refer the ISO/TC204 liaison link: >>> https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf >>> >>> As presented at the slide #13 above: ISO/TC204 calls "Direct=20 >>> communication between ITS stations=94 >> >> What is an "ITS Station"? Can't we use "Mobile Router" instead? > > Alex, come on! How don=92t you know the term used in ISO/TC204. ;) I know. But at IETF we use the term "Mobile Router" extensively. I guess we need a Terminology section which says: ITS Station =3D=3D Mobile Router =3D=3D modem(s) because some car manufacturers use the term "modem" extensively even = today. Alex > >> >> Alex >> >>> Its need has been well presented and as expressed at the slides, >>> ISO/TC204 says=85"Generically applicable IETF standard is sought on=20 >>> this otherwise ISO will develop its own=94 Thierry would have a = better=20 >>> idea. Let me him in this loop. >>> >>> Note that the request of the development of a solution for direct=20 >>> communication between ITS stations has a long history and as you may = >>> know because of this request the mnpp protocol >>> (https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00) was developed = >>> as a result of FP7 EU project, Geonet (design and development of=20 >>> Geoneworking over IPv6). At that time, there was no place to make it = >>> as RFC at the IETF due to not matured ITS activities at the IETF. >>> >>> Cheers. >>> >>>> >>>> Alex >>>> >>>>> >>>>> >>>>> Sri >>>>> >>>>> >>>>> From: Jong-Hyouk Lee >>>> > Date: >>>>> Monday, April 18, 2016 at 8:22 AM To: Sri Gundavelli=20 >>>>> =20 >>>>> > Cc: Alexandre Petrescu=20 >>>>> >>>> >>>>> >, "its@ietf.org=20 >>>>> " >>>> > Subject: Re: [its]=20 >>>>> charter ITS - proposed work items >>>>> >>>>> Hi Sri, >>>>> >>>>> Just one comment regarding IP prefix exchanges. Plz see inline. >>>>> -- Jong-Hyouk Lee, living somewhere between /dev/null and=20 >>>>> /dev/random Protocol Engineering Lab., Sangmyung University >>>>> >>>>> #email: jonghyouk@gmail.com =20 >>>>> #webpage: >>>>> https://sites.google.com/site/hurryon >>>>> >>>>>> On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave)=20 >>>>>> =20 >>>>>> > wrote: >>>>>> >>>>>> Alex =96 Inline .. >>>>>> >>>>>> >>>>>> >>>>>> To: Alexandre Petrescu >>>>> >>>>>> > Cc: "its@ietf.org=20 >>>>>> " >>>>> > Subject: Re: [its]=20 >>>>>> charter ITS - proposed work items >>>>>> >>>>>> >>>>>> ITSers, We work on a more rigorous ITS charter text. Now we=20 >>>>>> propose four work items: 1. "Problem statement for IP in V2V and=20 >>>>>> V2I" including "IP addressing architecture for V2V and V2I" >>>>>> and including "Gap Analysis: IP protocols suited and gaps" and=20 >>>>>> including "Use-cases for IP in V2V and V2I moving network to=20 >>>>>> nearby moving or fixed network" [Sri] Agree. This is a good=20 >>>>>> starting point. Use-Cases document is needed. On the Gap Analysis = >>>>>> document, it should be stated as how the gaps are captured and in = >>>>>> relation to what technology. Is it NEMO, MANET, some other=20 >>>>>> protocols ? >>>>>> >>>>>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I=20 >>>>>> context" [Sri] If my starting point is #1, not sure how to read=20 >>>>>> this ? Prefix exchanges appears more like a solution. In MANET=20 >>>>>> there is exchange of prefixes, in NEMO we don=92t inject those=20 >>>>>> prefixes and so I do not know if this work item is valid at this=20 >>>>>> time. >>>>> >>>>> You are right. That is a missing part. We need to have a solution=20 >>>>> for "IP prefix exchanges in V2V and V2I=94 The need of IP prefix=20 >>>>> exchanges is clear and well presented in PS documents for IP in=20 >>>>> V2V and V2I. Then, there are 2 documents already existing as >>>>> below: >>>>> >>>>> 1. >>>>> https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routi >>>>> ng-00 >>>>> >>>>> >> 2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 >>>>> >>>>> The above 2 documents are the early effort to establish IP=20 >>>>> direction communications between vehicles and also between a=20 >>>>> vehicle and a road side unit. >>>>> >>>>> I officially request that we should have a solution for IP prefix=20 >>>>> exchanges as a work item. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Cheers! >>>>>> >>>>>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*],=20 >>>>>> including connectivity in fast and asymmetric conditions,=20 >>>>>> coverage area vs speed diagrams, below-IP congestion management. >>>>>> >>>>>> 4. "List of papers and _products_ using IP in V2V and V2I" >>>>>> [Sri] Not clear what the deliverable is. >>>>>> >>>>>> What do you think? Please respond by next Monday, April 18th. >>>>>> >>>>>> _______________________________________________ its mailing list=20 >>>>>> its@ietf.org =20 >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>> > > _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Tue Apr 19 05:43:49 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4CF12DC21 for ; Tue, 19 Apr 2016 05:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuDMHXuWRhyZ for ; Tue, 19 Apr 2016 05:43:44 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F56A12D826 for ; Tue, 19 Apr 2016 05:43:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3JChdNT018367; Tue, 19 Apr 2016 14:43:39 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5EFA7207312; Tue, 19 Apr 2016 14:45:06 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4B7C8207248; Tue, 19 Apr 2016 14:45:06 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3JChc3b025060; Tue, 19 Apr 2016 14:43:38 +0200 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Jong-Hyouk Lee'" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> <57161C0F.7000908@gmail.com> <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> <57162615.7030409@gmail.com> <019001d19a38$95f543e0$c1dfcba0$@eurecom.fr> From: Alexandre Petrescu Message-ID: <571627FA.8050607@gmail.com> Date: Tue, 19 Apr 2016 14:43:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <019001d19a38$95f543e0$c1dfcba0$@eurecom.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Thierry Ernst' , its@ietf.org, "'Sri Gundavelli \(sgundave\)'" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 12:43:48 -0000 Le 19/04/2016 14:39, Jrme Hrri a crit : > Hi Alex, All, > > I would not say Mobile Router == ITS-S == Modem The problem is that for each of these terms, there are strong defenders: IETF RFC, ISO/TC204 document, and car manufacturer. > We need to look at the functions. I agree. > The ITS-S the overall 'system' consisting of the ITS stack (at least > at ETSI, but I guess similar at ISO), while the MR is the routing > layer and the modem is the Access Layer. But it could be nice to try > to come to a joint naming across SDOs...maybe another WI?? The terminology direction you give is relevant. However, no new WI because there are already too many. IETF documents have a Terminology section... Alex > > Cheers, > > Jrme > > -----Original Message----- From: its [mailto:its-bounces@ietf.org] On > Behalf Of Alexandre Petrescu Sent: Tuesday 19 April 2016 14:36 To: > Jong-Hyouk Lee Cc: Thierry Ernst; its@ietf.org; Sri Gundavelli > (sgundave) Subject: Re: [its] charter ITS - proposed work items > > > > Le 19/04/2016 14:16, Jong-Hyouk Lee a crit : >> >> -- Jong-Hyouk Lee, living somewhere between /dev/null and >> /dev/random Protocol Engineering Lab., Sangmyung University >> >> #email: jonghyouk@gmail.com #webpage: >> https://sites.google.com/site/hurryon >> >>> On Apr 19, 2016, at 8:52 PM, Alexandre Petrescu > wrote: >>> >>> >>> >>> Le 19/04/2016 00:51, Jong-Hyouk Lee a crit : >>>> Alex, -- Jong-Hyouk Lee, living somewhere between /dev/null >>>> and /dev/random Protocol Engineering Lab., Sangmyung >>>> University >>>> >>>> #email: jonghyouk@gmail.com >>>> #webpage: https://sites.google.com/site/hurryon >>>> >>>>> On Apr 19, 2016, at 2:12 AM, Alexandre Petrescu >>>>> >>>> > wrote: >>>>> >>>>> >>>>> >>>>> Le 18/04/2016 17:56, Sri Gundavelli (sgundave) a crit : >>>>>> Hi Jong-Hyouk, >>>>>> >>>>>>> I officially request that we should have a solution for >>>>>>> IP prefix >>>>>> exchanges as a work item. >>>>>> >>>>>> This is one specific approach. The description for the work >>>>>> item can be bit more generic. >>>>> >>>>> Thanks, but I would need a title for it. >>>>> >>>>> How about: >>>>> >>>>> "Solution for 1-hop IP V2V"? >>>>> >>>>> "Solution to establish a 1-hop IP path between nearby moving >>>>> networks or between nearby moving networks and an immediate >>>>> fixed network" >>>>> >>>>> "Solution for Moving/Fixed Network Discovery and 1-hop Path >>>>> Establishment"? >>>>> >>>>> "Solution for end-to-end path establishment in a star >>>>> topology with 1-hop fragile core and n-hop stable edges"? >>>> >>>> We may refer the ISO/TC204 liaison link: >>>> https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf >>>> >>>> As presented at the slide #13 above: ISO/TC204 calls "Direct >>>> communication between ITS stations" >>> >>> What is an "ITS Station"? Can't we use "Mobile Router" instead? >> >> Alex, come on! How don't you know the term used in ISO/TC204. ;) > > I know. But at IETF we use the term "Mobile Router" extensively. > > I guess we need a Terminology section which says: ITS Station == > Mobile Router == modem(s) > > because some car manufacturers use the term "modem" extensively even > today. > > Alex > >> >>> >>> Alex >>> >>>> Its need has been well presented and as expressed at the >>>> slides, ISO/TC204 says."Generically applicable IETF standard is >>>> sought on this otherwise ISO will develop its own" Thierry >>>> would have a better idea. Let me him in this loop. >>>> >>>> Note that the request of the development of a solution for >>>> direct communication between ITS stations has a long history >>>> and as you may know because of this request the mnpp protocol >>>> (https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00) was >>>> developed as a result of FP7 EU project, Geonet (design and >>>> development of Geoneworking over IPv6). At that time, there was >>>> no place to make it as RFC at the IETF due to not matured ITS >>>> activities at the IETF. >>>> >>>> Cheers. >>>> >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> >>>>>> Sri >>>>>> >>>>>> >>>>>> From: Jong-Hyouk Lee >>>>> > >>>>>> Date: Monday, April 18, 2016 at 8:22 AM To: Sri Gundavelli >>>>>> >>>>>> > Cc: Alexandre Petrescu >>>>>> >>>>> >>>>>> >, "its@ietf.org >>>>>> " >>>>> > Subject: Re: >>>>>> [its] charter ITS - proposed work items >>>>>> >>>>>> Hi Sri, >>>>>> >>>>>> Just one comment regarding IP prefix exchanges. Plz see >>>>>> inline. -- Jong-Hyouk Lee, living somewhere between >>>>>> /dev/null and /dev/random Protocol Engineering Lab., >>>>>> Sangmyung University >>>>>> >>>>>> #email: jonghyouk@gmail.com >>>>>> #webpage: >>>>>> https://sites.google.com/site/hurryon >>>>>> >>>>>>> On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) >>>>>>> >>>>>>> > wrote: >>>>>>> >>>>>>> Alex - Inline .. >>>>>>> >>>>>>> >>>>>>> >>>>>>> To: Alexandre Petrescu >>>>>> >>>>>>> > Cc: "its@ietf.org >>>>>>> " >>>>>>> >>>>>>> > Subject: Re: [its] charter ITS - >>>>>>> proposed work items >>>>>>> >>>>>>> >>>>>>> ITSers, We work on a more rigorous ITS charter text. Now >>>>>>> we propose four work items: 1. "Problem statement for IP >>>>>>> in V2V and V2I" including "IP addressing architecture for >>>>>>> V2V and V2I" and including "Gap Analysis: IP protocols >>>>>>> suited and gaps" and including "Use-cases for IP in V2V >>>>>>> and V2I moving network to nearby moving or fixed network" >>>>>>> [Sri] Agree. This is a good starting point. Use-Cases >>>>>>> document is needed. On the Gap Analysis document, it >>>>>>> should be stated as how the gaps are captured and in >>>>>>> relation to what technology. Is it NEMO, MANET, some >>>>>>> other protocols ? >>>>>>> >>>>>>> 2. "Threat Analysis for IP prefix exchanges in V2V and >>>>>>> V2I context" [Sri] If my starting point is #1, not sure >>>>>>> how to read this ? Prefix exchanges appears more like a >>>>>>> solution. In MANET there is exchange of prefixes, in NEMO >>>>>>> we don't inject those prefixes and so I do not know if >>>>>>> this work item is valid at this time. >>>>>> >>>>>> You are right. That is a missing part. We need to have a >>>>>> solution for "IP prefix exchanges in V2V and V2I" The need >>>>>> of IP prefix exchanges is clear and well presented in PS >>>>>> documents for IP in V2V and V2I. Then, there are 2 >>>>>> documents already existing as below: >>>>>> >>>>>> 1. >>>>>> https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routi >>>>>> >>>>>> ng-00 >>>>>> >>>>>> >>> 2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 >>>>>> >>>>>> The above 2 documents are the early effort to establish IP >>>>>> direction communications between vehicles and also between >>>>>> a vehicle and a road side unit. >>>>>> >>>>>> I officially request that we should have a solution for IP >>>>>> prefix exchanges as a work item. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Cheers! >>>>>>> >>>>>>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo >>>>>>> document[*], including connectivity in fast and >>>>>>> asymmetric conditions, coverage area vs speed diagrams, >>>>>>> below-IP congestion management. >>>>>>> >>>>>>> 4. "List of papers and _products_ using IP in V2V and >>>>>>> V2I" [Sri] Not clear what the deliverable is. >>>>>>> >>>>>>> What do you think? Please respond by next Monday, April >>>>>>> 18th. >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>> >> >> > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Tue Apr 19 05:46:32 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E4A12E539 for ; Tue, 19 Apr 2016 05:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAomcDS9pmb8 for ; Tue, 19 Apr 2016 05:46:28 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1FD12E52B for ; Tue, 19 Apr 2016 05:46:28 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id p185so1679390pfb.3 for ; Tue, 19 Apr 2016 05:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=hPAraIJfFnMRw0torcdnQBHmQkh6GWuX593Wf4zYLys=; b=M72nZ7MMOubBJSRBvMmt26FAmOQIuuZ3sYVDjfaoXhYrasK7Mwa9qEWkyS5/fnplnv jCPpHfXDd9+ABIBBnEArignQqLSe1gntu9QWpjWpP809Z6gfaaZTPQX3GuqJ4Eb5QDIT 3UVz2epGFsWd7YmteGWXX2iAziSNgB0oy7DdHE7wuQfh94OPdR7WWtyjoyOqbCNQ3NTg YIHL/5/MMS2FGqZs1Cnw7q+ed7qVHd2WDYD0sUzY7wHV0hreBvLndA8ikPjmHOspddKz b6h3As2s/q5d1Akv9UIeUMwK6dhzrBLsiRKocxw8bICFrj+yuKDhp97+0kjoT3VjZHlc vI+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=hPAraIJfFnMRw0torcdnQBHmQkh6GWuX593Wf4zYLys=; b=Tkl/sdPRsn9RwM0EfZWEMGU+d7lWNSXNJqjWkJFUZdUYkpnMfq/pf0VYtIgJPyq+72 9qgEAnuUwwejaPeiEmlzDT0cl1BfDgtR5uYRct0iJoJS+/5q1ecJYYpHNqvyZy+rPwFK iM2BYZx195pFkkJPHa1Lmg/u3+RmrSA45+BMfqxjz4VgiP8szrnLyM6jP5OtKgdxTXRV uuCPTJnY0OKkxCmNwQ5dYVmU5qdcWEAipbNIa7e4SMd9EUJWXMxFOANMEGrrYfe9z+E5 kjmkWtgBLmNCHeKWh+A9sbkClDMONEdUXdoUvjlFlyUitWbH7Zxpawg2GNHwAWp0Fh/V S3GQ== X-Gm-Message-State: AOPr4FXL1SMpPJ3UjvIOM0T/VKJkFDz6uCf8Eqp7KNjpj4WqhWofU6SBDE2jdwUrsrWwzw== X-Received: by 10.98.16.198 with SMTP id 67mr3759664pfq.21.1461069988098; Tue, 19 Apr 2016 05:46:28 -0700 (PDT) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id a205sm23214041pfa.6.2016.04.19.05.46.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Apr 2016 05:46:26 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_08BA44E1-F15F-4078-AEF7-0962523EAE5C" From: Jong-Hyouk Lee In-Reply-To: <57162615.7030409@gmail.com> Date: Tue, 19 Apr 2016 21:46:20 +0900 Message-Id: <88F8BA46-40B6-49E6-B44A-8AE1F27C84BD@gmail.com> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> <57161C0F.7000908@gmail.com> <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> <57162615.7030409@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Thierry Ernst , "its@ietf.org" , "Sri Gundavelli \(sgundave\)" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 12:46:30 -0000 --Apple-Mail=_08BA44E1-F15F-4078-AEF7-0962523EAE5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Plz see inline. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 19, 2016, at 9:35 PM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 19/04/2016 14:16, Jong-Hyouk Lee a =E9crit : >>=20 >> -- >> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >> Protocol Engineering Lab., Sangmyung University >>=20 >> #email: jonghyouk@gmail.com >> #webpage: https://sites.google.com/site/hurryon >>=20 >>> On Apr 19, 2016, at 8:52 PM, Alexandre Petrescu = wrote: >>>=20 >>>=20 >>>=20 >>> Le 19/04/2016 00:51, Jong-Hyouk Lee a =E9crit : >>>> Alex, -- Jong-Hyouk Lee, living somewhere between /dev/null and >>>> /dev/random Protocol Engineering Lab., Sangmyung University >>>>=20 >>>> #email: jonghyouk@gmail.com #webpage: >>>> https://sites.google.com/site/hurryon >>>>=20 >>>>> On Apr 19, 2016, at 2:12 AM, Alexandre Petrescu >>>>> >>>> > wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Le 18/04/2016 17:56, Sri Gundavelli (sgundave) a =E9crit : >>>>>> Hi Jong-Hyouk, >>>>>>=20 >>>>>>> I officially request that we should have a solution for IP >>>>>>> prefix >>>>>> exchanges as a work item. >>>>>>=20 >>>>>> This is one specific approach. The description for the work item >>>>>> can be bit more generic. >>>>>=20 >>>>> Thanks, but I would need a title for it. >>>>>=20 >>>>> How about: >>>>>=20 >>>>> "Solution for 1-hop IP V2V"? >>>>>=20 >>>>> "Solution to establish a 1-hop IP path between nearby moving >>>>> networks or between nearby moving networks and an immediate fixed >>>>> network" >>>>>=20 >>>>> "Solution for Moving/Fixed Network Discovery and 1-hop Path >>>>> Establishment"? >>>>>=20 >>>>> "Solution for end-to-end path establishment in a star topology = with >>>>> 1-hop fragile core and n-hop stable edges=94? >>>>=20 >>>> We may refer the ISO/TC204 liaison link: >>>> https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf >>>>=20 >>>> As presented at the slide #13 above: ISO/TC204 calls "Direct >>>> communication between ITS stations=94 >>>=20 >>> What is an "ITS Station"? Can't we use "Mobile Router" instead? >>=20 >> Alex, come on! How don=92t you know the term used in ISO/TC204. ;) >=20 > I know. But at IETF we use the term "Mobile Router" extensively. >=20 > I guess we need a Terminology section which says: > ITS Station =3D=3D Mobile Router =3D=3D modem(s) Hmmmmm=85I agree we need the terminology section in one document (I do = not know which one would be good for the terminology section). Anyway, = what you said is wrong.=20 There are 4 types of cooperative ITS stations: Personal ITS station = (e.g., smartphone), Vehicle ITS station, Roadside ITS station, and = Central ITS station. Then, for example, at a vehicle ITS station, a = vehicle ITS station gateway, ITS station host, and ITS station router = may exist. Those are connected each other on the ITS station internal = network. The vehicle ITS station gateway is connected to ECUs on = propriety in-vehicle network. The ITS station router is the one used to = connect to other side (e.g., Roadside ITS station or Internet). So, the = mobile router we are calling here at the IETF is the ITS station router = at the ISO/TC 204 standardisations.=20 Cheers. >=20 > because some car manufacturers use the term "modem" extensively even = today. >=20 > Alex >=20 >>=20 >>>=20 >>> Alex >>>=20 >>>> Its need has been well presented and as expressed at the slides, >>>> ISO/TC204 says=85"Generically applicable IETF standard is sought on >>>> this otherwise ISO will develop its own=94 Thierry would have a = better >>>> idea. Let me him in this loop. >>>>=20 >>>> Note that the request of the development of a solution for direct >>>> communication between ITS stations has a long history and as you = may >>>> know because of this request the mnpp protocol >>>> (https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00) was = developed >>>> as a result of FP7 EU project, Geonet (design and development of >>>> Geoneworking over IPv6). At that time, there was no place to make = it >>>> as RFC at the IETF due to not matured ITS activities at the IETF. >>>>=20 >>>> Cheers. >>>>=20 >>>>>=20 >>>>> Alex >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Sri >>>>>>=20 >>>>>>=20 >>>>>> From: Jong-Hyouk Lee >>>>> > Date: >>>>>> Monday, April 18, 2016 at 8:22 AM To: Sri Gundavelli >>>>>> >>>>>> > Cc: Alexandre Petrescu >>>>>> >>>>> >>>>>> >, "its@ietf.org >>>>>> " >>>>> > Subject: Re: [its] >>>>>> charter ITS - proposed work items >>>>>>=20 >>>>>> Hi Sri, >>>>>>=20 >>>>>> Just one comment regarding IP prefix exchanges. Plz see inline. >>>>>> -- Jong-Hyouk Lee, living somewhere between /dev/null and >>>>>> /dev/random Protocol Engineering Lab., Sangmyung University >>>>>>=20 >>>>>> #email: jonghyouk@gmail.com >>>>>> #webpage: >>>>>> https://sites.google.com/site/hurryon >>>>>>=20 >>>>>>> On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) >>>>>>> >>>>>>> > wrote: >>>>>>>=20 >>>>>>> Alex =96 Inline .. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> To: Alexandre Petrescu >>>>>> >>>>>>> > Cc: "its@ietf.org >>>>>>> " >>>>>> > Subject: Re: [its] >>>>>>> charter ITS - proposed work items >>>>>>>=20 >>>>>>>=20 >>>>>>> ITSers, We work on a more rigorous ITS charter text. Now we >>>>>>> propose four work items: 1. "Problem statement for IP in V2V >>>>>>> and V2I" including "IP addressing architecture for V2V and V2I" >>>>>>> and including "Gap Analysis: IP protocols suited and gaps" and >>>>>>> including "Use-cases for IP in V2V and V2I moving network to >>>>>>> nearby moving or fixed network" [Sri] Agree. This is a good >>>>>>> starting point. Use-Cases document is needed. On the Gap >>>>>>> Analysis document, it should be stated as how the gaps are >>>>>>> captured and in relation to what technology. Is it NEMO, MANET, >>>>>>> some other protocols ? >>>>>>>=20 >>>>>>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>>>>>> context" [Sri] If my starting point is #1, not sure how to read >>>>>>> this ? Prefix exchanges appears more like a solution. In MANET >>>>>>> there is exchange of prefixes, in NEMO we don=92t inject those >>>>>>> prefixes and so I do not know if this work item is valid at >>>>>>> this time. >>>>>>=20 >>>>>> You are right. That is a missing part. We need to have a solution >>>>>> for "IP prefix exchanges in V2V and V2I=94 The need of IP prefix >>>>>> exchanges is clear and well presented in PS documents for IP in >>>>>> V2V and V2I. Then, there are 2 documents already existing as >>>>>> below: >>>>>>=20 >>>>>> 1. >>>>>> = https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 >>>>>>=20 >>>>>>=20 >>> 2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 >>>>>>=20 >>>>>> The above 2 documents are the early effort to establish IP >>>>>> direction communications between vehicles and also between a >>>>>> vehicle and a road side unit. >>>>>>=20 >>>>>> I officially request that we should have a solution for IP >>>>>> prefix exchanges as a work item. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Cheers! >>>>>>>=20 >>>>>>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo >>>>>>> document[*], including connectivity in fast and asymmetric >>>>>>> conditions, coverage area vs speed diagrams, below-IP >>>>>>> congestion management. >>>>>>>=20 >>>>>>> 4. "List of papers and _products_ using IP in V2V and V2I" >>>>>>> [Sri] Not clear what the deliverable is. >>>>>>>=20 >>>>>>> What do you think? Please respond by next Monday, April 18th. >>>>>>>=20 >>>>>>> _______________________________________________ its mailing >>>>>>> list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_08BA44E1-F15F-4078-AEF7-0962523EAE5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Plz see inline.
--
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Apr 19, 2016, at 9:35 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:



Le 19/04/2016 14:16, Jong-Hyouk Lee a = =E9crit :

--
Jong-Hyouk Lee, living somewhere between = /dev/null and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Apr 19, 2016, at 8:52 = PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:



Le 19/04/2016 00:51, Jong-Hyouk = Lee a =E9crit :
Alex, = -- Jong-Hyouk Lee, living somewhere between /dev/null and
/dev/random Protocol Engineering Lab., Sangmyung = University

#email: jonghyouk@gmail.com = <mailto:jonghyouk@gmail.com> #webpage:
https://sites.google.com/site/hurryon

On Apr 19, 2016, at 2:12 = AM, Alexandre Petrescu
<alexandre.petrescu@gmail.com
<mailto:alexandre.petrescu@gmail.com>> wrote:



Le 18/04/2016 = 17:56, Sri Gundavelli (sgundave) a =E9crit :
Hi Jong-Hyouk,

I officially request = that we should have a solution for IP
prefix
exchanges as a work item.

This is one specific approach. The description for the work = item
can be bit more generic.
Thanks, but I would need a title for it.

How about:

"Solution for 1-hop = IP V2V"?

"Solution to establish a 1-hop IP = path between nearby moving
networks or between nearby = moving networks and an immediate fixed
network"

"Solution for Moving/Fixed Network Discovery = and 1-hop Path
Establishment"?

"Solution for end-to-end path establishment in a star = topology with
1-hop fragile core and n-hop stable = edges=94?

We may refer the = ISO/TC204 liaison link:
https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf<= br class=3D"">
As presented at the slide #13 above: = ISO/TC204 calls "Direct
communication between ITS = stations=94

What is an "ITS = Station"?  Can't we use "Mobile Router" instead?

Alex, come on! How don=92t you = know the term used in ISO/TC204. ;)

I know.  But = at IETF we use the term "Mobile Router" extensively.

I guess we need a Terminology section = which says:
ITS Station =3D=3D Mobile Router  =3D=3D = modem(s)

Hmmmmm=85I = agree we need the terminology section in one document (I do not know = which one would be good for the terminology section). Anyway, what you = said is wrong. 

There are 4 = types of cooperative ITS stations: Personal ITS station (e.g., = smartphone), Vehicle ITS station, Roadside ITS station, and Central ITS = station. Then, for example, at a vehicle ITS station, a vehicle ITS = station gateway, ITS station host, and ITS station router may exist. = Those are connected each other on the ITS station internal network. The = vehicle ITS station gateway is connected to ECUs on propriety in-vehicle = network. The ITS station router is the one used to connect to other side = (e.g., Roadside ITS station or Internet). So, the mobile router we are = calling here at the IETF is the ITS station router at the ISO/TC 204 = standardisations. 

Cheers.


because some car manufacturers use the = term "modem" extensively even today.

Alex



Alex

Its need = has been well presented and as expressed at the slides,
ISO/TC204 says=85"Generically applicable IETF standard is = sought on
this otherwise ISO will develop its own=94 = Thierry would have a better
idea. Let me him in this = loop.

Note that the request of the = development of a solution for direct
communication between = ITS stations has a long history and as you may
know = because of this request the mnpp protocol
(https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00) was = developed
as a result of FP7 EU project, Geonet (design = and development of
Geoneworking over IPv6). At that time, = there was no place to make it
as RFC at the IETF due to = not matured ITS activities at the IETF.

Cheers.


Alex



Sri


From: Jong-Hyouk Lee <jonghyouk@gmail.com
<mailto:jonghyouk@gmail.com> <mailto:jonghyouk@gmail.com>> Date:
Monday, April 18, 2016 at 8:22 AM To: Sri Gundavelli
<sgundave@cisco.com <mailto:sgundave@cisco.com>
<mailto:sgundave@cisco.com>> Cc: Alexandre = Petrescu
<alexandre.petrescu@gmail.com
<mailto:alexandre.petrescu@gmail.com>
<mailto:alexandre.petrescu@gmail.com>>, "its@ietf.org
<mailto:its@ietf.org> <mailto:its@ietf.org>" <its@ietf.org
<mailto:its@ietf.org> <mailto:its@ietf.org>> Subject: Re: [its]
charter ITS - proposed work items

Hi Sri,

Just one comment = regarding IP prefix exchanges. Plz see inline.
-- = Jong-Hyouk Lee, living somewhere between /dev/null and
/dev/random Protocol Engineering Lab., Sangmyung = University

#email: jonghyouk@gmail.com = <mailto:jonghyouk@gmail.com>
<mailto:jonghyouk@gmail.com> #webpage:
https://sites.google.com/site/hurryon

On Apr 18, 2016, at = 11:51 PM, Sri Gundavelli (sgundave)
<sgundave@cisco.com = <mailto:sgundave@cisco.com>
<mailto:sgundave@cisco.com>> wrote:

Alex =96 Inline ..



To: Alexandre Petrescu = <alexandre.petrescu@gmail.com
<mailto:alexandre.petrescu@gmail.com>
<mailto:alexandre.petrescu@gmail.com>> Cc: = "its@ietf.org
<mailto:its@ietf.org> = <mailto:its@ietf.org>" <its@ietf.org
<mailto:its@ietf.org> <mailto:its@ietf.org>> = Subject: Re: [its]
charter ITS - proposed work items


ITSers, We work on a more = rigorous ITS charter text. Now we
propose four work items: = 1. "Problem statement for IP in V2V
and V2I" including "IP = addressing architecture for V2V and V2I"
and including = "Gap Analysis: IP protocols suited and gaps" and
including = "Use-cases for IP in V2V and V2I moving network to
nearby = moving or fixed network" [Sri] Agree. This is a good
starting point. Use-Cases document is needed. On the Gap
Analysis document, it should be stated as how the gaps are
captured and in relation to what technology. Is it NEMO, = MANET,
some other protocols ?

2. "Threat Analysis for IP prefix exchanges in V2V and V2I
context" [Sri] If my starting point is #1, not sure how to = read
this ? Prefix exchanges appears more like a solution. = In MANET
there is exchange of prefixes, in NEMO we don=92t = inject those
prefixes and so I do not know if this work = item is valid at
this time.

You are right. That is a missing part. We need to have a = solution
for "IP prefix exchanges in V2V and V2I=94 The = need of IP prefix
exchanges is clear and well presented in = PS documents for IP in
V2V and V2I. Then, there are 2 = documents already existing as
below:

1.
https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-ro= uting-00


2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00

The above = 2 documents are the early effort to establish IP
direction = communications between vehicles and also between a
vehicle = and a road side unit.

I officially request = that we should have a solution for IP
prefix exchanges as = a work item.






Cheers!

3. "IP = over DSRC (802.11-OCB)" typical IP-over-foo
document[*], = including connectivity in fast and asymmetric
conditions, = coverage area vs speed diagrams, below-IP
congestion = management.

4. "List of papers and = _products_ using IP in V2V and V2I"
[Sri] Not clear what = the deliverable is.

What do you think? = Please respond by next Monday, April 18th.

_______________________________________________ its = mailing
list its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org>
https://www.ietf.org/mailman/listinfo/its

= --Apple-Mail=_08BA44E1-F15F-4078-AEF7-0962523EAE5C-- From nobody Tue Apr 19 06:11:49 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B223912EA7A for ; Tue, 19 Apr 2016 06:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85PznOzCq0IM for ; Tue, 19 Apr 2016 06:11:42 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C6512EAE3 for ; Tue, 19 Apr 2016 06:11:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3JDBWft029114; Tue, 19 Apr 2016 15:11:32 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 05A9F207383; Tue, 19 Apr 2016 15:13:00 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E5BE4207395; Tue, 19 Apr 2016 15:12:59 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3JDBWZ9024327; Tue, 19 Apr 2016 15:11:32 +0200 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJpIChFVVJFQ09NKSA=?= , "'Nabil Benamar'" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <04ae01d199bf$3d2938d0$b77baa70$@ing.uchile.cl> <004b01d19a0c$bb4632c0$31d29840$@eurecom.fr> From: Alexandre Petrescu Message-ID: <57162E84.9030507@gmail.com> Date: Tue, 19 Apr 2016 15:11:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <004b01d19a0c$bb4632c0$31d29840$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: its@ietf.org, =?UTF-8?Q?'Sandra_C=c3=a9spedes'?= Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 13:11:48 -0000 Jérôme, I agree with many things that you say below. The platform that you have looks very interesting - you send data from CAN things through 802.11-OCB, all the way to the Internet (V2Internet); IPv6 has its perfect place there. You ask whether the draft proposes IPv6 mainly for safety-criticial apps: no, the current text uses other motivators for IPv6. But, I can't suggest an IoT work item right now in the Charter. We never talked about it and there are already 5 items. Maybe you want us to just use some "IoT" text in the charter? like in saying to leverage other IETF IoT-related work like 6lo and LP-WAN? If yes, we'll see that in a few days when we announce the preliminary charter. Please keep "IoT" in mind. Otherwise, if you really want an IoT work item, you may do: - ask Jong-Hyouk and others to join your effort. - write an Internet Draft as individual submission (not work item) that would answer some questions, among which: - is IoT-over-IP an application? Which application? For example, an application is remote software update of Things in a vehicle. What Thing more precisely? The map storer? The airbag controller? - what is the relationship between IoT-over-IP and V2V, V2I, I2V, V2Internet? - is "I" losing meaning if IoT is in moving network to moving network fully disconnected from the Internet? - can we use just "T" (Things) in order to realize some relevant V2V use-cases? For example, at IETF they created this T2T (thing to thing) effort. - if "IoT" is a Colgate barcode, what is a car license plate? - present. ... and see where is the tract. Alex Le 19/04/2016 09:26, Jérôme Härri (EURECOM) a écrit : > Dear Nabil, Dear All, > > I am one of the supporters of having IoT in the charter, and I disagree > with your statement on IoT. > > There are plenty of interpretation of what IoT is or is not...the same > stands for vehicular communications... > > IoT will be transiting via vehicular communication - we have a testbed, > where IoT traffic from embedded sensors (CAN or non-CAN) are sent to an > IoT server on Internet via ITS-G5/DSRC communication. IoT here is the > architecture (oneM2M) that is above a specific technology, not a > technology itself (you are maybe referring to SigFox or LTE-sensors I > guess)..so, our system works if we use another technology and would even > need to work if we have multiple technologies on the path between the > sensors and the ‘cloud’…here, IPv6 take all of its sense. > > The IoT differences in ‘routing, energy consumption, mac layer’ as you > said are actually either fully relevant to the charter, as referring to > IPv6-over-foo or fully irrelevant to IPv6 (as based on IoT > application-level traffic). > > Instead of debating whether we should add IoT or keep vehicular > communication, we should debate of what kind of traffic (M2M-like, > stream?, unicast/multicast etc..) will be transiting through IPv6 > communication from a ‘vehicle’ to either Internet or another ‘vehicle’. > > And I would like to mention that my suggestion is not to reduce the > focus, but actually to focus on an aspect, where IPv6 does not have a > competitor and can really make a difference. > > Said simple: if the charter addresses primarily IPv6 for critical safety > communications, this will be difficult to sell, as other simpler > solutions already work without IPv6. > > I would therefore support and even propose to have a draft formulating > the problem related to “IoT-over-IPv6 on moving networks”. > > Best Regards, > > Jérôme > > > > Envoyé de mon iPad > > *De:*its [mailto:its-bounces@ietf.org] *En nombre de *Nabil Benamar > *Enviado el:* lunes, 18 de abril de 2016 4:55 > *Para:* Alexandre Petrescu > > *CC:* its@ietf.org > *Asunto:* Re: [its] charter ITS - proposed work items > > Hi All, > > I agree on the current charter since these are the points discussed > during the BoF! However there were some replies in this list > mentioning to probably add IoT as an exemple of IP based > communications. I think that we should keep the focus on vehicular > communications/networks and do not diverge from this topic. IoT is > fundamentally different from vehicular networks in many aspects such > as routing, energy consumption, mac layer, etc... > > > Best regards > > Nabil Benamar > > ------------------- > > نبيل بنعمرو > > http://nabilbenamar.ipv6-lab.net/ > > On Thu, Apr 14, 2016 at 9:42 AM, Alexandre Petrescu > > > wrote: > > ITSers, > > We work on a more rigorous ITS charter text. > > Now we propose four work items: > > 1. "Problem statement for IP in V2V and V2I" > including "IP addressing architecture for V2V and V2I" > and including "Gap Analysis: IP protocols suited and gaps" > and including "Use-cases for IP in V2V and V2I moving network to > nearby moving or fixed network" > > 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" > > 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], > including connectivity in fast and asymmetric conditions, > coverage > area vs speed diagrams, below-IP congestion management. > > 4. "List of papers and _products_ using IP in V2V and V2I" > > What do you think? > > Please respond by next Monday, April 18th. > > Alex and Dapeng > [*] a typical IP-over-foo document is, for example, RFC2464 > "Transmission of IPv6 Packets over Ethernet Networks", where > "foo" is instantiated as "Ethernet". Other IPv6-over-foo > documents > are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" > and more. > > Le 14/04/2016 09:42, Jérôme Härri a écrit : > > Paul, > > Thanks. Btw, when I mentioned ‘people’ are aware of IP V2V > but not see > the need (so far), I referred to the automotive SDOs (led by > automotive > industries)…, although there are always ‘minority reports’ J > > Cheers, > > Jérôme > > *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com > ] > *Sent:* Thursday 14 April 2016 09:36 > *To:* Jérôme Härri > *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [its] charter ITS > > Jérôme, > > I missed that you are also an academic person. > > I got it :-) > > I understand your points for industry activity related to > vehicular > networking. > > Your observation seems true. > > BTW, I will invite you to my team for the draft for a list > of academic > papers for V2V and V2I > > by a personal message. > > Thanks. > > Paul > > On Thu, Apr 14, 2016 at 4:09 PM, Jérôme Härri > > >> wrote: > > Hi Paul, > > Thanks for your feedback. Do not get me wrong, I am an > academic and with > my team, we also work on IP-based V2V and V2I, in particular > related to > mobility management with DMM, but also in the context of > vehicular IoT. > > I just have the feeling that people are perfectly aware of > the fact that > IP _can_ be used for V2V and V2I, but does not ‘_need_’ to > be used as > other solutions already perfectly fit their need. Listing > papers will > not change this awareness. > > So, as a complement to academic papers, it would help to be > able to > pin-point which industrial activities are using or are > strongly planning > (short term I mean) to use pure IPv6 system in vehicles. > > My feeling here is we have a different eco-system that the > Automotive > industry (and automotive industry-related SDO)..more likely > the IoT > industry…and as such, we should not need to have the (direct) > involvement of automotive industry in the Charter. If we can > make this > clear by an industry-based ‘survey’, that would help make > the case for > the WG. > > Btw, you can count on me your draft..we can add some > IP-based V2V and > V2I for mobility management and also IoT. > > Cheers, > > Jérôme > > *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com > > >] > *Sent:* Thursday 14 April 2016 03:22 > *To:* Jérôme Härri > *Cc:* Alexandre Petrescu; its@ietf.org > > > *Subject:* Re: [its] charter ITS > > Hi Jérôme, > > I have an opinion on your comment 5) below. > > I think that a list of high-quality papers about IP-based > V2V and V2I > > can teach very useful lessons to software designers of IP in > V2V and V2I > > in the industry. > > Multiple people are working for this IP-based V2V and V2I > > (including Sandra Cespedes and me) in academia and > > more people(including Nabil Benamar) are willing to work for > this area. > > I think we need to utilize the list of such papers as the > ground for our > ITS group > > through a WI. Note that the draft of the list will include > the summary > of the main > > ideas of the papers. > > For the industry current activities for this area, I believe > that you > can share them > > as references through our ITS mailing list rather than > through a WI. > > Could you join my team that are making efforts for a list of > such papers? > > Thanks. > > Best Regards, > > Paul > > On Thu, Apr 7, 2016 at 8:11 AM, Jérôme Härri > > >> wrote: > > Dear ITSers, Dear Alex, > > Here are some comments on the updated charter: > > 1)Can we keep a reference to IEEE 802.11p, considering it > does not exist > anymore? It is now fully integrated into IEEE 802.11-2012 as > OCB mode > (and 10Mhz @5.9Ghz) of course. > > 2)Should we really keep C-ACC (or Platooning) in the charter > explicitly > as use case, considering it is a seriously controversial > aspect with > some SDOs (ex. In Automotive SDOs)? In the ISO presentation, > Thierry > mentions traffic efficiency/infotainment applications, such as > in-signage applications... > > a.We might have to aim at less controversial use cases to > attract > automotive industries > > 3)One potential WI I could think of (rather a basic one): > _definition of > a vehicular wireless ‘link’ in an automotive context_ > > a.To me, this is a fundamental brick in the larger IETF WG > ITS house.. > > 4)I would suggest to be more explicit in the foreseen > challenges of this > WG, instead of mentioning general use case (which end up be > controversial) > > a.Example: maintaining IPv6 connectivity in fast and > asymmetric wireless > links; also under quickly changing topologies (actually > suggested by > Dick Roy on the chat room) > > b.Example: IPv6 addressing in link-local scope.. > > c.Example: guaranteeing privacy in IPv6 moving networks etc.. > > 5)Before listing academic papers referring to IPv6 in > vehicles, I would > suggest to first try to list commercial products/solutions > that are in > vehicles and are using IPv6, possibly suffering from a silo > limitations > (ex. restricted to a single technology, single use case…) > > a.I think we need to get to products first, before academic > visions > > My two cents.. > > Best Regards, > > Jérôme > > *From:*its [mailto:its-bounces@ietf.org > >] > *On Behalf Of *Alexandre Petrescu > *Sent:* Wednesday 06 April 2016 23:45 > *To:* its@ietf.org > > > *Subject:* [its] charter ITS > > ITSers, > > Please see below the current charter. > > - the two Problem Statements drafts V2V and V2I joined, so > there is less > text in charter. > - added an Item on "List of Research papers..." > > Erik: did I understand you correctly that there should be > some item on > discussing whether link-local addressing is sufficient, > whether prefix > exchange is necessary? > > Dino: should LISP be included in the gap analysis draft > which includes > C-ACC use-case? OR should we separate a dedicated I-D only > with gap > analysis including ND, MIP, AODVv2, LISP? > > Person from mediatek: is the 'zeroconf' need in the > vehicle-to-vehicle > interface illustrated good enough by the words "moving > network to nearby > moving network communications"? Or is it better to say "the > 1-IP-hop > between nearby moving networks must be self-configured"? > > Nabil, Sandra: is it ok to have a working group item "List > of Research > Papers for IP in V2V and V2I communications"? > > Other comments? > > Alex > > ------------------------------------------------------------------ > > ITS (name to change) > Charter > April 6th, 2016 > http://ietf.org/mailman/listinfo/its > > > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming > > Chairs: > TBD > > Assigned Area Director: > TBD > > Mailing list > Address: its@ietf.org > > > 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: > > Goal > ---- > The goal of this group is to standardize IP-based protocols for > establishing direct and secure connectivity between moving > networks, > some of which could be fixed permanently or temporarily. > > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving > network to > nearby moving network communications. For example: > vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating > to a > homenet, vehicle-to-infrastructure communications, > wagon-to-wagon in a > train, or train-to-intersection signalling. > > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly > connected to > the Internet, either as vehicle-to-vehicle, vehicle-to-infra or > vehicle-to-Internet. Entertainment apps enhancing comfort, > reliable > data exchanges for road safety, and automated driving are > features > coming in automobiles to hit the roads from now to year 2020. > Highlighting increased safety as an immediate result of > hyper-connectivity applied to vehicles, public authorities > worldwide > are increasingly mandating secure communication technology > requirements in vehicles. > > Emergency apps for new instrumented ambulances carry many > benefits > both to the users and to society in general. > > Why IP? > ------- > Today, there are several deployed Vehicle-to-Internet > technologies, > including car tethering through driver's cellular smartphone. > However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure > communications are still being developed. To improve on a > situation > of link-specific data exchanges, and enable independent > application > sets to share the same links, IP data exchanges are needed. > Enabling > IP communication between vehicles (V2V), and between > vehicles and the > immediate infrastructure (V2I), will provide (0) ability to > reach the > rest of the world on the Internet (1) short and > deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) > ease of > reuse of existing Internet applications in a vehicular > environment. > > Moving network to nearby moving network communications > involve link > layers such as: 802.11p OCB (Outside the Context of a Basic > Service > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light > Communications), IrDA, LTE-D. Only the IP protocols are > capable of > running on each of these links and establish IP paths across > them in > an interoperable manner. > > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate > from one > moving network to another nearby moving network. > > In the automobile space, the Cooperative Adaptive Cruise > Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the > cross-roads, > the moving network inside a vehicle exchanges data with the > moving > network in the red-light pole. > > Several public safety scenarios involve moving networks. > Distinct > organizations deploy different moving networks (in-vehicle, > on-person) > at an incident scene. These networks need to interoperate > in order to > more effectively understand and deal with the incident scene. > > In connected rail scenarios the moving network deployed in > trains > communicate with other moving networks at the cross-points. > > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving > network > to nearby moving network communications are of two kinds: IP > routing > protocols for n-hop path management and 1-hop link-scoped IP > protocol > enhancements. The 1-hop link-scoped protocols include the > protocols > for route establishment involving ICMP Router > Advertisements. The > n-hop path management protocols include n-hop path establishment > protocols (e.g. Babel, OSPF) and n-hop path search protocols > (most > notably AODV and derivates). > > In this proposed Working Group the focus is on 1-hop > protocols, and > leverage from other Working Groups for the n-hop situations. > > In some of the moving network applications the window of > opportunity > for exchanging data with the immediate infrastructure may be > very > short. For example, a car driving near a road-side unit may > have only > 5s to exchange with that RSU (depending on speed, RSU range and > number). (ephemeral connections). > > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to nearby > moving > network communications are focusing on low delays of the > data paths, > reduced number of messages for path establishment, application > friendly, resilience to attacks, compatibility with DHCP and > Mobile > IP. > > In addition, some moving network to nearby moving network > applications > involve IP multicast mechanisms (e.g. virtual siren); thus > C-ACC the > 1-hop IP moving network to nearby moving netowrk mechanisms > will need > to gracefully support IP multicast. > > Due to the inherent characteristics of safety-related > communications, > all new moving network to nearby moving network mechanisms > must afford > authenticity and confidentiality where necessary. Dynamically > establishing ephemeral communication paths between > automobiles in > public areas must offer privacy safeguards for the end users > (passengers). > > Establishing 1-hop IP V2V paths must not break the existing > on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. > > In a moving network deployed in an automobile, typically one > exit > point connects the moving network to other moving networks. > However, > in a more general manner (and to support reliability) any new > mechanism of moving network to nearby moving network > communications > should support multi-homing: one router to use multiple > interfaces > towards outside the moving network, or multiple routers. > > Current version of Internet protocols > ------------------------------------- > The group will only work on IPv6 solutions. > > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to nearby > moving > network communications, often involving IPv6, and novel V2V and > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For > Vehicle-to-Internet communications, 3GPP LTE and other cellular > technologies represent the long-range connectivity method; for > Vehicle-to-Vehicle communications, LTE Direct is currently > specified, > as well as OCB mode of IEEE 802.11. Several use-cases > exhibit a need > for IPv6 data exchanges between vehicles: ETSI's Cooperative > Adaptive > Cruise Control and Platooning. The IEEE developed a popular > link for > short-range communications - IEEE 802.11p "WAVE". The NHTSA > wrote a > set of requirements for V2V communications. > > Work Items > ---------- > - use-cases for moving network to nearby moving network > communications > - Problem Statement for moving network to nearby moving network > communications > including V2V, V2I and DNS. > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Solutions, which might include new protocols or extensions to > existing protocols. With MIB. > - IPv6-over foo, where foo is pertinent for moving network > to nearby > moving network communications (e.g. 802.11 OCB, VLC, > LTE-D, 802.11ad) > - List of Research Papers in the V2V domain, identifying > which uses IP. > > Timeline > -------- > - > > > _______________________________________________ > its mailing list > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com > > >, > pauljeong@skku.edu > > > Personal Homepage: > http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com > > >, > pauljeong@skku.edu > > > Personal Homepage: > http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > ------------------------------------------------------------------------ > > Avast logo > > > > > El software de antivirus Avast ha analizado este correo electrónico > en busca de virus. > www.avast.com > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Tue Apr 19 06:20:20 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4707E12DBB1 for ; Tue, 19 Apr 2016 06:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.333 X-Spam-Level: X-Spam-Status: No, score=-4.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvV2RHnJ_Drn for ; Tue, 19 Apr 2016 06:20:17 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9090F12D5D8 for ; Tue, 19 Apr 2016 06:20:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3JDKBIK032104; Tue, 19 Apr 2016 15:20:11 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8326F207336; Tue, 19 Apr 2016 15:21:38 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 71431200C5F; Tue, 19 Apr 2016 15:21:38 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3JDKAP7001857; Tue, 19 Apr 2016 15:20:11 +0200 To: Jong-Hyouk Lee References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> <57161C0F.7000908@gmail.com> <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> <57162615.7030409@gmail.com> <88F8BA46-40B6-49E6-B44A-8AE1F27C84BD@gmail.com> From: Alexandre Petrescu Message-ID: <5716308A.9030107@gmail.com> Date: Tue, 19 Apr 2016 15:20:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <88F8BA46-40B6-49E6-B44A-8AE1F27C84BD@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Thierry Ernst , "its@ietf.org" , "Sri Gundavelli \(sgundave\)" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 13:20:19 -0000 Jong-Hyouk, Le 19/04/2016 14:46, Jong-Hyouk Lee a crit : > Plz see inline. > -- > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > Protocol Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com > #webpage: https://sites.google.com/site/hurryon > >> On Apr 19, 2016, at 9:35 PM, Alexandre Petrescu >> > >> wrote: >> >> >> >> Le 19/04/2016 14:16, Jong-Hyouk Lee a crit : >>> >>> -- >>> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >>> Protocol Engineering Lab., Sangmyung University >>> >>> #email: jonghyouk@gmail.com >>> #webpage: https://sites.google.com/site/hurryon >>> >>>> On Apr 19, 2016, at 8:52 PM, Alexandre Petrescu >>>> > >>>> wrote: >>>> >>>> >>>> >>>> Le 19/04/2016 00:51, Jong-Hyouk Lee a crit : >>>>> Alex, -- Jong-Hyouk Lee, living somewhere between /dev/null and >>>>> /dev/random Protocol Engineering Lab., Sangmyung University >>>>> >>>>> #email: jonghyouk@gmail.com >>>>> #webpage: >>>>> https://sites.google.com/site/hurryon >>>>> >>>>>> On Apr 19, 2016, at 2:12 AM, Alexandre Petrescu >>>>>> >>>>> > wrote: >>>>>> >>>>>> >>>>>> >>>>>> Le 18/04/2016 17:56, Sri Gundavelli (sgundave) a crit : >>>>>>> Hi Jong-Hyouk, >>>>>>> >>>>>>>> I officially request that we should have a solution for IP >>>>>>>> prefix >>>>>>> exchanges as a work item. >>>>>>> >>>>>>> This is one specific approach. The description for the work item >>>>>>> can be bit more generic. >>>>>> >>>>>> Thanks, but I would need a title for it. >>>>>> >>>>>> How about: >>>>>> >>>>>> "Solution for 1-hop IP V2V"? >>>>>> >>>>>> "Solution to establish a 1-hop IP path between nearby moving >>>>>> networks or between nearby moving networks and an immediate fixed >>>>>> network" >>>>>> >>>>>> "Solution for Moving/Fixed Network Discovery and 1-hop Path >>>>>> Establishment"? >>>>>> >>>>>> "Solution for end-to-end path establishment in a star topology with >>>>>> 1-hop fragile core and n-hop stable edges? >>>>> >>>>> We may refer the ISO/TC204 liaison link: >>>>> https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf >>>>> >>>>> As presented at the slide #13 above: ISO/TC204 calls "Direct >>>>> communication between ITS stations >>>> >>>> What is an "ITS Station"? Can't we use "Mobile Router" instead? >>> >>> Alex, come on! How dont you know the term used in ISO/TC204. ;) >> >> I know. But at IETF we use the term "Mobile Router" extensively. >> >> I guess we need a Terminology section which says: >> ITS Station == Mobile Router == modem(s) > > HmmmmmI agree we need the terminology section in one document (I do not > know which one would be good for the terminology section). This is the current list. Maybe in 1. 1. "Problem statement for IP in V2V and V2I" including "IP addressing architecture for V2V and V2I" and including "Gap Analysis: IP protocols suited and gaps" and including "Use-cases for IP in V2V and V2I moving network To nearby moving or fixed network" 2. "Threat Analysis for IP prefix exchanges in V2V and V2I Context" 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document, including connectivity in fast and asymmetric conditions, coverage area vs speed diagrams, below-IP congestion management. 4. "List of papers and _products_ using IP in V2V and V2I" 5. "Solution for direct communication between Mobile Routers" > Anyway, what > you said is wrong. > > There are 4 types of cooperative ITS stations: Personal ITS station > (e.g., smartphone), Vehicle ITS station, Roadside ITS station, and > Central ITS station. Then, for example, at a vehicle ITS station, a > vehicle ITS station gateway, ITS station host, and ITS station router > may exist. ITS station gateway - does not sound correct order of words(?) What's the difference between ITS station router and ITS station gateway? > Those are connected each other on the ITS station internal > network. The vehicle ITS station gateway is connected to ECUs on > propriety in-vehicle network. The ITS station router is the one used to > connect to other side (e.g., Roadside ITS station or Internet). So, the > mobile router we are calling here at the IETF is the ITS station router > at the ISO/TC 204 standardisations. Makes sense. Alex > > Cheers. > >> >> because some car manufacturers use the term "modem" extensively even >> today. >> >> Alex >> >>> >>>> >>>> Alex >>>> >>>>> Its need has been well presented and as expressed at the slides, >>>>> ISO/TC204 says"Generically applicable IETF standard is sought on >>>>> this otherwise ISO will develop its own Thierry would have a better >>>>> idea. Let me him in this loop. >>>>> >>>>> Note that the request of the development of a solution for direct >>>>> communication between ITS stations has a long history and as you may >>>>> know because of this request the mnpp protocol >>>>> (https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00) was developed >>>>> as a result of FP7 EU project, Geonet (design and development of >>>>> Geoneworking over IPv6). At that time, there was no place to make it >>>>> as RFC at the IETF due to not matured ITS activities at the IETF. >>>>> >>>>> Cheers. >>>>> >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> >>>>>>> Sri >>>>>>> >>>>>>> >>>>>>> From: Jong-Hyouk Lee >>>>>> >>>>>>> > Date: >>>>>>> Monday, April 18, 2016 at 8:22 AM To: Sri Gundavelli >>>>>>> >>>>>>> >>>>>>> > Cc: Alexandre Petrescu >>>>>>> >>>>>>> >>>>>>> >, "its@ietf.org >>>>>>> >>>>>>> " >>>>>> >>>>>>> > Subject: Re: [its] >>>>>>> charter ITS - proposed work items >>>>>>> >>>>>>> Hi Sri, >>>>>>> >>>>>>> Just one comment regarding IP prefix exchanges. Plz see inline. >>>>>>> -- Jong-Hyouk Lee, living somewhere between /dev/null and >>>>>>> /dev/random Protocol Engineering Lab., Sangmyung University >>>>>>> >>>>>>> #email: jonghyouk@gmail.com >>>>>>> >>>>>>> #webpage: >>>>>>> https://sites.google.com/site/hurryon >>>>>>> >>>>>>>> On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) >>>>>>>> >>>>>>>> > wrote: >>>>>>>> >>>>>>>> Alex Inline .. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> To: Alexandre Petrescu >>>>>>> >>>>>>>> > Cc: "its@ietf.org >>>>>>>> " >>>>>>> > Subject: Re: [its] >>>>>>>> charter ITS - proposed work items >>>>>>>> >>>>>>>> >>>>>>>> ITSers, We work on a more rigorous ITS charter text. Now we >>>>>>>> propose four work items: 1. "Problem statement for IP in V2V >>>>>>>> and V2I" including "IP addressing architecture for V2V and V2I" >>>>>>>> and including "Gap Analysis: IP protocols suited and gaps" and >>>>>>>> including "Use-cases for IP in V2V and V2I moving network to >>>>>>>> nearby moving or fixed network" [Sri] Agree. This is a good >>>>>>>> starting point. Use-Cases document is needed. On the Gap >>>>>>>> Analysis document, it should be stated as how the gaps are >>>>>>>> captured and in relation to what technology. Is it NEMO, MANET, >>>>>>>> some other protocols ? >>>>>>>> >>>>>>>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>>>>>>> context" [Sri] If my starting point is #1, not sure how to read >>>>>>>> this ? Prefix exchanges appears more like a solution. In MANET >>>>>>>> there is exchange of prefixes, in NEMO we dont inject those >>>>>>>> prefixes and so I do not know if this work item is valid at >>>>>>>> this time. >>>>>>> >>>>>>> You are right. That is a missing part. We need to have a solution >>>>>>> for "IP prefix exchanges in V2V and V2I The need of IP prefix >>>>>>> exchanges is clear and well presented in PS documents for IP in >>>>>>> V2V and V2I. Then, there are 2 documents already existing as >>>>>>> below: >>>>>>> >>>>>>> 1. >>>>>>> https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 >>>>>>> >>>>>>> >>>> 2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 >>>>>>> >>>>>>> The above 2 documents are the early effort to establish IP >>>>>>> direction communications between vehicles and also between a >>>>>>> vehicle and a road side unit. >>>>>>> >>>>>>> I officially request that we should have a solution for IP >>>>>>> prefix exchanges as a work item. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Cheers! >>>>>>>> >>>>>>>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo >>>>>>>> document[*], including connectivity in fast and asymmetric >>>>>>>> conditions, coverage area vs speed diagrams, below-IP >>>>>>>> congestion management. >>>>>>>> >>>>>>>> 4. "List of papers and _products_ using IP in V2V and V2I" >>>>>>>> [Sri] Not clear what the deliverable is. >>>>>>>> >>>>>>>> What do you think? Please respond by next Monday, April 18th. >>>>>>>> >>>>>>>> _______________________________________________ its mailing >>>>>>>> list its@ietf.org >>>>>>>> >>>>>>>> https://www.ietf.org/mailman/listinfo/its > From nobody Tue Apr 19 06:32:26 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E9A12EA1E for ; Tue, 19 Apr 2016 06:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgUD_gF-cnlK for ; Tue, 19 Apr 2016 06:32:23 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD38812ED35 for ; Tue, 19 Apr 2016 06:32:22 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id r187so1843338pfr.2 for ; Tue, 19 Apr 2016 06:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s1osjildFMz9gob9rfSbXIkGNGaztI3iOUMlpVbIJKs=; b=H5s6r1cZsKkeFwiXWDxy1Rhn1OGlqiQHkF4Jmm6uJN04kBlR0zrIhUHATtCKad+u5h UDk30+EnLJ1F2B1aF1d+NXtScgqcsRSOP7zDRVWNZr6vWQtxcePqmVicC8R/CLA9pRxf +bCkOawvTMpYcpFfXl9p5EuzTf0xAkeWEgD2+fL+c28aILGDtdBE41fPiBvECckDQfue 0Mo+TgG0TmgGJyqVt4x4tIkckU61+kemqqHhDiVuzINo5QsSMHZjx8KiP4OQDtnhf9a4 0PLo1mUGroAqczVRTcSdc4ChH4wJbeFKpPnYRFAIZXdMOHHpxGtw9zDIzZWxcwaESEam e9QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s1osjildFMz9gob9rfSbXIkGNGaztI3iOUMlpVbIJKs=; b=JQJdD2cOi/3/wbzJ+kOZ3a8SmjQU1cuRZmvCtlEL003kxcfg35ArgeTyisLcX9xEyV HKZd3iWhODZaCIU6fT3e21jZ7XsRhDutv8mL3namUgmmhsLewUfS8zTVrYQyp708KgEV nm9brVvCYIosF5Aiud5GXDeN4osNh8ZoMjQGIhIrK4u5WjcIe2WknpQlDKKkTLtqvbEK C6zusaiUXSRFC1LlrSwqmyjchD8fG6AgqArJuw9KWjg9vpfK+ZsMgC+WLvEp02QNozs5 R/rm2NP5Yb8sWA2YN/4DVCKp6JvDGh1AiQCBDIGAFGShgw4mdDKgu8ojLtKD+NoO6Von zZoA== X-Gm-Message-State: AOPr4FVAs69QTimwYqrbkuAOO9irPXdTXaeelhRBSfP7vvN66dVfmOrJz8CISTQ2NqGhOQ== X-Received: by 10.98.22.146 with SMTP id 140mr4046942pfw.116.1461072742303; Tue, 19 Apr 2016 06:32:22 -0700 (PDT) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id o16sm3634245pfi.5.2016.04.19.06.32.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Apr 2016 06:32:21 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=windows-1252 From: Jong-Hyouk Lee In-Reply-To: <5716308A.9030107@gmail.com> Date: Tue, 19 Apr 2016 22:32:16 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> <57161C0F.7000908@gmail.com> <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> <57162615.7030409@gmail.com> <88F8BA46-40B6-49E6-B44A-8AE1F27C84BD@gmail.com> <5716308A.9030107@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Thierry Ernst , "its@ietf.org" , "Sri Gundavelli \(sgundave\)" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 13:32:25 -0000 Plz see inline, Alex. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 19, 2016, at 10:20 PM, Alexandre Petrescu = wrote: >=20 > Jong-Hyouk, >=20 > Le 19/04/2016 14:46, Jong-Hyouk Lee a =E9crit : >> Plz see inline. >> -- >> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >> Protocol Engineering Lab., Sangmyung University >>=20 >> #email: jonghyouk@gmail.com >> #webpage: https://sites.google.com/site/hurryon >>=20 >>> On Apr 19, 2016, at 9:35 PM, Alexandre Petrescu >>> > >>> wrote: >>>=20 >>>=20 >>>=20 >>> Le 19/04/2016 14:16, Jong-Hyouk Lee a =E9crit : >>>>=20 >>>> -- >>>> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >>>> Protocol Engineering Lab., Sangmyung University >>>>=20 >>>> #email: jonghyouk@gmail.com >>>> #webpage: https://sites.google.com/site/hurryon >>>>=20 >>>>> On Apr 19, 2016, at 8:52 PM, Alexandre Petrescu >>>>> > >>>>> wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Le 19/04/2016 00:51, Jong-Hyouk Lee a =E9crit : >>>>>> Alex, -- Jong-Hyouk Lee, living somewhere between /dev/null and >>>>>> /dev/random Protocol Engineering Lab., Sangmyung University >>>>>>=20 >>>>>> #email: jonghyouk@gmail.com >>>>>> #webpage: >>>>>> https://sites.google.com/site/hurryon >>>>>>=20 >>>>>>> On Apr 19, 2016, at 2:12 AM, Alexandre Petrescu >>>>>>> >>>>>> > wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Le 18/04/2016 17:56, Sri Gundavelli (sgundave) a =E9crit : >>>>>>>> Hi Jong-Hyouk, >>>>>>>>=20 >>>>>>>>> I officially request that we should have a solution for IP >>>>>>>>> prefix >>>>>>>> exchanges as a work item. >>>>>>>>=20 >>>>>>>> This is one specific approach. The description for the work = item >>>>>>>> can be bit more generic. >>>>>>>=20 >>>>>>> Thanks, but I would need a title for it. >>>>>>>=20 >>>>>>> How about: >>>>>>>=20 >>>>>>> "Solution for 1-hop IP V2V"? >>>>>>>=20 >>>>>>> "Solution to establish a 1-hop IP path between nearby moving >>>>>>> networks or between nearby moving networks and an immediate = fixed >>>>>>> network" >>>>>>>=20 >>>>>>> "Solution for Moving/Fixed Network Discovery and 1-hop Path >>>>>>> Establishment"? >>>>>>>=20 >>>>>>> "Solution for end-to-end path establishment in a star topology = with >>>>>>> 1-hop fragile core and n-hop stable edges=94? >>>>>>=20 >>>>>> We may refer the ISO/TC204 liaison link: >>>>>> https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf >>>>>>=20 >>>>>> As presented at the slide #13 above: ISO/TC204 calls "Direct >>>>>> communication between ITS stations=94 >>>>>=20 >>>>> What is an "ITS Station"? Can't we use "Mobile Router" instead? >>>>=20 >>>> Alex, come on! How don=92t you know the term used in ISO/TC204. ;) >>>=20 >>> I know. But at IETF we use the term "Mobile Router" extensively. >>>=20 >>> I guess we need a Terminology section which says: >>> ITS Station =3D=3D Mobile Router =3D=3D modem(s) >>=20 >> Hmmmmm=85I agree we need the terminology section in one document (I = do not >> know which one would be good for the terminology section). >=20 > This is the current list. Maybe in 1. >=20 > 1. "Problem statement for IP in V2V and V2I" > including "IP addressing architecture for V2V and V2I" > and including "Gap Analysis: IP protocols suited and gaps" > and including "Use-cases for IP in V2V and V2I moving network > To nearby moving or fixed network" > 2. "Threat Analysis for IP prefix exchanges in V2V and V2I > Context" > 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document, > including connectivity in fast and asymmetric conditions, > coverage area vs speed diagrams, below-IP congestion > management. > 4. "List of papers and _products_ using IP in V2V and V2I" > 5. "Solution for direct communication between Mobile Routers=94 Noted. And, if needed, when I write the gap analysis part, I will provide the = terminology section that lists up the terminologies being used at = ETSI/ISO with corresponding terminologies being used at the IETF.=20 >=20 >> Anyway, what >> you said is wrong. >>=20 >> There are 4 types of cooperative ITS stations: Personal ITS station >> (e.g., smartphone), Vehicle ITS station, Roadside ITS station, and >> Central ITS station. Then, for example, at a vehicle ITS station, a >> vehicle ITS station gateway, ITS station host, and ITS station router >> may exist. >=20 > ITS station gateway - does not sound correct order of words(?) That=92s been written at ISO documents. ;) >=20 > What's the difference between ITS station router and ITS station = gateway? The ITS station router is the router used to connect to outside (e.g., = to other vehicles=92s ITS station router, or to the Internet via the = roadside ITS station). In other words, the ITS station router is the = mobile router (with the NEMO concept). The ITS station gateway is the = gateway connecting to ECUs on a propriety in-vehicle network (e.g., = CAN). As I mentioned, on the ITS station internal network, the three = entities (i.e., ITS station router, ITS station gateway, and ITS station = host) are connected. Cheers. >=20 >> Those are connected each other on the ITS station internal >> network. The vehicle ITS station gateway is connected to ECUs on >> propriety in-vehicle network. The ITS station router is the one used = to >> connect to other side (e.g., Roadside ITS station or Internet). So, = the >> mobile router we are calling here at the IETF is the ITS station = router >> at the ISO/TC 204 standardisations. >=20 > Makes sense. >=20 > Alex >=20 >>=20 >> Cheers. >>=20 >>>=20 >>> because some car manufacturers use the term "modem" extensively even >>> today. >>>=20 >>> Alex >>>=20 >>>>=20 >>>>>=20 >>>>> Alex >>>>>=20 >>>>>> Its need has been well presented and as expressed at the slides, >>>>>> ISO/TC204 says=85"Generically applicable IETF standard is sought = on >>>>>> this otherwise ISO will develop its own=94 Thierry would have a = better >>>>>> idea. Let me him in this loop. >>>>>>=20 >>>>>> Note that the request of the development of a solution for direct >>>>>> communication between ITS stations has a long history and as you = may >>>>>> know because of this request the mnpp protocol >>>>>> (https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00) was = developed >>>>>> as a result of FP7 EU project, Geonet (design and development of >>>>>> Geoneworking over IPv6). At that time, there was no place to make = it >>>>>> as RFC at the IETF due to not matured ITS activities at the IETF. >>>>>>=20 >>>>>> Cheers. >>>>>>=20 >>>>>>>=20 >>>>>>> Alex >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Sri >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> From: Jong-Hyouk Lee >>>>>>> >>>>>>>> > = Date: >>>>>>>> Monday, April 18, 2016 at 8:22 AM To: Sri Gundavelli >>>>>>>> >>>>>>>> >>>>>>>> > Cc: Alexandre Petrescu >>>>>>>> >>>>>>>> >>>>>>>> >, "its@ietf.org >>>>>>>> >>>>>>>> " >>>>>>> >>>>>>>> > Subject: Re: [its] >>>>>>>> charter ITS - proposed work items >>>>>>>>=20 >>>>>>>> Hi Sri, >>>>>>>>=20 >>>>>>>> Just one comment regarding IP prefix exchanges. Plz see inline. >>>>>>>> -- Jong-Hyouk Lee, living somewhere between /dev/null and >>>>>>>> /dev/random Protocol Engineering Lab., Sangmyung University >>>>>>>>=20 >>>>>>>> #email: jonghyouk@gmail.com >>>>>>>> >>>>>>>> #webpage: >>>>>>>> https://sites.google.com/site/hurryon >>>>>>>>=20 >>>>>>>>> On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) >>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>> Alex =96 Inline .. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> To: Alexandre Petrescu >>>>>>>> >>>>>>>>> > Cc: "its@ietf.org >>>>>>>>> " >>>>>>>> > Subject: Re: = [its] >>>>>>>>> charter ITS - proposed work items >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ITSers, We work on a more rigorous ITS charter text. Now we >>>>>>>>> propose four work items: 1. "Problem statement for IP in V2V >>>>>>>>> and V2I" including "IP addressing architecture for V2V and = V2I" >>>>>>>>> and including "Gap Analysis: IP protocols suited and gaps" and >>>>>>>>> including "Use-cases for IP in V2V and V2I moving network to >>>>>>>>> nearby moving or fixed network" [Sri] Agree. This is a good >>>>>>>>> starting point. Use-Cases document is needed. On the Gap >>>>>>>>> Analysis document, it should be stated as how the gaps are >>>>>>>>> captured and in relation to what technology. Is it NEMO, = MANET, >>>>>>>>> some other protocols ? >>>>>>>>>=20 >>>>>>>>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>>>>>>>> context" [Sri] If my starting point is #1, not sure how to = read >>>>>>>>> this ? Prefix exchanges appears more like a solution. In MANET >>>>>>>>> there is exchange of prefixes, in NEMO we don=92t inject those >>>>>>>>> prefixes and so I do not know if this work item is valid at >>>>>>>>> this time. >>>>>>>>=20 >>>>>>>> You are right. That is a missing part. We need to have a = solution >>>>>>>> for "IP prefix exchanges in V2V and V2I=94 The need of IP = prefix >>>>>>>> exchanges is clear and well presented in PS documents for IP in >>>>>>>> V2V and V2I. Then, there are 2 documents already existing as >>>>>>>> below: >>>>>>>>=20 >>>>>>>> 1. >>>>>>>> = https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 >>>>>>>>=20 >>>>>>>>=20 >>>>> 2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 >>>>>>>>=20 >>>>>>>> The above 2 documents are the early effort to establish IP >>>>>>>> direction communications between vehicles and also between a >>>>>>>> vehicle and a road side unit. >>>>>>>>=20 >>>>>>>> I officially request that we should have a solution for IP >>>>>>>> prefix exchanges as a work item. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Cheers! >>>>>>>>>=20 >>>>>>>>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo >>>>>>>>> document[*], including connectivity in fast and asymmetric >>>>>>>>> conditions, coverage area vs speed diagrams, below-IP >>>>>>>>> congestion management. >>>>>>>>>=20 >>>>>>>>> 4. "List of papers and _products_ using IP in V2V and V2I" >>>>>>>>> [Sri] Not clear what the deliverable is. >>>>>>>>>=20 >>>>>>>>> What do you think? Please respond by next Monday, April 18th. >>>>>>>>>=20 >>>>>>>>> _______________________________________________ its mailing >>>>>>>>> list its@ietf.org >>>>>>>>> >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>=20 From nobody Tue Apr 19 07:32:12 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE95412E7A1 for ; Tue, 19 Apr 2016 07:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6mxfcYLapzQ for ; Tue, 19 Apr 2016 07:32:07 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA94712E779 for ; Tue, 19 Apr 2016 07:32:06 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id n3so33155868wmn.0 for ; Tue, 19 Apr 2016 07:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kEO2ncKi08XiWPea5qTVurnw1SAeSA3UDXyUIV9XiW4=; b=eZ3DDhpIf7765An3mvFp81HLZA+Ee2pmxZOd/GFwsLzH7PGaRUxSad8GTwnuz+KiQA sJSYmFRXiH2sKOmRVJS6ILDqg9HF+R7MrUJmTP+uQ/ZWphfvCpURzL8BY5v51oN8lEdt XMjaVTrFJT50XxH+6gXsE187pTCoJYKSqCd7rGZTTj7bhcLmxyMZoJx2eSkqNdla2UIh rnBi86/cok6Dxx58miqDBIEAVx0bXajbMONx0W6qEZJ907RaEbNiCytwU9KXyybxINwA JRWvkDFKGu+OGdgJsHKW7a02nhkjbrsJDZ7kykAumbuxo+JIwXg7aIa7Al5mymm9ISA+ RF1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kEO2ncKi08XiWPea5qTVurnw1SAeSA3UDXyUIV9XiW4=; b=X6ofUirKcRGHZGIX1G7xcJtzGExuNpe7GBBKgqsktWZLhCsldCd9houKWqmy2eFw0p QSgleK4RMNpXYBxCqPFPHgajPB1S3lqgLYWcR609VJ7cHrv6nlOAatrgSByN9GQL3OAA GeD3SgA2ObHhyRGPh4Hw9cuzxT6WMVI2bZH6+/a+xn5/59lkfBCFY2w23J62MwPfQFnP qXpYayPOZEkSj0mwYJj/yXhzPbbmkMt5zlt/cCn/5bjYIISj8tQcrZ3vHD5F3BaVudTB sYgPUUMVIbuL3Mz+pVPJXlcYpq2dk2K8tlUCEX+3nrsf0l39a8cAGuBMvi3HkqXvC46r Ktjw== X-Gm-Message-State: AOPr4FVM09FjMHVx2/VcZP1pE70cVxJ/bukvJihZlkuB14QFAMTEeVD1Ia3dAuWjrHbuyhbbDAGypOHhMDO/tw== MIME-Version: 1.0 X-Received: by 10.194.163.229 with SMTP id yl5mr514709wjb.6.1461076325307; Tue, 19 Apr 2016 07:32:05 -0700 (PDT) Received: by 10.28.224.137 with HTTP; Tue, 19 Apr 2016 07:32:04 -0700 (PDT) In-Reply-To: References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> <57161C0F.7000908@gmail.com> <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> <57162615.7030409@gmail.com> <88F8BA46-40B6-49E6-B44A-8AE1F27C84BD@gmail.com> <5716308A.9030107@gmail.com> Date: Tue, 19 Apr 2016 15:32:04 +0100 Message-ID: From: Nabil Benamar To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJpIChFVVJFQ09NKQ==?= Content-Type: multipart/related; boundary=089e01176d1b5c40d70530d75745 Archived-At: Cc: Alexandre Petrescu , "its@ietf.org" , =?UTF-8?Q?Sandra_C=C3=A9spedes?= Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 14:32:11 -0000 --089e01176d1b5c40d70530d75745 Content-Type: multipart/alternative; boundary=089e01176d1b5c40d10530d75744 --089e01176d1b5c40d10530d75744 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Jerome, Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Tue, Apr 19, 2016 at 8:26 AM, J=C3=A9r=C3=B4me H=C3=A4rri (EURECOM) < jerome.haerri@eurecom.fr> wrote: > Dear Nabil, Dear All, > > > > I am one of the supporters of having IoT in the charter, and I disagree > with your statement on IoT. > > > > There are plenty of interpretation of what IoT is or is not...the same > stands for vehicular communications... > =E2=80=8BI do not think so! All the IoT definitions mention things or objec= ts and in the majority of cases these things will be energy constrained , which is not the case of vehicular networks. As far as I know, the MAC layer for vehicular networks have been standardized by IEEE (among others), which is IEEE802.11p (doesn't exist anymore !). Is this the case for IoT ? > > > IoT will be transiting via vehicular communication - we have a testbed, > where IoT traffic from embedded sensors (CAN or non-CAN) are sent to an I= oT > server on Internet via ITS-G5/DSRC communication. IoT here is the > architecture (oneM2M) that is above a specific technology, not a technolo= gy > itself (you are maybe referring to SigFox or LTE-sensors I guess).. > =E2=80=8BI can agree in this case! =E2=80=8B so, our system works if we use another technology and would even need to work if we have multiple technologies on the path between the sensors and the =E2=80=98cloud=E2=80=99=E2=80=A6here, IPv6 take all of its sense. =E2=80=8Bmakes sens! =E2=80=8B The IoT differences in =E2=80=98routing, energy consumption, mac layer=E2= =80=99 as you said are actually either fully relevant to the charter, as referring to IPv6-over-foo or fully irrelevant to IPv6 (as based on IoT application-level traffic). Instead of debating whether we should add IoT or keep vehicular communication, we should debate of what kind of traffic (M2M-like, stream?, unicast/multicast etc..) will be transiting through IPv6 communication from a =E2=80=98vehicle=E2=80=99 to either Internet or another =E2=80=98vehicle= =E2=80=99. =E2=80=8BThis is another debate indeed.=E2=80=8B And I would like to mention that my suggestion is not to reduce the focus, but actually to focus on an aspect, where IPv6 does not have a competitor and can really make a difference. Said simple: if the charter addresses primarily IPv6 for critical safety communications, this will be difficult to sell, as other simpler solutions already work without IPv6. I would therefore support and even propose to have a draft formulating the problem related to =E2=80=9CIoT-over-IPv6 on moving networks=E2=80=9D. =E2=80=8BIt's an interesting work but outside the current charter =E2=80=8B =E2=80=8B!=E2=80=8B Best Regards, J=C3=A9r=C3=B4me Envoy=C3=A9 de mon iPad *De:* its [mailto:its-bounces@ietf.org ] *En nombre de *Nabil Benamar *Enviado el:* lunes, 18 de abril de 2016 4:55 *Para:* Alexandre Petrescu *CC:* its@ietf.org *Asunto:* Re: [its] charter ITS - proposed work items Hi All, I agree on the current charter since these are the points discussed during the BoF! However there were some replies in this list mentioning to probably add IoT as an exemple of IP based communications. I think that we should keep the focus on vehicular communications/networks and do not diverge from this topic. IoT is fundamentally different from vehicular networks in many aspects such as routing, energy consumption, mac layer, etc... Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Thu, Apr 14, 2016 at 9:42 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: ITSers, We work on a more rigorous ITS charter text. Now we propose four work items: 1. "Problem statement for IP in V2V and V2I" including "IP addressing architecture for V2V and V2I" and including "Gap Analysis: IP protocols suited and gaps" and including "Use-cases for IP in V2V and V2I moving network to nearby moving or fixed network" 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context" 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], including connectivity in fast and asymmetric conditions, coverage area vs speed diagrams, below-IP congestion management. 4. "List of papers and _products_ using IP in V2V and V2I" What do you think? Please respond by next Monday, April 18th. Alex and Dapeng [*] a typical IP-over-foo document is, for example, RFC2464 "Transmission of IPv6 Packets over Ethernet Networks", where "foo" is instantiated as "Ethernet". Other IPv6-over-foo documents are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and more. Le 14/04/2016 09:42, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : Paul, Thanks. Btw, when I mentioned =E2=80=98people=E2=80=99 are aware of IP V2V = but not see the need (so far), I referred to the automotive SDOs (led by automotive industries)=E2=80=A6, although there are always =E2=80=98minority reports= =E2=80=99 J Cheers, J=C3=A9r=C3=B4me *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] *Sent:* Thursday 14 April 2016 09:36 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:* Alexandre Petrescu; its@ietf.org *Subject:* Re: [its] charter ITS J=C3=A9r=C3=B4me, I missed that you are also an academic person. I got it :-) I understand your points for industry activity related to vehicular networking. Your observation seems true. BTW, I will invite you to my team for the draft for a list of academic papers for V2V and V2I by a personal message. Thanks. Paul On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H=C3=A4rri > wrote: Hi Paul, Thanks for your feedback. Do not get me wrong, I am an academic and with my team, we also work on IP-based V2V and V2I, in particular related to mobility management with DMM, but also in the context of vehicular IoT. I just have the feeling that people are perfectly aware of the fact that IP _can_ be used for V2V and V2I, but does not =E2=80=98_need_=E2=80=99 to = be used as other solutions already perfectly fit their need. Listing papers will not change this awareness. So, as a complement to academic papers, it would help to be able to pin-point which industrial activities are using or are strongly planning (short term I mean) to use pure IPv6 system in vehicles. My feeling here is we have a different eco-system that the Automotive industry (and automotive industry-related SDO)..more likely the IoT industry=E2=80=A6and as such, we should not need to have the (direct) involvement of automotive industry in the Charter. If we can make this clear by an industry-based =E2=80=98survey=E2=80=99, that would help make t= he case for the WG. Btw, you can count on me your draft..we can add some IP-based V2V and V2I for mobility management and also IoT. Cheers, J=C3=A9r=C3=B4me *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com ] *Sent:* Thursday 14 April 2016 03:22 *To:* J=C3=A9r=C3=B4me H=C3=A4rri *Cc:* Alexandre Petrescu; its@ietf.org *Subject:* Re: [its] charter ITS Hi J=C3=A9r=C3=B4me, I have an opinion on your comment 5) below. I think that a list of high-quality papers about IP-based V2V and V2I can teach very useful lessons to software designers of IP in V2V and V2I in the industry. Multiple people are working for this IP-based V2V and V2I (including Sandra Cespedes and me) in academia and more people(including Nabil Benamar) are willing to work for this area. I think we need to utilize the list of such papers as the ground for our ITS group through a WI. Note that the draft of the list will include the summary of the main ideas of the papers. For the industry current activities for this area, I believe that you can share them as references through our ITS mailing list rather than through a WI. Could you join my team that are making efforts for a list of such papers? Thanks. Best Regards, Paul On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H=C3=A4rri > wrote: Dear ITSers, Dear Alex, Here are some comments on the updated charter: 1)Can we keep a reference to IEEE 802.11p, considering it does not exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of course. 2)Should we really keep C-ACC (or Platooning) in the charter explicitly as use case, considering it is a seriously controversial aspect with some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry mentions traffic efficiency/infotainment applications, such as in-signage applications... a.We might have to aim at less controversial use cases to attract automotive industries 3)One potential WI I could think of (rather a basic one): _definition of a vehicular wireless =E2=80=98link=E2=80=99 in an automotive context_ a.To me, this is a fundamental brick in the larger IETF WG ITS house.. 4)I would suggest to be more explicit in the foreseen challenges of this WG, instead of mentioning general use case (which end up be controversial) a.Example: maintaining IPv6 connectivity in fast and asymmetric wireless links; also under quickly changing topologies (actually suggested by Dick Roy on the chat room) b.Example: IPv6 addressing in link-local scope.. c.Example: guaranteeing privacy in IPv6 moving networks etc.. 5)Before listing academic papers referring to IPv6 in vehicles, I would suggest to first try to list commercial products/solutions that are in vehicles and are using IPv6, possibly suffering from a silo limitations (ex. restricted to a single technology, single use case=E2=80=A6) a.I think we need to get to products first, before academic visions My two cents.. Best Regards, J=C3=A9r=C3=B4me *From:*its [mailto:its-bounces@ietf.org ] *On Behalf Of *Alexandre Petrescu *Sent:* Wednesday 06 April 2016 23:45 *To:* its@ietf.org *Subject:* [its] charter ITS ITSers, Please see below the current charter. - the two Problem Statements drafts V2V and V2I joined, so there is less text in charter. - added an Item on "List of Research papers..." Erik: did I understand you correctly that there should be some item on discussing whether link-local addressing is sufficient, whether prefix exchange is necessary? Dino: should LISP be included in the gap analysis draft which includes C-ACC use-case? OR should we separate a dedicated I-D only with gap analysis including ND, MIP, AODVv2, LISP? Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle interface illustrated good enough by the words "moving network to nearby moving network communications"? Or is it better to say "the 1-IP-hop between nearby moving networks must be self-configured"? Nabil, Sandra: is it ok to have a working group item "List of Research Papers for IP in V2V and V2I communications"? Other comments? Alex ------------------------------------------------------------------ ITS (name to change) Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: WG forming Chairs: TBD Assigned Area Director: TBD Mailing list Address: its@ietf.org 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: Goal ---- The goal of this group is to standardize IP-based protocols for establishing direct and secure connectivity between moving networks, some of which could be fixed permanently or temporarily. Moving Network to Nearby Moving Network Communications ------------------------------------------------------ The group is concerned with all situations involving moving network to nearby moving network communications. For example: vehicle-to-vehicle communications, nomadic user wearing a PAN and communicating to a homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a train, or train-to-intersection signalling. Example from the automobile communications space ------------------------------------------------ Automobiles and vehicles of all types are increasingly connected to the Internet, either as vehicle-to-vehicle, vehicle-to-infra or vehicle-to-Internet. Entertainment apps enhancing comfort, reliable data exchanges for road safety, and automated driving are features coming in automobiles to hit the roads from now to year 2020. Highlighting increased safety as an immediate result of hyper-connectivity applied to vehicles, public authorities worldwide are increasingly mandating secure communication technology requirements in vehicles. Emergency apps for new instrumented ambulances carry many benefits both to the users and to society in general. Why IP? ------- Today, there are several deployed Vehicle-to-Internet technologies, including car tethering through driver's cellular smartphone. However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are still being developed. To improve on a situation of link-specific data exchanges, and enable independent application sets to share the same links, IP data exchanges are needed. Enabling IP communication between vehicles (V2V), and between vehicles and the immediate infrastructure (V2I), will provide (0) ability to reach the rest of the world on the Internet (1) short and deterministic delays, (2) fast forwarding through scalable paths of routers, (3) ease of reuse of existing Internet applications in a vehicular environment. Moving network to nearby moving network communications involve link layers such as: 802.11p OCB (Outside the Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light Communications), IrDA, LTE-D. Only the IP protocols are capable of running on each of these links and establish IP paths across them in an interoperable manner. Scenarios? ---------- There are a few scenarios exhibiting the need to communicate from one moving network to another nearby moving network. In the automobile space, the Cooperative Adaptive Cruise Control and Platooning features consider that vehicles close to each other exchange data describing their kinematic status. At the cross-roads, the moving network inside a vehicle exchanges data with the moving network in the red-light pole. Several public safety scenarios involve moving networks. Distinct organizations deploy different moving networks (in-vehicle, on-person) at an incident scene. These networks need to interoperate in order to more effectively understand and deal with the incident scene. In connected rail scenarios the moving network deployed in trains communicate with other moving networks at the cross-points. What kind of solutions? ----------------------- The current technical solutions considered to achieve moving network to nearby moving network communications are of two kinds: IP routing protocols for n-hop path management and 1-hop link-scoped IP protocol enhancements. The 1-hop link-scoped protocols include the protocols for route establishment involving ICMP Router Advertisements. The n-hop path management protocols include n-hop path establishment protocols (e.g. Babel, OSPF) and n-hop path search protocols (most notably AODV and derivates). In this proposed Working Group the focus is on 1-hop protocols, and leverage from other Working Groups for the n-hop situations. In some of the moving network applications the window of opportunity for exchanging data with the immediate infrastructure may be very short. For example, a car driving near a road-side unit may have only 5s to exchange with that RSU (depending on speed, RSU range and number). (ephemeral connections). What kind of requirements? -------------------------- The requirements for mechanisms for moving network to nearby moving network communications are focusing on low delays of the data paths, reduced number of messages for path establishment, application friendly, resilience to attacks, compatibility with DHCP and Mobile IP. In addition, some moving network to nearby moving network applications involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the 1-hop IP moving network to nearby moving netowrk mechanisms will need to gracefully support IP multicast. Due to the inherent characteristics of safety-related communications, all new moving network to nearby moving network mechanisms must afford authenticity and confidentiality where necessary. Dynamically establishing ephemeral communication paths between automobiles in public areas must offer privacy safeguards for the end users (passengers). Establishing 1-hop IP V2V paths must not break the existing on-board protocols and applications which communicate with the Internet, possibly via multiple radios. In a moving network deployed in an automobile, typically one exit point connects the moving network to other moving networks. However, in a more general manner (and to support reliability) any new mechanism of moving network to nearby moving network communications should support multi-homing: one router to use multiple interfaces towards outside the moving network, or multiple routers. Current version of Internet protocols ------------------------------------- The group will only work on IPv6 solutions. What SDOs may need this work? ----------------------------- The requirements and standards for moving network to nearby moving network communications, often involving IPv6, and novel V2V and V2Infra concepts, are developed mainly at ISO TC204 "Intelligent Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For Vehicle-to-Internet communications, 3GPP LTE and other cellular technologies represent the long-range connectivity method; for Vehicle-to-Vehicle communications, LTE Direct is currently specified, as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning. The IEEE developed a popular link for short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V communications. Work Items ---------- - use-cases for moving network to nearby moving network communications - Problem Statement for moving network to nearby moving network communications including V2V, V2I and DNS. - Security and Privacy Requirements for moving network to nearby moving network communications - Solutions, which might include new protocols or extensions to existing protocols. With MIB. - IPv6-over foo, where foo is pertinent for moving network to nearby moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in the V2V domain, identifying which uses IP. Timeline -------- - _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com , pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com , pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its ------------------------------ [image: Avast logo] El software de antivirus Avast ha analizado este correo electr=C3=B3nico en busca de virus. www.avast.com _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its --089e01176d1b5c40d10530d75744 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Jerome,

Best regards
Na= bil Benamar
---------------= ----
=D9= =86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88
=

On Tue, Apr 19, 2016 at 8:26 AM, J=C3=A9r=C3= =B4me H=C3=A4rri (EURECOM) <jerome.haerri@eurecom.fr>= wrote:

Dear Nabil, Dear All,

=C2=A0

I am one o= f the supporters of having IoT in the charter, and I disagree with your sta= tement on IoT.

=C2=A0

There are plenty of interpretation of what IoT = is or is not...the same stands for vehicular communications...


=E2=80=8BI do not think so! All the IoT definitions mention t= hings or objects and in the majority of cases these things will be energy c= onstrained , which is not the case of vehicular networks. As far as I know,= the MAC layer for vehicular networks have been standardized by IEEE (among= others), which is IEEE802.11p (doesn't exist anymore !). Is this the c= ase for IoT ?
<= div>

=C2=A0

IoT will be transiting via veh= icular communication - we have a testbed, where IoT traffic from embedded s= ensors (CAN or non-CAN) are sent to an IoT server on Internet via ITS-G5/DS= RC communication. IoT here is the architecture (oneM2M) that is above a spe= cific technology, not a technology itself (you are maybe referring to SigFo= x or LTE-sensors I guess)..


=E2=80=8BI can agree = in this case!

= so, our system works if we use another technology and would even need to wo= rk if we have multiple technologies on the path between the sensors and the= =C2=A0 =E2=80=98cloud=E2=80=99=E2=80=A6here, IPv6 take all of its sense.=

=C2=A0

=E2=80=8Bmakes sens!

=C2=A0

=E2=80=8B
=

The IoT differences in =E2=80=98routing, = energy consumption, mac layer=E2=80=99 as you said are actually either full= y relevant to the charter, as referring to IPv6-over-foo or fully irrelevan= t to IPv6 (as based on IoT application-level traffic).

=C2=A0

Instead= of debating whether we should add IoT or keep vehicular communication, we = should debate of what kind of traffic (M2M-like, stream?, unicast/multicast= etc..) will be transiting through IPv6 communication from a =E2=80=98vehic= le=E2=80=99 to either Internet or another =E2=80=98vehicle=E2=80=99.


=E2=80=8BThis is another debate indeed.=E2=80=8B
= =C2=A0

=

=C2=A0

And I would like to mention that my suggestion is not to reduce t= he focus, but actually to focus on an aspect, where IPv6 does not have a co= mpetitor and can really make a difference.

Said simple: i= f the charter addresses primarily IPv6 for critical safety communications, = this will be difficult to sell, as other simpler solutions already work wit= hout IPv6.

=C2=A0

I would therefore support and even propose to have = a draft=C2=A0 formulating the problem related to =E2=80=9CIoT-over-IPv6 on = moving networks=E2=80=9D.

= =C2=A0


=E2=80=8BIt's an interesting work but = outside the current charter =E2=80=8B
=C2=A0
=E2=80=8B!=E2=80=8B

=

Best Regards,

=C2=A0

J=C3=A9r=C3=B4me=

=C2=A0

Envoy=C3=A9 de mon = iPad

=C2=A0

<= p class=3D"MsoNormal">=C2=A0

De: its= [mailto:its-bounces@ietf.org] En nombre de Nabil Benamar
Enviado el:<= /b> lunes, 18 de abril de 2016 4:55
Para: Alexandre Petrescu <= alexandre.petrescu@gmail.com>
CC: = its@ietf.org
Asunto: Re: [its] cha= rter ITS - proposed work items

=C2=A0

Hi Al= l,

=C2= =A0

I= agree on the current charter since these are the points discussed during t= he BoF! However there were some replies in this list mentioning to probably= add IoT as an exemple of IP based communications.=C2=A0 I think that we sh= ould keep the focus on vehicular communications/networks and do not diverge= from this topic. IoT is fundamentally different from vehicular networks in= many aspects such as routing, energy consumption, mac layer, etc...=


Best regards

Nabil Ben= amar

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

=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88

= =C2=A0

=C2=A0

On Thu, Apr 14, 2016 at 9:42 AM, Alexandre Petrescu <alexandre.petrescu@gm= ail.com> wrote:

ITSers,

We work on a more rigorous ITS charter text.

Now we= propose four work items:

1. "Problem statement for IP in V2V a= nd V2I"
=C2=A0 =C2=A0including "IP addressing architecture for= V2V and V2I"
=C2=A0 =C2=A0and including "Gap Analysis: IP pro= tocols suited and gaps"
=C2=A0 =C2=A0and including "Use-cases = for IP in V2V and V2I moving network to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nearby moving or fixed network"
2. "Threat Analysis for IP prefix exchanges in V2V and V2I context&qu= ot;

3. "IP over DSRC (802.11-OCB)" typical IP-over-foo doc= ument[*],
=C2=A0 =C2=A0including connectivity in fast and asymmetric con= ditions, coverage
=C2=A0 =C2=A0area vs speed diagrams, below-IP congesti= on management.

4. "List of papers and _products_ using IP in V2= V and V2I"

What do you think?

Please respond by next Mon= day, April 18th.

Alex and Dapeng
[*] a typical IP-over-foo docume= nt is, for example, RFC2464
=C2=A0 =C2=A0 "Transmission of IPv6 Pac= kets over Ethernet Networks", where
=C2=A0 =C2=A0 "foo" i= s instantiated as "Ethernet".=C2=A0 Other IPv6-over-foo documents=
=C2=A0 =C2=A0 are RFC4944 "IPv6 over 802.15.4" RFC5072 "= IPv6 over PPP" and more.

Le 14/04/2016 09:42, J=C3=A9r=C3=B4me = H=C3=A4rri a =C3=A9crit :

Paul,

Thanks. Btw, when I mentio= ned =E2=80=98people=E2=80=99 are aware of IP V2V but not see
the need (s= o far), I referred to the automotive SDOs (led by automotive
industries)= =E2=80=A6, although there are always =E2=80=98minority reports=E2=80=99 J
Cheers,

J=C3=A9r=C3=B4me

*From:*Mr. Jaehoon Paul Jeong = [mailto:jaehoon= .paul@gmail.com]
*Sent:* Thursday 14 April 2016 09:36
*To:* J=C3= =A9r=C3=B4me H=C3=A4rri
*Cc:* Alexandre Petrescu; its@ietf.org
*Subject:* Re: [its] charte= r ITS

J=C3=A9r=C3=B4me,

I missed that you are also an academi= c person.

I got it :-)

I understand your points for industry = activity related to vehicular
networking.

Your observation seems = true.

BTW, I will invite you to my team for the draft for a list of = academic
papers for V2V and V2I

by a personal message.

Tha= nks.

Paul

On Thu, Apr 14, 2016 at 4:09 PM, J=C3=A9r=C3=B4me H= =C3=A4rri <jerome.haerri@eurecom.fr
<mailto:jerome.haerri@eurecom.fr>> wrote:<= br>
Hi Paul,

Thanks for your feedback. Do not get me wrong, I am = an academic and with
my team, we also work on IP-based V2V and V2I, in p= articular related to
mobility management with DMM, but also in the conte= xt of vehicular IoT.

I just have the feeling that people are perfect= ly aware of the fact that
IP _can_ be used for V2V and V2I, but does not= =E2=80=98_need_=E2=80=99 to be used as
other solutions already perfectl= y fit their need. Listing papers will
not change this awareness.

= So, as a complement to academic papers, it would help to be able to
pin-= point which industrial activities are using or are strongly planning
(sh= ort term I mean) to use pure IPv6 system in vehicles.

My feeling her= e is we have a different eco-system that the Automotive
industry (and au= tomotive industry-related SDO)..more likely the IoT
industry=E2=80=A6and= as such, we should not need to have the (direct)
involvement of automot= ive industry in the Charter. If we can make this
clear by an industry-ba= sed =E2=80=98survey=E2=80=99, that would help make the case for
the WG.<= br>
Btw, you can count on me your draft..we can add some IP-based V2V an= d
V2I for mobility management and also IoT.

Cheers,

J=C3= =A9r=C3=B4me

*From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com
&l= t;mailto:jaehoo= n.paul@gmail.com>]
*Sent:* Thursday 14 April 2016 03:22
*To:* = J=C3=A9r=C3=B4me H=C3=A4rri
*Cc:* Alexandre Petrescu; its@ietf.org <mailto:its@ietf.org>
*Subject:* Re: [= its] charter ITS

Hi J=C3=A9r=C3=B4me,

I have an opinion on yo= ur comment 5) below.

I think that a list of high-quality papers abou= t IP-based V2V and V2I

can teach very useful lessons to software des= igners of IP in V2V and V2I

in the industry.

Multiple people = are working for this IP-based V2V and V2I

(including Sandra Cespedes= and me) in academia and

more people(including Nabil Benamar) are wi= lling to work for this area.

I think we need to utilize the list of = such papers as the ground for our
ITS group

through a WI. Note th= at the draft of the list will include the summary
of the main

ide= as of the papers.

For the industry current activities for this area,= I believe that you
can share them

as references through our ITS = mailing list rather than through a WI.

Could you join my team that a= re making efforts for a list of such papers?

Thanks.

Best Reg= ards,

Paul

On Thu, Apr 7, 2016 at 8:11 AM, J=C3=A9r=C3=B4me H= =C3=A4rri <jerome.haerri@eurecom.fr
<mailto:jerome.haerri@eurecom.fr>> wrote:<= br>
Dear ITSers,=C2=A0 Dear Alex,

Here are some comments on the u= pdated charter:

1)Can we keep a reference to IEEE 802.11p, consideri= ng it does not exist
anymore? It is now fully integrated into IEEE 802.1= 1-2012 as OCB mode
(and 10Mhz @5.9Ghz) of course.

2)Should we rea= lly keep C-ACC (or Platooning) in the charter explicitly
as use case, co= nsidering it is a seriously controversial aspect with
some SDOs (ex. In = Automotive SDOs)? In the ISO presentation, Thierry
mentions traffic effi= ciency/infotainment applications, such as
in-signage applications...
=
a.We might have to aim at less controversial use cases to attract
au= tomotive industries

3)One potential WI I could think of (rather a ba= sic one): _definition of
a vehicular wireless =E2=80=98link=E2=80=99 in = an automotive context_

a.To me, this is=C2=A0 a fundamental brick in= the larger IETF WG ITS house..

4)I would suggest to be more explici= t in the foreseen challenges of this
WG, instead of mentioning general u= se case (which end up be controversial)

a.Example: maintaining IPv6 = connectivity in fast and asymmetric wireless
links; also under quickly c= hanging topologies (actually suggested by
Dick Roy on the chat room)
=
b.Example: IPv6 addressing in link-local scope..

c.Example: guar= anteeing privacy in IPv6 moving networks etc..

5)Before listing acad= emic papers referring to IPv6 in vehicles, I would
suggest to first try = to list commercial products/solutions that are in
vehicles and are using= IPv6, possibly suffering from a silo limitations
(ex. restricted to a s= ingle technology, single use case=E2=80=A6)

a.I think we need to get= to products first, before academic visions

My two cents..

Be= st Regards,

J=C3=A9r=C3=B4me

*From:*its [mailto:its-bounces@ietf.org <m= ailto:its-bounces= @ietf.org>]
*On Behalf Of *Alexandre Petrescu
*Sent:* Wednesda= y 06 April 2016 23:45
*To:* its@ietf.org <mailto:its@ietf.org>
*Subject:* [its] charter ITS

ITSers= ,

Please see below the current charter.

- the two Problem Sta= tements drafts V2V and V2I joined, so there is less
text in charter.
= - added an Item on "List of Research papers..."

Erik: did = I understand you correctly that there should be some item on
discussing = whether link-local addressing is sufficient, whether prefix
exchange is = necessary?

Dino: should LISP be included in the gap analysis draft w= hich includes
C-ACC use-case?=C2=A0 OR should we separate a dedicated I-= D only with gap
analysis including ND, MIP, AODVv2, LISP?

Person = from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle
= interface illustrated good enough by the words "moving network to near= by
moving network communications"?=C2=A0 Or is it better to say &qu= ot;the 1-IP-hop
between nearby moving networks must be self-configured&q= uot;?

Nabil, Sandra: is it ok to have a working group item "Lis= t of Research
Papers for IP in V2V and V2I communications"?

= Other comments?

Alex

----------------------------------------= --------------------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 ITS (name to change)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Charter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 April 6th, 2016
http://ietf.org/mailman/listinfo/its

Intelligent Transportation Systems (its)
-----------------------------= -----------
Current Status: WG forming

Chairs:
=C2=A0 =C2=A0 T= BD

Assigned Area Director:
=C2=A0 =C2=A0 TBD

Mailing list<= br>=C2=A0 =C2=A0 Address: its@ietf.org <mailto:its@ietf.org>
=C2=A0 =C2=A0 To Subscribe: https://www.ietf.org/m= ailman/listinfo/its
=C2=A0 =C2=A0 Archive:
http= ://www.ietf.org/mail-archive/web/its/current/maillist.html

Addit= ional web page
=C2=A0 =C2=A0 TBD

Charter:

Goal
----
= The goal of this group is to standardize IP-based protocols for
establis= hing direct and secure connectivity between moving networks,
some of whi= ch could be fixed permanently or temporarily.

Moving Network to Near= by Moving Network Communications
---------------------------------------= ---------------
The group is concerned with all situations involving mov= ing network to
nearby moving network communications.=C2=A0 For example: = vehicle-to-vehicle
communications, nomadic user wearing a PAN and commun= icating to a
homenet, vehicle-to-infrastructure communications, wagon-to= -wagon in a
train, or train-to-intersection signalling.

Example f= rom the automobile communications space
--------------------------------= ----------------
Automobiles and vehicles of all types are increasingly = connected to
the Internet, either as vehicle-to-vehicle, vehicle-to-infr= a or
vehicle-to-Internet.=C2=A0 Entertainment apps enhancing comfort, re= liable
data exchanges for road safety, and automated driving are feature= s
coming in automobiles to hit the roads from now to year 2020.
Highl= ighting increased safety as an immediate result of
hyper-connectivity ap= plied to vehicles, public authorities worldwide
are increasingly mandati= ng secure communication technology
requirements in vehicles.

Emer= gency apps for new instrumented ambulances carry many benefits
both to t= he users and to society in general.

Why IP?
-------
Today, the= re are several deployed Vehicle-to-Internet technologies,
including car = tethering through driver's cellular smartphone.
However, Vehicle-to-= Vehicle and Vehicle-to-Infrastructure
communications are still being dev= eloped.=C2=A0 To improve on a situation
of link-specific data exchanges,= and enable independent application
sets to share the same links, IP dat= a exchanges are needed.=C2=A0 Enabling
IP communication between vehicles= (V2V), and between vehicles and the
immediate infrastructure (V2I), wil= l provide (0) ability to reach the
rest of the world on the Internet (1)= short and deterministic delays,
(2) fast forwarding through scalable pa= ths of routers, (3) ease of
reuse of existing Internet applications in a= vehicular environment.

Moving network to nearby moving network comm= unications involve link
layers such as: 802.11p OCB (Outside the Context= of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible = Light
Communications), IrDA, LTE-D.=C2=A0 Only the IP protocols are capa= ble of
running on each of these links and establish IP paths across them= in
an interoperable manner.

Scenarios?
----------
There ar= e a few scenarios exhibiting the need to communicate from one
moving net= work to another nearby moving network.

In the automobile space, the = Cooperative Adaptive Cruise Control and
Platooning features consider tha= t vehicles close to each other
exchange data describing their kinematic = status.=C2=A0 At the cross-roads,
the moving network inside a vehicle ex= changes data with the moving
network in the red-light pole.

Sever= al public safety scenarios involve moving networks.=C2=A0 Distinct
organ= izations deploy different moving networks (in-vehicle, on-person)
at an = incident scene.=C2=A0 These networks need to interoperate in order to
mo= re effectively understand and deal with the incident scene.

In conne= cted rail scenarios the moving network deployed in trains
communicate wi= th other moving networks at the cross-points.

What kind of solutions= ?
-----------------------
The current technical solutions considered = to achieve moving network
to nearby moving network communications are of= two kinds: IP routing
protocols for n-hop path management and 1-hop lin= k-scoped IP protocol
enhancements.=C2=A0 The 1-hop link-scoped protocols= include the protocols
for route establishment involving ICMP Router Adv= ertisements.=C2=A0 The
n-hop path management protocols include n-hop pat= h establishment
protocols (e.g. Babel, OSPF) and n-hop path search proto= cols (most
notably AODV and derivates).

In this proposed Working = Group the focus is on 1-hop protocols, and
leverage from other Working G= roups for the n-hop situations.

In some of the moving network applic= ations the window of opportunity
for exchanging data with the immediate = infrastructure may be very
short.=C2=A0 For example, a car driving near = a road-side unit may have only
5s to exchange with that RSU (depending o= n speed, RSU range and
number). (ephemeral connections).

What kin= d of requirements?
--------------------------
The requirements for me= chanisms for moving network to nearby moving
network communications are = focusing on low delays of the data paths,
reduced number of messages for= path establishment, application
friendly, resilience to attacks, compat= ibility with DHCP and Mobile
IP.

In addition, some moving network= to nearby moving network applications
involve IP multicast mechanisms (= e.g. virtual siren); thus C-ACC the
1-hop IP moving network to nearby mo= ving netowrk mechanisms will need
to gracefully support IP multicast.
Due to the inherent characteristics of safety-related communications,<= br>all new moving network to nearby moving network mechanisms must affordauthenticity and confidentiality where necessary.=C2=A0 Dynamically
es= tablishing ephemeral communication paths between automobiles in
public a= reas must offer privacy safeguards for the end users
(passengers).
Establishing 1-hop IP V2V paths must not break the existing on-board
p= rotocols and applications which communicate with the Internet,
possibly = via multiple radios.

In a moving network deployed in an automobile, = typically one exit
point connects the moving network to other moving net= works.=C2=A0 However,
in a more general manner (and to support reliabili= ty) any new
mechanism of moving network to nearby moving network communi= cations
should support multi-homing: one router to use multiple interfac= es
towards outside the moving network, or multiple routers.

Curre= nt version of Internet protocols
-------------------------------------The group will only work on IPv6 solutions.

What SDOs may need thi= s work?
-----------------------------
The requirements and standards = for moving network to nearby moving
network communications, often involv= ing IPv6, and novel V2V and
V2Infra concepts, are developed mainly at IS= O TC204 "Intelligent
Transport Systems", 3GPP, ETSI, NHTSA and= IEEE.=C2=A0 For
Vehicle-to-Internet communications, 3GPP LTE and other = cellular
technologies represent the long-range connectivity method; for<= br>Vehicle-to-Vehicle communications, LTE Direct is currently specified,as well as OCB mode of IEEE 802.11.=C2=A0 Several use-cases exhibit a need=
for IPv6 data exchanges between vehicles: ETSI's Cooperative Adapti= ve
Cruise Control and Platooning.=C2=A0 The IEEE developed a popular lin= k for
short-range communications - IEEE 802.11p "WAVE".=C2=A0 = The NHTSA wrote a
set of requirements for V2V communications.

Wor= k Items
----------
- use-cases for moving network to nearby moving ne= twork communications
- Problem Statement for moving network to nearby mo= ving network
communications
=C2=A0 =C2=A0including V2V, V2I and DNS.<= br>- Security and Privacy Requirements for moving network to
=C2=A0 =C2= =A0nearby moving network communications
- Solutions, which might include= new protocols or extensions to
=C2=A0 =C2=A0existing protocols.=C2=A0 W= ith MIB.
- IPv6-over foo, where foo is pertinent for moving network to n= earby
=C2=A0 =C2=A0moving network communications (e.g. 802.11 OCB, VLC, = LTE-D, 802.11ad)
- List of Research Papers in the V2V domain, identifyin= g which uses IP.

Timeline
--------
-


______________= _________________________________
its mailing list
its@ietf.org <mailto:its@ietf.org>
https://www.ietf.or= g/mailman/listinfo/its



--

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon= (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Su= ngkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>,
pauljeong= @skku.edu <mailto:pauljeong@skku.edu>
Personal Homepage: http://iotlab.skk= u.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-= jaehoon-jeong.php>



--

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (P= aul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungk= yunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>= ,
pauljeong@skku= .edu <mailto:pauljeong@skku.edu>
Personal Homepage: http://iotlab.skku.edu= /people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaeho= on-jeong.php>

<= br>_______________________________________________
its mailing list
<= a href=3D"mailto:its@ietf.org" target=3D"_blank">its@ietf.org
https://w= ww.ietf.org/mailman/listinfo/its

=C2=A0

=C2=A0

<= /tbody>

=3D"Avast

El software de antivirus Avas= t ha analizado este correo electr=C3=B3nico en busca de virus.
<= span style=3D"font-family:"Calibri","sans-serif";color:= #3d4d5a">www.avast.com

=C2=A0

=

_______________________________________________
its mailing = list
its@ietf.org<= br>= https://www.ietf.org/mailman/listinfo/its


--089e01176d1b5c40d10530d75744-- --089e01176d1b5c40d70530d75745 Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: aadfb5afa3a1eccc_0.1 iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAfmSURBVFhH tVdrbBTXFT73zp31jN8PDKYGEoyLDTghkWMjFwwiGKM+eKgSSRtQ2v5qIyohJSlRpcSbdaOqihQp VUpUEHGUVDSIqqWlKE0dNwkxkVtv7FiVCesEObSEd8wa1usd79y5t9+M1w9o41qNe631zsy9e893 vvOdc8+ISCRCM42WsvCDxOkAZdH61k8if59x8f8wKWY0viLM6Tr9gIoon+L0CNb6nzkdkwDgaS52 rmq9HOmZsODEaZFlUC2NESNNa1vqw6K1OyLnEsEUA5waNNFLLYXh1a3DkbhvxCKaD/rzyMWNplL6 J/kgh/8vAJSilTybFpPCh0D4+JhHRmCcAMSg0eBuTsckA5zTJRDtj5xJC5oayF/hM0DkxC0EY45G OBxmtU0786dCoOgkPLwGHx+EHhbCY6YVPcR846EAROyFy5GRObJPyD7dEf3o4UkAEN+VJ8vCr3Gb 9sLPveQRMZ8RfOOj8Xf0ixpv7z87XyRkrinzLroisUqbVH1LGnKCAhBlLWmYmVRIvt45no3RIVwd +aIAxJj6qmeyr0Biz3kitJ9p+cxUGtaHQ3SettJN6obxX2qX9rFcqqYRGqAN9MPWIxEXcQNG8ulT nwfGjy3m2PQ1YdSTyJmIgtD937mSRDZjym66b+WJKQYuUkWQanm0vfXjyOmWReEhCPAPeNbpG389 Glu3cfvubZox3t4VOy4EDStTFDfdU/nO8c7OvOzs0u2keHLD9t0NEDS9FY0dM+28M65M7l3/we6i Dhk7pThPcq2XMU6btOaBnqaLsB7099o/fyy1vOTCk3po7a/Cd72XQAgu+guhwx8rbpTBvTQz2VKP 0Yck5TJMvZNrld6rNH9ck3KITK0YC3lM3anGkm9zxh6Blno1IwBULzLOGxTXA5B4kFvTNVBLJp1Z kJP8drElf3L0w6qBcO17UejArwL4x+bJlHrIgecWo1cNrUsVsaAqgto6bWgfqGV6+gF3zM0HyIMA u1l63s+a66qf74gOtHLSXyal3zBIH0Ys1t8KQFO+cvlngnShSqeeG1UFy1EXzuKDgoig+iCEfT0h V92wzb8qpVkeZ5QKwHG2Dgh7kLn1HQ9vvd70m4OptDM/rcEzZ7yovbO/nCzrECe5AxutYlqkNcmg qE0xwIgnUmIMGTfKSL4mNfsucn8MIQiEFwwnJfLotGAhkIrEBArZ1dUVYmbxAuTsfkhsw/K2NkF5 RdhXC675u4r0PsMObdZadsLrj7EZ1+TAuJl1ewh0yFRCcJYvySoxmQem4L2HvMhQYFu2dhDlQMt+ ZJgeA6QVuBq2snjMcbxg08xsrifTJ7gQBjd4qZL0NfzgFHB7pkPnpMV+cXsISmxbDiFG+YzUEybJ U6CrFnY+m9gy7tDNbY3lox09A6Q1mQZjSaXEFqwZjMedm3a20LsaGtJDhw/rD6pq0zwU2qIUf7np 3sqLb74/cAiuI9PYYLyIUtmpcTcEyu5SXO5AMNZgo+GEJ44VKGPTkoJ4B7zfhwD8Y9wl5uVkjzyL 8vk30A1P2aDSeg0ILYDsn6ooouQlh3I6orFnqbKuF+w4TFM9Y94O/Oa3CFodNHJUMf1Adko8ivtd 2PVFXwN70O08FqjBofWHNr7x6Nanj/5Jv3rfEjCwkJK02refVuaBEHP3AMkYwHQL4kc8wysjT484 Ts7Jmrrl3uWe2MsAtosJNgp9RA1Sf4EMHweYrzOtu0wyDjlaLmPEigHgpfEQMPpWIHG/5mfTkm8s Hvw+jLcBzFM4FxlSc3XLvHAVrYm80t51tgcFKCkdkk2Nlefbo2dbbNsYbaorH/U3u3Jn6QsLB691 QMA3bDK8xrrKT9v7YucwVWgLeb6xpnqoPdr/BKRljY7aQ+MAOJUHme5SbxAVDtodasazhiDJDLIB 4pWWpeHvoAj3T4jM/26uqzw//X5XSYlLJSW39I3N91T7ACZHc13Nten3AkaHUeYKwcAzlEYjYtPb 6AAbcQaMs+KDyoE+Rmh/y4rwjtYzc3ckjzNA1K3TtJEp6mi9Gkm0fCn8I1S/PdqjJcwIzkJCn+CD 2EQJasLV76d78J+uj0cvLMilePn9dTW9/nxXV6FIiu7vZdnpXzfW1CRvZUDTT5lHv0M/kAgmFtHz 6P3egiz8rNjvNyaZ0PiMbJkNAIsSixXxMqwNACTk+6Vc6Lvj8fjh2wELGD4Jajvp8vhUpuvtxbM+ PUx7WIhWBY2YHw6iO/6b9xlaLcXF/Pau/rtIWDdQPi3p6q6ioopQezS20iQacaW0mhtq+oJSjLj+ 2/nuP0OH9CYTGQD+QjatX5wBSVrxHIOrtdwUd3CX/kwkPcb03W4qWQGV57tKXRUi5J8F4wA+b+Bc /yjIkPFm1a++s+qKueAKJ19Ca9aEc+WYa5LLJff8hoQZyiPOFmPBYIatGUkdzlA/sSg9mxDgfPbr i40U+kQLaQpXQBLGVcXVORSgKqWpYMKnGRlANlyZPC+DRmvyfWFGHMJUQ8xVf/RI1JBpjaDGWOjH LmTZvGcsRRU4ET8FyKB4zQwgTTFt0HX0iMWZQ7lvNgxcSsX7EGx1Tea9WyrXjUp5WuBNZ6DzxMFU 086dbfE46aKizGE044Z78bJyAIUpRN9EIXKggddnA8A/ETPrcJQP47I86Jy2NQZv4jem7zEjA614 eWiR4adxIG2G8bbpL66zATKbNf8CtKtM41O+pTwAAAAASUVORK5CYII= --089e01176d1b5c40d70530d75745-- From nobody Tue Apr 19 14:04:56 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A53D12E5B6 for ; Tue, 19 Apr 2016 14:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSfN20Wm4521 for ; Tue, 19 Apr 2016 14:04:54 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A0312E4DA for ; Tue, 19 Apr 2016 14:04:53 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id c20so10385723pfc.1 for ; Tue, 19 Apr 2016 14:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=CFoPlB/mZKvE0Wgx74JPgb/RP+rMEwu/cwplIwuUJOc=; b=MfCUI9Hb1YENdt673IczK1jNoNv/nstkDIeyigX3AemI7Guiig8mCDCSQfpjcyv3eo vU3JxzvSCLxxuzX+P78Z1uFrns7VyAKGbDoJefcmTM1L3YRposznjjVCXGiVjm/c2C7W PA5xkC6sbLpfCILD2q0rv6OuvPLrftfHGJ2+rKlP1UoNrPOLjt/0jGsdUI/RHOuMdfsh Q+vDHromj7ElEUAkem6OyJTJJMOFk6Xspe2oUDGcQ0vJHqZgI3KwWNAFY45sHJugbCm/ WwHZhWTdwoS93SNf2HbN4CUIprYU42OgYGkGWtKiz2g/C5p6qRKBv9Y/OtzZheR56gSK BXLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=CFoPlB/mZKvE0Wgx74JPgb/RP+rMEwu/cwplIwuUJOc=; b=ibIdCnvv5R7VeivLvsClo4G5Kfj3d/KcXrYC6WFpBt1HmvDY4wlKKMS33w5bRPX5UE J8RqB8qREc6gVmBIDNk5J4zWIoeXkLvpp8kxpLM1v2jqiYwH0hkflSi3YxbOKuSiGuUE lPWNIbqzz+c2yMctslG6s7tvKtNpdEiuMairWc6YZIiJ0N4njl+pjR3YE7+R+Ch3V+LM 4og0VmLOifnuXIs7A8Hqzzm6SydZhQTk8/Jf+mESJalfcLli2+c+8peH5TLqMuaMbo3x 2LibRkvNZdBaWXXd9lXeQrGSiwarRwP8V9kOTEXTpBsTcQgY+wO6Ccv55vDBcNbpk9gt v4Ag== X-Gm-Message-State: AOPr4FXVS5MaKnXCp04P+u9pce+QaYH1tN4BHMwR6qWWa1I1pOL76SqcQIkqxGTFf4eZYg== X-Received: by 10.98.36.195 with SMTP id k64mr7099764pfk.88.1461099893439; Tue, 19 Apr 2016 14:04:53 -0700 (PDT) Received: from localhost.localdomain (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by smtp.gmail.com with ESMTPSA id u2sm92991304pfi.26.2016.04.19.14.04.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Apr 2016 14:04:52 -0700 (PDT) Message-ID: <1461099891.2390.49.camel@gmail.com> From: Rex Buddenberg To: Alexandre Petrescu , Jong-Hyouk Lee Date: Tue, 19 Apr 2016 14:04:51 -0700 In-Reply-To: <5716308A.9030107@gmail.com> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> <57161C0F.7000908@gmail.com> <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> <57162615.7030409@gmail.com> <88F8BA46-40B6-49E6-B44A-8AE1F27C84BD@gmail.com> <5716308A.9030107@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: Thierry Ernst , "its@ietf.org" , "Sri Gundavelli \(sgundave\)" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 21:04:55 -0000 On Tue, 2016-04-19 at 15:20 +0200, Alexandre Petrescu wrote: > > What's the difference between ITS station router and ITS station > gateway? Gateway, router and hub used to be synonymous (back in '70s).  But - gateway usually means layer 7 gateway -- a translation between internet (i.e. IP) and something else.  The most ubiquitous layer 7 gateways are those in telco central offices which translate from IP to POTS phone (to keep the local loop unchanged). - router.  Eats IP datagrams, spits them back out another port.  Strictly layer 3 functions.  Terminology abuse usually results from mixing in layer 1/2 functions.   - switch.  layer 2 bridge. IEEE 802.16 (and probably mirrored in TIA LTE) is the notion of subscriber station and base station.  SS and BS.  This is strictly a layer 2 issue, nothing to do with routing.      Important because radio is a shared medium and most of terrestrial internet is point-to-point.   IEEE 802.11 has similar namecalling: what 802.16 calls BS is called access point (AP).  What you don't want to do is fall into the marketing trap of a 'wifi router'.  Both AP and routing functions are bundled into the same box.  That's a packaging issue, not a protocol one.   Getting >1 layer function into a definition is probably a poor idea because then you can't change one thing without addressing all of them.  Life cycle maintainability ran around on modularity shortcomings.  (terms like 'road side units' have this shortcoming because they have multiple layer (usually 2 and 3) functions in the box.  It's ok to manufacture this way, but it's not a good way to write the protocols. From nobody Wed Apr 20 21:10:23 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2189612E0A7 for ; Wed, 20 Apr 2016 21:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dKJB7-NJF7X for ; Wed, 20 Apr 2016 21:10:20 -0700 (PDT) Received: from mail-pa0-x244.google.com (mail-pa0-x244.google.com [IPv6:2607:f8b0:400e:c03::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB8212DF7B for ; Wed, 20 Apr 2016 21:10:20 -0700 (PDT) Received: by mail-pa0-x244.google.com with SMTP id i5so5339342pag.3 for ; Wed, 20 Apr 2016 21:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YC/d+A6HpGG4voaw+7TUVuFAzjZLO0Ay42dycWhbAm0=; b=yss4JK5gQ58GOXkJh470IlGVhW8KN+Jc9kjhOqEeX+s2ybYiLqqOEX5U7txs3zHixy grA9VFT8NtN2avqm2V0PoGMZS4Nj47jQ73nx3ihsSdk84ScRCILy5k9oxN9inK+0tLZX Rc2FkvKMnJp3F9+CS08VO1jAdABJbStX1UY9H4rijJAmVGX26zOtmFiGPBj6y/Tw++FX wS3aEBJOp5G+hsQKE4Iw1i5ieGKu06svty83UmU+OSpXqBBdqSDkh2BlRAzYauPV7WXu p1oNi9/3Gf7ww3n8nZ0jjMPXTjUkhnFVMN/NXNK9FMQovD+D18t0N8a/buW3livBRvdO E8Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YC/d+A6HpGG4voaw+7TUVuFAzjZLO0Ay42dycWhbAm0=; b=GpiG4gdnMaAaiUUXg8emgRKbX7Ae6ArX5CZ7unouDPGIC9JTlX6Xpd7jFMgwao9k20 IeS/d6fbbBtJKyTMYxcQ+PE38TUff4Eoe8nDZ3dMTpTjN+xDUCgS47txxYpPM/0UmHLY fTsY+XENzmmk2dHzdAwf3YrbXfMYG/boRDVQ6ToMiphRl99qLE6Tf6h5usiqPpKhFcpr FG9y3c+nTj2bYWbIgRFZbxqA7Uys4V79dieF0KYG5D10Z/QHa3xCmgSZPkthN8x0iJGh o55UhtMCe9tsKjrVocztjK7w25J2zpKvZPWKWkk5u/W+KfyaWi8fIyPLSHDOku0uogsc iWOA== X-Gm-Message-State: AOPr4FWJFYPQQg1+QWOsnYdyIuqt/xWxbPDSjtlRzcTKJR1sbKumocoXXSxYM/qcP6jdjA== X-Received: by 10.66.183.36 with SMTP id ej4mr17381263pac.53.1461211819888; Wed, 20 Apr 2016 21:10:19 -0700 (PDT) Received: from [10.10.0.14] ([122.202.248.11]) by smtp.gmail.com with ESMTPSA id q26sm769936pfi.57.2016.04.20.21.10.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Apr 2016 21:10:19 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=iso-8859-1 From: Jong-Hyouk Lee In-Reply-To: <4C7791ED834042AEA3C55A7217FD3055@SRA4> Date: Thu, 21 Apr 2016 13:10:15 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <631FB056-E97D-4652-B0F8-02DA5B4FA3E0@gmail.com> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> <57161C0F.7000908@gmail.com> <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> <57162615.7030409@gmail.com> <88F8BA46-40B6-49E6-B44A-8AE1F27C84BD@gmail.com> <5716308A.9030107@gmail.com> <1461099891.2390.49.camel@gmail.com> <4C7791ED834042AEA3C55A7217FD3055@SRA4> To: dickroy@alum.mit.edu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Rex Buddenberg , Alexandre Petrescu , Thierry Ernst , its@ietf.org, "Sri Gundavelli \(sgundave\)" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 04:10:22 -0000 Hi=20 -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 21, 2016, at 7:44 AM, Richard Roy wrote: >=20 > To expand a bit on Rex's comments, an ITS station (mobile) router is = an > entity that manages (IP(v6)) connectivity at layer 3 in an ITS-S. An = ITS > station gateway is a component of an ITS-S that has two main = functions: 1) > network and transport layer protocol translation where necessary (as = noted > below), and most importantly, 2) firewall (security) provisioning = which > prevents unauthorized access to the ITS-S (which is DEFINED AS a = bounded, > secure, managed domain!). Just to be clear, the ITS station gateway cannot provide the firewall = function to the ITS station host and router; it provides the firewall = function to the ECUs on the proprietary in-vehicle network. J. > It is this security functionality that is > critical to the success of many envisaged ITS services. >=20 > Hope this helps ... >=20 > RR >=20 >> -----Original Message----- >> From: Rex Buddenberg [mailto:buddenbergr@gmail.com] >> Sent: Tuesday, April 19, 2016 2:05 PM >> To: Alexandre Petrescu; Jong-Hyouk Lee >> Cc: Thierry Ernst; its@ietf.org; Sri Gundavelli (sgundave) >> Subject: Re: [its] charter ITS - proposed work items >>=20 >> On Tue, 2016-04-19 at 15:20 +0200, Alexandre Petrescu wrote: >>>=20 >>> What's the difference between ITS station router and ITS station >>> gateway? >>=20 >> Gateway, router and hub used to be synonymous (back in '70s). But >>=20 >> - gateway usually means layer 7 gateway -- a translation between >> internet (i.e. IP) and something else. The most ubiquitous layer 7 >> gateways are those in telco central offices which translate from IP = to >> POTS phone (to keep the local loop unchanged). >>=20 >> - router. Eats IP datagrams, spits them back out another port. >> Strictly layer 3 functions. Terminology abuse usually results from >> mixing in layer 1/2 functions. >>=20 >> - switch. layer 2 bridge. >>=20 >> IEEE 802.16 (and probably mirrored in TIA LTE) is the notion of >> subscriber station and base station. SS and BS. This is strictly a >> layer 2 issue, nothing to do with routing. >> Important because radio is a shared medium and most of = terrestrial >> internet is point-to-point. >>=20 >> IEEE 802.11 has similar namecalling: what 802.16 calls BS is called >> access point (AP). What you don't want to do is fall into the >> marketing trap of a 'wifi router'. Both AP and routing functions are >> bundled into the same box. That's a packaging issue, not a protocol >> one. >>=20 >> Getting >1 layer function into a definition is probably a poor idea >> because then you can't change one thing without addressing all of = them. >> Life cycle maintainability ran around on modularity shortcomings. >> (terms like 'road side units' have this shortcoming because they = have >> multiple layer (usually 2 and 3) functions in the box. It's ok to >> manufacture this way, but it's not a good way to write the protocols. >>=20 >>=20 >=20 >=20 From nobody Thu Apr 21 01:26:21 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F76212E9EE for ; Thu, 21 Apr 2016 01:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtRkqJhfaNjF for ; Thu, 21 Apr 2016 01:26:17 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B606612E9E1 for ; Thu, 21 Apr 2016 01:26:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3L8Q9YC007474; Thu, 21 Apr 2016 10:26:09 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 48D0720F049; Thu, 21 Apr 2016 10:27:39 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 31ED72012DE; Thu, 21 Apr 2016 10:27:39 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3L8Q8Nh009411; Thu, 21 Apr 2016 10:26:09 +0200 To: Jong-Hyouk Lee , dickroy@alum.mit.edu References: <57058375.6050101@gmail.com> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> <57161C0F.7000908@gmail.com> <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> <57162615.7030409@gmail.com> <88F8BA46-40B6-49E6-B44A-8AE1F27C84BD@gmail.com> <5716308A.9030107@gmail.com> <1461099891.2390.49.camel@gmail.com> <4C7791ED834042AEA3C55A7217FD3055@SRA4> <631FB056-E97D-4652-B0F8-02DA5B4FA3E0@gmail.com> From: Alexandre Petrescu Message-ID: <57188EA0.5090705@gmail.com> Date: Thu, 21 Apr 2016 10:26:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <631FB056-E97D-4652-B0F8-02DA5B4FA3E0@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Rex Buddenberg , Thierry Ernst , its@ietf.org, "Sri Gundavelli \(sgundave\)" Subject: Re: [its] charter ITS - terminology X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:26:20 -0000 Hi, The terms of "ITS station" will need to be agreed on, and defined in the Terminology section of a draft. But now, when writing charter text, I need the following terms: V2V - vehicle to vehicle communications V2Internet - vehicle to Internet-at-large communications V2I - vehicle to immediate infrastructure communications I2V - infrastructure to a vehicle passing by I hope these terms make sense to you too. Alex Le 21/04/2016 06:10, Jong-Hyouk Lee a crit : > Hi -- Jong-Hyouk Lee, living somewhere between /dev/null and > /dev/random Protocol Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com #webpage: > https://sites.google.com/site/hurryon > >> On Apr 21, 2016, at 7:44 AM, Richard Roy >> wrote: >> >> To expand a bit on Rex's comments, an ITS station (mobile) router >> is an entity that manages (IP(v6)) connectivity at layer 3 in an >> ITS-S. An ITS station gateway is a component of an ITS-S that has >> two main functions: 1) network and transport layer protocol >> translation where necessary (as noted below), and most importantly, >> 2) firewall (security) provisioning which prevents unauthorized >> access to the ITS-S (which is DEFINED AS a bounded, secure, managed >> domain!). > > Just to be clear, the ITS station gateway cannot provide the firewall > function to the ITS station host and router; it provides the firewall > function to the ECUs on the proprietary in-vehicle network. > > J. > >> It is this security functionality that is critical to the success >> of many envisaged ITS services. >> >> Hope this helps ... >> >> RR >> >>> -----Original Message----- From: Rex Buddenberg >>> [mailto:buddenbergr@gmail.com] Sent: Tuesday, April 19, 2016 2:05 >>> PM To: Alexandre Petrescu; Jong-Hyouk Lee Cc: Thierry Ernst; >>> its@ietf.org; Sri Gundavelli (sgundave) Subject: Re: [its] >>> charter ITS - proposed work items >>> >>> On Tue, 2016-04-19 at 15:20 +0200, Alexandre Petrescu wrote: >>>> >>>> What's the difference between ITS station router and ITS >>>> station gateway? >>> >>> Gateway, router and hub used to be synonymous (back in '70s). >>> But >>> >>> - gateway usually means layer 7 gateway -- a translation between >>> internet (i.e. IP) and something else. The most ubiquitous layer >>> 7 gateways are those in telco central offices which translate >>> from IP to POTS phone (to keep the local loop unchanged). >>> >>> - router. Eats IP datagrams, spits them back out another port. >>> Strictly layer 3 functions. Terminology abuse usually results >>> from mixing in layer 1/2 functions. >>> >>> - switch. layer 2 bridge. >>> >>> IEEE 802.16 (and probably mirrored in TIA LTE) is the notion of >>> subscriber station and base station. SS and BS. This is >>> strictly a layer 2 issue, nothing to do with routing. Important >>> because radio is a shared medium and most of terrestrial internet >>> is point-to-point. >>> >>> IEEE 802.11 has similar namecalling: what 802.16 calls BS is >>> called access point (AP). What you don't want to do is fall into >>> the marketing trap of a 'wifi router'. Both AP and routing >>> functions are bundled into the same box. That's a packaging >>> issue, not a protocol one. >>> >>> Getting >1 layer function into a definition is probably a poor >>> idea because then you can't change one thing without addressing >>> all of them. Life cycle maintainability ran around on modularity >>> shortcomings. (terms like 'road side units' have this shortcoming >>> because they have multiple layer (usually 2 and 3) functions in >>> the box. It's ok to manufacture this way, but it's not a good >>> way to write the protocols. >>> >>> >> >> > > From nobody Thu Apr 21 01:31:57 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94BF12EB2A for ; Thu, 21 Apr 2016 01:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZVpvzk171OY for ; Thu, 21 Apr 2016 01:31:54 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F2312EB25 for ; Thu, 21 Apr 2016 01:31:53 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id e190so6580672pfe.0 for ; Thu, 21 Apr 2016 01:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y4h0lzeptumCsKIAOUKojVhgnDakCAxZkzKwZeKQ/Gw=; b=Gg9OL0wPV7rkLpgMsMcR6vmRS7X82MvzTKC3o+XGyFlq0hiEgQOOy/Ps3J0LIhOcRh IvrGUX6IC8IY0zIlh7VlwfEoFomQ8R2cp+iSjoNA6fj6xrqeRmBl29MAmGkh0/zwgBRK xBuZdOh1cBByFyn9lmOKJWn/SIAPe9/glk6K/1vsQP2CY6bsuJaOsO0clW20wrfE8pd5 40sATLRfkR8Q9YL1JYkYekA4xjPS83wiWf3iaeRiryGqyXWkpYuLCT64zcrdUS2ABoRG OVksuufNz0nlqYprkUNhYNGUwREBocfEIh8Nn1Hb/TGrRnCkeZYFSuBAji3CnWUId5Ug qjPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y4h0lzeptumCsKIAOUKojVhgnDakCAxZkzKwZeKQ/Gw=; b=bhJHEo1AUkP6TkszG2ZnLpQHCQ5sKjreri+2tkKxCmLrO4nV8eA+KpqYhg6/MSFPrC mE6mknLEbaXp6QVaFJ4zbFU9WvVUlKwj5sNBVWYmbGLbt0pK9M+2gpFrqnoVwdnYVPxd U1zJ4zlutQ7hIq3/wnyCpwFt8/do8KY2HRExpMwy5fadMCf2iwg2cf/rknMWdaWPm7cl TZKFO1GOFLbnTiwMjNkFcPcEnGnKrD+mGLzrjVyb1Cb51IdY+Puukcst+aCf/rgHLynE UbTzMJ5tUaDj5LEAUsFnDg3spCscu6sGYvx0B6GGJnnWE22AxCskO1uFNFAkwPI3i+9x 491g== X-Gm-Message-State: AOPr4FWCUIKHf2h9t3ZW/X89P67Y6mdOfz32vmkK7jTSQDRq8hXo2F+ucEHFC0XBJKQDgA== X-Received: by 10.98.43.7 with SMTP id r7mr18891943pfr.24.1461227513275; Thu, 21 Apr 2016 01:31:53 -0700 (PDT) Received: from [10.10.0.14] ([122.202.248.11]) by smtp.gmail.com with ESMTPSA id q70sm2843746pfj.81.2016.04.21.01.31.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Apr 2016 01:31:52 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=windows-1252 From: Jong-Hyouk Lee In-Reply-To: <57188EA0.5090705@gmail.com> Date: Thu, 21 Apr 2016 17:31:48 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57058375.6050101@gmail.com> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> <57161C0F.7000908@gmail.com> <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> <57162615.7030409@gmail.com> <88F8BA46-40B6-49E6-B44A-8AE1F27C84BD@gmail.com> <5716308A.9030107@gmail.com> <1461099891.2390.49.camel@gmail.com> <4C7791ED834042AEA3C55A7217FD3055@SRA4> <631FB056-E97D-4652-B0F8-02DA5B4FA3E0@gmail.com> <57188EA0.5090705@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Rex Buddenberg , dickroy@alum.mit.edu, Thierry Ernst , its@ietf.org, "Sri Gundavelli \(sgundave\)" Subject: Re: [its] charter ITS - terminology X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:31:56 -0000 To me, those are fine. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 21, 2016, at 5:26 PM, Alexandre Petrescu = wrote: >=20 > Hi, >=20 > The terms of "ITS station" will need to be agreed on, and defined in = the Terminology section of a draft. >=20 > But now, when writing charter text, I need the following terms: >=20 > V2V - vehicle to vehicle communications > V2Internet - vehicle to Internet-at-large communications > V2I - vehicle to immediate infrastructure communications > I2V - infrastructure to a vehicle passing by >=20 > I hope these terms make sense to you too. >=20 > Alex >=20 > Le 21/04/2016 06:10, Jong-Hyouk Lee a =E9crit : >> Hi -- Jong-Hyouk Lee, living somewhere between /dev/null and >> /dev/random Protocol Engineering Lab., Sangmyung University >>=20 >> #email: jonghyouk@gmail.com #webpage: >> https://sites.google.com/site/hurryon >>=20 >>> On Apr 21, 2016, at 7:44 AM, Richard Roy >>> wrote: >>>=20 >>> To expand a bit on Rex's comments, an ITS station (mobile) router >>> is an entity that manages (IP(v6)) connectivity at layer 3 in an >>> ITS-S. An ITS station gateway is a component of an ITS-S that has >>> two main functions: 1) network and transport layer protocol >>> translation where necessary (as noted below), and most importantly, >>> 2) firewall (security) provisioning which prevents unauthorized >>> access to the ITS-S (which is DEFINED AS a bounded, secure, managed >>> domain!). >>=20 >> Just to be clear, the ITS station gateway cannot provide the firewall >> function to the ITS station host and router; it provides the firewall >> function to the ECUs on the proprietary in-vehicle network. >>=20 >> J. >>=20 >>> It is this security functionality that is critical to the success >>> of many envisaged ITS services. >>>=20 >>> Hope this helps ... >>>=20 >>> RR >>>=20 >>>> -----Original Message----- From: Rex Buddenberg >>>> [mailto:buddenbergr@gmail.com] Sent: Tuesday, April 19, 2016 2:05 >>>> PM To: Alexandre Petrescu; Jong-Hyouk Lee Cc: Thierry Ernst; >>>> its@ietf.org; Sri Gundavelli (sgundave) Subject: Re: [its] >>>> charter ITS - proposed work items >>>>=20 >>>> On Tue, 2016-04-19 at 15:20 +0200, Alexandre Petrescu wrote: >>>>>=20 >>>>> What's the difference between ITS station router and ITS >>>>> station gateway? >>>>=20 >>>> Gateway, router and hub used to be synonymous (back in '70s). >>>> But >>>>=20 >>>> - gateway usually means layer 7 gateway -- a translation between >>>> internet (i.e. IP) and something else. The most ubiquitous layer >>>> 7 gateways are those in telco central offices which translate >>>> from IP to POTS phone (to keep the local loop unchanged). >>>>=20 >>>> - router. Eats IP datagrams, spits them back out another port. >>>> Strictly layer 3 functions. Terminology abuse usually results >>>> from mixing in layer 1/2 functions. >>>>=20 >>>> - switch. layer 2 bridge. >>>>=20 >>>> IEEE 802.16 (and probably mirrored in TIA LTE) is the notion of >>>> subscriber station and base station. SS and BS. This is >>>> strictly a layer 2 issue, nothing to do with routing. Important >>>> because radio is a shared medium and most of terrestrial internet >>>> is point-to-point. >>>>=20 >>>> IEEE 802.11 has similar namecalling: what 802.16 calls BS is >>>> called access point (AP). What you don't want to do is fall into >>>> the marketing trap of a 'wifi router'. Both AP and routing >>>> functions are bundled into the same box. That's a packaging >>>> issue, not a protocol one. >>>>=20 >>>> Getting >1 layer function into a definition is probably a poor >>>> idea because then you can't change one thing without addressing >>>> all of them. Life cycle maintainability ran around on modularity >>>> shortcomings. (terms like 'road side units' have this shortcoming >>>> because they have multiple layer (usually 2 and 3) functions in >>>> the box. It's ok to manufacture this way, but it's not a good >>>> way to write the protocols. >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 From nobody Thu Apr 21 01:46:51 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F4712D6B2 for ; Thu, 21 Apr 2016 01:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-Vir51rDoE0 for ; Thu, 21 Apr 2016 01:46:47 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7232C12D85B for ; Thu, 21 Apr 2016 01:46:46 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id v188so234876382wme.1 for ; Thu, 21 Apr 2016 01:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=B2lDZ49oGft/kvhiPyxB36Vb0ucy1EYzWlceQsfKHbg=; b=DfcG1CLhMV0+dVDHhn8qjrnETuKpy1WzUJp1nFSgu3iERf6Rjg/BLf7Zn04ZnwNT9e e0bgDem0klgX+OPsbF1uNaZoHBBn8IZQXqgaqtPSBSOxr39QIlRJTrT45bJUwpMkJJdb ivSHhAT+WL1SDwQF6+05WHZtHGv59/UWcHSRj29Caj3b3ZmXksXz1e6HYbgghZtrOjq8 3rJ2WYuzIGvg3In/C3kjCQ+dv7dgQFrFZcHsitxNHgBzkKjlgex9VoH0Actw4OGqkOqw 5jHOGep3ZoVunFthlWQ8Fb1oR5pBqz1kor+cPrLrTzSvTTyM+qHXdkL2bi/qAU3D1Fim Y8ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=B2lDZ49oGft/kvhiPyxB36Vb0ucy1EYzWlceQsfKHbg=; b=D2NTh7A3NdXmX6zRZ4RKL2KOjdv+0n8wPHdsAtFtOj2o4f5DWy+a3fHSbe2lmwSuWb sVuFCf4xtSAp9tZdZXohCEkCPDzh13JPBu8OFGcSf+esLMgcAsbToTNmgsHIPX1/GpE1 ShndhzFx/uLjcyCVLx1RTIThKIe6cULVbxKbDmaxgxYFM56YGQyb/4DjZKful3+gGdCc YjH2eT5TCB1MwMzynXNhRkqkXZCoXZ4LKDbnK7RNHlKGKBRJFxZClIlnr9ZESfWPXVFI /iLBi2C7tXj2f2JuUojD/ObREOqnHrxjVtThVEzPMVSNRs+XAuKw+GtDY2GmulWgY5oV brfQ== X-Gm-Message-State: AOPr4FVw3LwvqfPZtxWPpqNfv6qgA/g6XL1tff9zzxGQ6PlkyMf8IKfWezDO+Vy2Np/8Ot3WdJTYHCfg5oREJg== MIME-Version: 1.0 X-Received: by 10.195.13.135 with SMTP id ey7mr12772371wjd.161.1461228404867; Thu, 21 Apr 2016 01:46:44 -0700 (PDT) Received: by 10.28.224.137 with HTTP; Thu, 21 Apr 2016 01:46:44 -0700 (PDT) In-Reply-To: References: <57058375.6050101@gmail.com> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <57149222.8090806@gmail.com> <78149E14-C77C-49E9-A992-D24773951FA5@gmail.com> <5714C3B9.8030904@gmail.com> <109AC3B1-1148-44E7-8C4B-C997A00A6A07@gmail.com> <57151593.4010807@gmail.com> <57161C0F.7000908@gmail.com> <29E58B6D-3808-48FE-BAAA-377931D4F56A@gmail.com> <57162615.7030409@gmail.com> <88F8BA46-40B6-49E6-B44A-8AE1F27C84BD@gmail.com> <5716308A.9030107@gmail.com> <1461099891.2390.49.camel@gmail.com> <4C7791ED834042AEA3C55A7217FD3055@SRA4> <631FB056-E97D-4652-B0F8-02DA5B4FA3E0@gmail.com> <57188EA0.5090705@gmail.com> Date: Thu, 21 Apr 2016 09:46:44 +0100 Message-ID: From: Nabil Benamar To: Jong-Hyouk Lee Content-Type: multipart/alternative; boundary=047d7bb04dc40211fe0530fac08b Archived-At: Cc: Rex Buddenberg , "its@ietf.org" , Thierry Ernst , "Sri Gundavelli \(sgundave\)" , Alexandre Petrescu , Richard Roy Subject: Re: [its] charter ITS - terminology X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:46:49 -0000 --047d7bb04dc40211fe0530fac08b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, I agree on the terms proposed and defined by Alex. Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Thu, Apr 21, 2016 at 9:31 AM, Jong-Hyouk Lee wrote= : > To me, those are fine. > -- > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > Protocol Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com > #webpage: https://sites.google.com/site/hurryon > > > On Apr 21, 2016, at 5:26 PM, Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > > > > Hi, > > > > The terms of "ITS station" will need to be agreed on, and defined in th= e > Terminology section of a draft. > > > > But now, when writing charter text, I need the following terms: > > > > V2V - vehicle to vehicle communications > > V2Internet - vehicle to Internet-at-large communications > > V2I - vehicle to immediate infrastructure communications > > I2V - infrastructure to a vehicle passing by > > > > I hope these terms make sense to you too. > > > > Alex > > > > Le 21/04/2016 06:10, Jong-Hyouk Lee a =C3=A9crit : > >> Hi -- Jong-Hyouk Lee, living somewhere between /dev/null and > >> /dev/random Protocol Engineering Lab., Sangmyung University > >> > >> #email: jonghyouk@gmail.com #webpage: > >> https://sites.google.com/site/hurryon > >> > >>> On Apr 21, 2016, at 7:44 AM, Richard Roy > >>> wrote: > >>> > >>> To expand a bit on Rex's comments, an ITS station (mobile) router > >>> is an entity that manages (IP(v6)) connectivity at layer 3 in an > >>> ITS-S. An ITS station gateway is a component of an ITS-S that has > >>> two main functions: 1) network and transport layer protocol > >>> translation where necessary (as noted below), and most importantly, > >>> 2) firewall (security) provisioning which prevents unauthorized > >>> access to the ITS-S (which is DEFINED AS a bounded, secure, managed > >>> domain!). > >> > >> Just to be clear, the ITS station gateway cannot provide the firewall > >> function to the ITS station host and router; it provides the firewall > >> function to the ECUs on the proprietary in-vehicle network. > >> > >> J. > >> > >>> It is this security functionality that is critical to the success > >>> of many envisaged ITS services. > >>> > >>> Hope this helps ... > >>> > >>> RR > >>> > >>>> -----Original Message----- From: Rex Buddenberg > >>>> [mailto:buddenbergr@gmail.com] Sent: Tuesday, April 19, 2016 2:05 > >>>> PM To: Alexandre Petrescu; Jong-Hyouk Lee Cc: Thierry Ernst; > >>>> its@ietf.org; Sri Gundavelli (sgundave) Subject: Re: [its] > >>>> charter ITS - proposed work items > >>>> > >>>> On Tue, 2016-04-19 at 15:20 +0200, Alexandre Petrescu wrote: > >>>>> > >>>>> What's the difference between ITS station router and ITS > >>>>> station gateway? > >>>> > >>>> Gateway, router and hub used to be synonymous (back in '70s). > >>>> But > >>>> > >>>> - gateway usually means layer 7 gateway -- a translation between > >>>> internet (i.e. IP) and something else. The most ubiquitous layer > >>>> 7 gateways are those in telco central offices which translate > >>>> from IP to POTS phone (to keep the local loop unchanged). > >>>> > >>>> - router. Eats IP datagrams, spits them back out another port. > >>>> Strictly layer 3 functions. Terminology abuse usually results > >>>> from mixing in layer 1/2 functions. > >>>> > >>>> - switch. layer 2 bridge. > >>>> > >>>> IEEE 802.16 (and probably mirrored in TIA LTE) is the notion of > >>>> subscriber station and base station. SS and BS. This is > >>>> strictly a layer 2 issue, nothing to do with routing. Important > >>>> because radio is a shared medium and most of terrestrial internet > >>>> is point-to-point. > >>>> > >>>> IEEE 802.11 has similar namecalling: what 802.16 calls BS is > >>>> called access point (AP). What you don't want to do is fall into > >>>> the marketing trap of a 'wifi router'. Both AP and routing > >>>> functions are bundled into the same box. That's a packaging > >>>> issue, not a protocol one. > >>>> > >>>> Getting >1 layer function into a definition is probably a poor > >>>> idea because then you can't change one thing without addressing > >>>> all of them. Life cycle maintainability ran around on modularity > >>>> shortcomings. (terms like 'road side units' have this shortcoming > >>>> because they have multiple layer (usually 2 and 3) functions in > >>>> the box. It's ok to manufacture this way, but it's not a good > >>>> way to write the protocols. > >>>> > >>>> > >>> > >>> > >> > >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --047d7bb04dc40211fe0530fac08b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I agree on the terms proposed and d= efined by Alex.

Best regards
Nabil Ben= amar
-------------------
=D9=86=D8=A8= =D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88


On Thu, Apr 21, 2016 at 9:31 AM, Jong-Hyouk = Lee <jonghyouk@gmail.com> wrote:
To me, those are fine.
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

> On Apr 21, 2016, at 5:2= 6 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
>
> Hi,
>
> The terms of "ITS station" will need to be agreed on, and de= fined in the Terminology section of a draft.
>
> But now, when writing charter text, I need the following terms:
>
> V2V - vehicle to vehicle communications
> V2Internet - vehicle to Internet-at-large communications
> V2I - vehicle to immediate infrastructure communications
> I2V - infrastructure to a vehicle passing by
>
> I hope these terms make sense to you too.
>
> Alex
>
> Le 21/04/2016 06:10, Jong-Hyouk Lee a =C3=A9crit :
>> Hi -- Jong-Hyouk Lee, living somewhere between /dev/null and
>> /dev/random Protocol Engineering Lab., Sangmyung University
>>
>> #email: jonghyouk@gmail.com= #webpage:
>> https://sites.google.com/site/hurryon
>>
>>> On Apr 21, 2016, at 7:44 AM, Richard Roy <dickroy@ALUM.MIT.EDU>
>>> wrote:
>>>
>>> To expand a bit on Rex's comments, an ITS station (mobile)= router
>>> is an entity that manages (IP(v6)) connectivity at layer 3 in = an
>>> ITS-S.=C2=A0 An ITS station gateway is a component of an ITS-S= that has
>>> two main functions: 1) network and transport layer protocol >>> translation where necessary (as noted below), and most importa= ntly,
>>> 2) firewall (security) provisioning which prevents unauthorize= d
>>> access to the ITS-S (which is DEFINED AS a bounded, secure, ma= naged
>>> domain!).
>>
>> Just to be clear, the ITS station gateway cannot provide the firew= all
>> function to the ITS station host and router; it provides the firew= all
>> function to the ECUs on the proprietary in-vehicle network.
>>
>> J.
>>
>>> It is this security functionality that is critical to the succ= ess
>>> of many envisaged ITS services.
>>>
>>> Hope this helps ...
>>>
>>> RR
>>>
>>>> -----Original Message----- From: Rex Buddenberg
>>>> [mailto:buddenber= gr@gmail.com] Sent: Tuesday, April 19, 2016 2:05
>>>> PM To: Alexandre Petrescu; Jong-Hyouk Lee Cc: Thierry Erns= t;
>>>> its@ietf.org; Sri Gund= avelli (sgundave) Subject: Re: [its]
>>>> charter ITS - proposed work items
>>>>
>>>> On Tue, 2016-04-19 at 15:20 +0200, Alexandre Petrescu wrot= e:
>>>>>
>>>>> What's the difference between ITS station router a= nd ITS
>>>>> station gateway?
>>>>
>>>> Gateway, router and hub used to be synonymous (back in = 9;70s).
>>>> But
>>>>
>>>> - gateway usually means layer 7 gateway -- a translation b= etween
>>>> internet (i.e. IP) and something else.=C2=A0 The most ubiq= uitous layer
>>>> 7 gateways are those in telco central offices which transl= ate
>>>> from IP to POTS phone (to keep the local loop unchanged).<= br> >>>>
>>>> - router.=C2=A0 Eats IP datagrams, spits them back out ano= ther port.
>>>> Strictly layer 3 functions.=C2=A0 Terminology abuse usuall= y results
>>>> from mixing in layer 1/2 functions.
>>>>
>>>> - switch.=C2=A0 layer 2 bridge.
>>>>
>>>> IEEE 802.16 (and probably mirrored in TIA LTE) is the noti= on of
>>>> subscriber station and base station.=C2=A0 SS and BS.=C2= =A0 This is
>>>> strictly a layer 2 issue, nothing to do with routing. Impo= rtant
>>>> because radio is a shared medium and most of terrestrial i= nternet
>>>> is point-to-point.
>>>>
>>>> IEEE 802.11 has similar namecalling: what 802.16 calls BS = is
>>>> called access point (AP).=C2=A0 What you don't want to= do is fall into
>>>> the marketing trap of a 'wifi router'.=C2=A0 Both = AP and routing
>>>> functions are bundled into the same box.=C2=A0 That's = a packaging
>>>> issue, not a protocol one.
>>>>
>>>> Getting >1 layer function into a definition is probably= a poor
>>>> idea because then you can't change one thing without a= ddressing
>>>> all of them. Life cycle maintainability ran around on modu= larity
>>>> shortcomings. (terms like 'road side units' have t= his shortcoming
>>>> because they have multiple layer (usually 2 and 3) functio= ns in
>>>> the box.=C2=A0 It's ok to manufacture this way, but it= 's not a good
>>>> way to write the protocols.
>>>>
>>>>
>>>
>>>
>>
>>

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

--047d7bb04dc40211fe0530fac08b-- From nobody Thu Apr 21 08:50:19 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D72712DEAC for ; Thu, 21 Apr 2016 08:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1eIrXki88_g for ; Thu, 21 Apr 2016 08:50:16 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA6712DBDB for ; Thu, 21 Apr 2016 08:50:16 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id F1D5AF2401F; Thu, 21 Apr 2016 11:50:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id JoYrAYN40dhH; Thu, 21 Apr 2016 11:34:32 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 77F6CF24013; Thu, 21 Apr 2016 11:50:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <57162E84.9030507@gmail.com> Date: Thu, 21 Apr 2016 11:49:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <04ae01d199bf$3d2938d0$b77baa70$@ing.uchile.cl> <004b01d19a0c$bb4632c0$31d29840$@eurecom.fr> <57162E84.9030507@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: its@ietf.org Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 15:50:17 -0000 > You ask whether the draft proposes IPv6 mainly for safety-criticial = apps: no, the current text uses other motivators for IPv6. I think that the answer to this question belongs in an update to the = Goals in the draft charter text. At the BOF, I heard several people point out that there are many safety = communications that will not use IPv6. The charter text needs to = recognize this situation by saying that those single-hop V2V and V2I = communications are out of scope for this effort. After all, those are = being standardized elsewhere, and this effort should not overlap with = them. The current draft charter says that the goal of this effort is to: The goal of this group is to standardize IP-based protocols for establishing direct and secure connectivity between moving networks, some of which could be fixed permanently or temporarily. I throw this out to start discussion: Some vehicle communications will not use IP, including safety messages with other vehicles and infrastructure. Other vehicle communications will be IP-based protocols, especially when multiple applications need to share one data link. This group will develop IP-based protocols to establish direct and secure connectivity between a vehicle, which are 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. Russ= From nobody Thu Apr 21 13:54:57 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD41412E546 for ; Thu, 21 Apr 2016 13:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4QrSyrZITZG for ; Thu, 21 Apr 2016 13:54:54 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 835E612DC05 for ; Thu, 21 Apr 2016 13:54:54 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 464D6F2402A; Thu, 21 Apr 2016 16:54:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 7k-apPov-wdT; Thu, 21 Apr 2016 16:39:11 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 94756F24013; Thu, 21 Apr 2016 16:54:42 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <0372E48159F544E89115442BAAD41910@SRA4> Date: Thu, 21 Apr 2016 16:54:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <04ae01d199bf$3d2938d0$b77baa70$@ing.uchile.cl> <004b01d19a0c$bb4632c0$31d29840$@eurecom.fr> <57162E84.9030507@gmail.com> <0372E48159F544E89115442BAAD41910@SRA4> To: dickroy@alum.mit.edu X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Alexandre Petrescu , its@ietf.org Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:54:56 -0000 Richard: >=20 >>=20 >>> You ask whether the draft proposes IPv6 mainly for safety-criticial = apps: no, the current text uses other motivators for IPv6. >>=20 >> I think that the answer to this question belongs in an update to the = Goals >> in the draft charter text. >>=20 >> At the BOF, I heard several people point out that there are many = safety >> communications that will not use IPv6. The charter text needs to >> recognize this situation by saying that those single-hop V2V and V2I >> communications are out of scope for this effort. After all, those = are >> being standardized elsewhere, and this effort should not overlap with = them. >>=20 >> The current draft charter says that the goal of this effort is to: >>=20 >> The goal of this group is to standardize IP-based protocols for >> establishing direct and secure connectivity between moving = networks, >> some of which could be fixed permanently or temporarily. >=20 > [RR>] Fair enough, however to indicate that a "moving network" is = "fixed > permanently" begs the question of the definition of a "moving = network":^)) > That is: How can a "moving network" be "permanently fixed"??? I think that the text proposed below resolves this point you raise. >> I throw this out to start discussion: >>=20 >> Some vehicle communications will not use IP, including safety >> messages with other vehicles and infrastructure. Other vehicle >> communications will be IP-based protocols, especially when multiple >> applications need to share one data link. This group will develop >> IP-based protocols to establish direct and secure connectivity >> between a vehicle, which are 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. >>=20 >> Russ >=20 > [RR>] Perhaps it would make sense just to focus on those use cases = where IP > has value and simply ignore those where it may not be used. By = mentioning > applications and services to which IP is not well-suited just confuses > people without adding any value to the discussion or the effort. Also, = I > believe in several places above where there is reference to = communication > life-times what is really meant is "communication session" life-times = and > "session (layer) continuity using IP networking=94. I think the we need to declare that as out oaf scope for this effort in = some place in the charter. If you do not think that is the goals = section, please suggest another place that makes more sense to you. Russ From nobody Fri Apr 22 04:55:45 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0495812DF4F for ; Fri, 22 Apr 2016 04:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.053 X-Spam-Level: X-Spam-Status: No, score=-1.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSyKcTLTFZIX for ; Fri, 22 Apr 2016 04:55:43 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CCE12DF41 for ; Fri, 22 Apr 2016 04:55:43 -0700 (PDT) Received: from [192.168.0.26] (unknown [82.229.156.225]) by smtp4-g21.free.fr (Postfix) with ESMTP id D3DD719F59C; Fri, 22 Apr 2016 12:01:40 +0200 (CEST) To: Russ Housley , dickroy@alum.mit.edu References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <04ae01d199bf$3d2938d0$b77baa70$@ing.uchile.cl> <004b01d19a0c$bb4632c0$31d29840$@eurecom.fr> <57162E84.9030507@gmail.com> <0372E48159F544E89115442BAAD41910@SRA4> From: Alexandre Petrescu Message-ID: <571A112F.5030603@gmail.com> Date: Fri, 22 Apr 2016 13:55:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: its@ietf.org Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 11:55:45 -0000 Le 21/04/2016 22:54, Russ Housley a crit : > Richard: > >> >>> >>>> You ask whether the draft proposes IPv6 mainly for >>>> safety-criticial apps: no, the current text uses other >>>> motivators for IPv6. >>> >>> I think that the answer to this question belongs in an update to >>> the Goals in the draft charter text. >>> >>> At the BOF, I heard several people point out that there are many >>> safety communications that will not use IPv6. The charter text >>> needs to recognize this situation by saying that those single-hop >>> V2V and V2I communications are out of scope for this effort. >>> After all, those are being standardized elsewhere, and this >>> effort should not overlap with them. >>> >>> The current draft charter says that the goal of this effort is >>> to: >>> >>> The goal of this group is to standardize IP-based protocols for >>> establishing direct and secure connectivity between moving >>> networks, some of which could be fixed permanently or >>> temporarily. >> >> [RR>] Fair enough, however to indicate that a "moving network" is >> "fixed permanently" begs the question of the definition of a >> "moving network":^)) That is: How can a "moving network" be >> "permanently fixed"??? > > I think that the text proposed below resolves this point you raise. > >>> I throw this out to start discussion: >>> >>> Some vehicle communications will not use IP, including safety >>> messages with other vehicles and infrastructure. Other vehicle >>> communications will be IP-based protocols, especially when >>> multiple applications need to share one data link. This group >>> will develop IP-based protocols to establish direct and secure >>> connectivity between a vehicle, which are 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. >>> >>> Russ >> >> [RR>] Perhaps it would make sense just to focus on those use cases >> where IP has value and simply ignore those where it may not be >> used. By mentioning applications and services to which IP is not >> well-suited just confuses people without adding any value to the >> discussion or the effort. Also, I believe in several places above >> where there is reference to communication life-times what is really >> meant is "communication session" life-times and "session (layer) >> continuity using IP networking. > > I think the we need to declare that as out oaf scope for this effort > in some place in the charter. If you do not think that is the goals > section, please suggest another place that makes more sense to you. I propose the following paragraph towards the end of the Charter: This group will not work on V2V or V2I use-cases where IP is not well-suited, including safety messages with other vehicles and infrastructure. Is it ok? Alex > > Russ > > From nobody Fri Apr 22 04:57:28 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E1812E683 for ; Fri, 22 Apr 2016 04:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAMDnyqBXII1 for ; Fri, 22 Apr 2016 04:57:22 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C8612E64B for ; Fri, 22 Apr 2016 04:57:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3MBvFTI020107; Fri, 22 Apr 2016 13:57:15 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A52ED2049BA; Fri, 22 Apr 2016 13:58:46 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 963E52047F2; Fri, 22 Apr 2016 13:58:46 +0200 (CEST) Received: from [132.166.85.25] ([132.166.85.25]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3MBvE8F031124; Fri, 22 Apr 2016 13:57:14 +0200 To: dickroy@alum.mit.edu, "'Jong-Hyouk Lee'" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <4F249A9B9BE3463A89F7608549FBA84C@SRA4> From: Alexandre Petrescu Message-ID: <571A119A.3010701@gmail.com> Date: Fri, 22 Apr 2016 13:57:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <4F249A9B9BE3463A89F7608549FBA84C@SRA4> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: its@ietf.org Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 11:57:25 -0000 Le 22/04/2016 01:53, Richard Roy a crit : > I'd like to suggest that the strict focus on ITS may be leading the > discussion astray somewhat. ITS is clearly an important use case > (and should be highlighted as such in the "reasons for doing this > work" document), but IPv6 mobility is generally important in other > application areas as well. I agree. To that end we may say 'moving network' rather than 'in-vehicle network'. And we accommodate networks deployed in trains as well: wagon-to-wagon IP communications is similar to vehicle-to-vehicle communications. And there is interest in PAN-to-homenet, as much as there is interest in PAN-to-car communications. > Furthermore, doing an ITS TVRA is clearly out of scope of any IETF > effort I would think. (TVRA - Threat Vulnerability Risk Assessment?). Certainly no generic ITS TVRA to be performed here - it is too much, and too specific to many other protocol layers of vehicular communications: PHY, MAC, transport, applications. But as with any new IETF protocol (not necessarily ITS), we need to be explicit about the new security threats induced by that new protocol. In particular, if we assume for a moment IP prefix exchanges between moving networks: this creates a new privacy risk in which a nearby moving network learns all IP addresses of this moving network; a car learns all IP addresses of the other car. Similarly, if we assume for a moment the use of (m)DNS between moving networks, there may be new threats introduced (compared to the current situation where a vehicle uses a DNS server fixed in the infrastructure). These two aspects must be part of the Threat Analysis work item. > I'd suggest using ITS communications as a key use case, then going on > to leave ITS behind and simply discuss the need for IPv6 mobility > support in rapidly varying RF and topological environments along with > a general need to address security issues, and leave it at that. It makes sense. But beware the term "IP mobility". It has a particular meaning at IETF: it means the Mobile IP protocol. The Mobile IP protocol can not be used in a V2V setting. "IP mobility" at IETF may also be understood as the DMM working group (Distributed Mobility Management). That deals mainly with infrastructure entities, not moving networks. Especially no direct links between moving networks in DMM. Alex > > My two cents ... > > RR > > ------------------------------------------------------------------------ > > > *From:*Jong-Hyouk Lee [mailto:jonghyouk@gmail.com] *Sent:* Monday, > April 18, 2016 12:32 AM *To:* Alexandre Petrescu *Cc:* its@ietf.org > *Subject:* Re: [its] charter ITS - proposed work items > > Thx, plz see inline. > > -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > Protocol Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com #webpage: > https://sites.google.com/site/hurryon > >> On Apr 18, 2016, at 3:52 PM, Alexandre Petrescu >> > > wrote: >> >> Hi Jong-Hyouk, >> >> Le 17/04/2016 14:07, Jong-Hyouk Lee a crit : >> >> Hi Alex >> >> Just to clarify. -- Jong-Hyouk Lee, living somewhere between >> /dev/null and /dev/random Protocol Engineering Lab., Sangmyung >> University >> >> #email: jonghyouk@gmail.com #webpage: >> https://sites.google.com/site/hurryon >> >> >> On Apr 14, 2016, at 5:42 PM, Alexandre Petrescu >> wrote: >> >> ITSers, >> >> We work on a more rigorous ITS charter text. >> >> Now we propose four work items: >> >> 1. "Problem statement for IP in V2V and V2I" including "IP >> addressing architecture for V2V and V2I" and including "Gap >> Analysis: IP protocols suited and gaps" and including "Use-cases >> for IP in V2V and V2I moving network to nearby moving or fixed >> network >> >> >> Are you intending to have one document that includes those three >> parts? >> >> >> Yes. >> >> Because we need to reduce the number of items. Because one of the >> remarks during BoF was that the scope was too large. >> > Humthen, the document will be too broad. We may need people to work > on each part. > >> >> >>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>> context >>> >> >> Is this mean that this group first go for this and later considers >> a general security document (e.g., security requirements for ITS) >> ? >> >> >> For now it is "Threat Analysis for IP prefix exchanges in V2V and >> V2I context. >> > Ok. For the document Threat Analysis of IP prefix exchanges in V2V > and V2I, I just started to work on. Soon I will post. > > > > > "General security requirements for ITS" seems very broad - what do > you mean more precisely? > > We may later need one document describing general security > requirements for ITS that corresponds the document PS for IP in V2V > and V2I. We will be later. ;) > > Good day! > > > > > Alex > > > > Cheers. > > > > 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], > including connectivity in fast and asymmetric conditions, coverage > area vs speed diagrams, below-IP congestion management. > > 4. "List of papers and _products_ using IP in V2V and V2I" > > What do you think? > > Please respond by next Monday, April 18th. > > Alex and Dapeng [*] a typical IP-over-foo document is, for example, > RFC2464 "Transmission of IPv6 Packets over Ethernet Networks", where > "foo" is instantiated as "Ethernet". Other IPv6-over-foo documents > are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and more. > > Le 14/04/2016 09:42, Jrme Hrri a crit : > > Paul, > > Thanks. Btw, when I mentioned people are aware of IP V2V but not > see the need (so far), I referred to the automotive SDOs (led by > automotive industries), although there are always minority > reports J > > Cheers, > > Jrme > > *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] > *Sent:* Thursday 14 April 2016 09:36 *To:* Jrme Hrri *Cc:* > Alexandre Petrescu; its@ietf.org *Subject:* Re: > [its] charter ITS > > Jrme, > > I missed that you are also an academic person. > > I got it :-) > > I understand your points for industry activity related to vehicular > networking. > > Your observation seems true. > > BTW, I will invite you to my team for the draft for a list of > academic papers for V2V and V2I > > by a personal message. > > Thanks. > > Paul > > On Thu, Apr 14, 2016 at 4:09 PM, Jrme Hrri > > > wrote: > > Hi Paul, > > Thanks for your feedback. Do not get me wrong, I am an academic and > with my team, we also work on IP-based V2V and V2I, in particular > related to mobility management with DMM, but also in the context of > vehicular IoT. > > I just have the feeling that people are perfectly aware of the fact > that IP _can_ be used for V2V and V2I, but does not _need_ to be > used as other solutions already perfectly fit their need. Listing > papers will not change this awareness. > > So, as a complement to academic papers, it would help to be able to > pin-point which industrial activities are using or are strongly > planning (short term I mean) to use pure IPv6 system in vehicles. > > My feeling here is we have a different eco-system that the > Automotive industry (and automotive industry-related SDO)..more > likely the IoT industryand as such, we should not need to have the > (direct) involvement of automotive industry in the Charter. If we can > make this clear by an industry-based survey, that would help make > the case for the WG. > > Btw, you can count on me your draft..we can add some IP-based V2V > and V2I for mobility management and also IoT. > > Cheers, > > Jrme > > *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com > ] *Sent:* Thursday 14 April 2016 > 03:22 *To:* Jrme Hrri *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [its] > charter ITS > > Hi Jrme, > > I have an opinion on your comment 5) below. > > I think that a list of high-quality papers about IP-based V2V and > V2I > > can teach very useful lessons to software designers of IP in V2V and > V2I > > in the industry. > > Multiple people are working for this IP-based V2V and V2I > > (including Sandra Cespedes and me) in academia and > > more people(including Nabil Benamar) are willing to work for this > area. > > I think we need to utilize the list of such papers as the ground for > our ITS group > > through a WI. Note that the draft of the list will include the > summary of the main > > ideas of the papers. > > For the industry current activities for this area, I believe that > you can share them > > as references through our ITS mailing list rather than through a WI. > > Could you join my team that are making efforts for a list of such > papers? > > Thanks. > > Best Regards, > > Paul > > On Thu, Apr 7, 2016 at 8:11 AM, Jrme Hrri > > > wrote: > > Dear ITSers, Dear Alex, > > Here are some comments on the updated charter: > > 1)Can we keep a reference to IEEE 802.11p, considering it does not > exist anymore? It is now fully integrated into IEEE 802.11-2012 as > OCB mode (and 10Mhz @5.9Ghz) of course. > > 2)Should we really keep C-ACC (or Platooning) in the charter > explicitly as use case, considering it is a seriously controversial > aspect with some SDOs (ex. In Automotive SDOs)? In the ISO > presentation, Thierry mentions traffic efficiency/infotainment > applications, such as in-signage applications... > > a.We might have to aim at less controversial use cases to attract > automotive industries > > 3)One potential WI I could think of (rather a basic one): > _definition of a vehicular wireless link in an automotive context_ > > a.To me, this is a fundamental brick in the larger IETF WG ITS > house.. > > 4)I would suggest to be more explicit in the foreseen challenges of > this WG, instead of mentioning general use case (which end up be > controversial) > > a.Example: maintaining IPv6 connectivity in fast and asymmetric > wireless links; also under quickly changing topologies (actually > suggested by Dick Roy on the chat room) > > b.Example: IPv6 addressing in link-local scope.. > > c.Example: guaranteeing privacy in IPv6 moving networks etc.. > > 5)Before listing academic papers referring to IPv6 in vehicles, I > would suggest to first try to list commercial products/solutions > that are in vehicles and are using IPv6, possibly suffering from a > silo limitations (ex. restricted to a single technology, single use > case) > > a.I think we need to get to products first, before academic visions > > My two cents.. > > Best Regards, > > Jrme > > *From:*its [mailto:its-bounces@ietf.org > ] *On Behalf Of *Alexandre Petrescu > *Sent:* Wednesday 06 April 2016 23:45 *To:* its@ietf.org > *Subject:* [its] charter > ITS > > ITSers, > > Please see below the current charter. > > - the two Problem Statements drafts V2V and V2I joined, so there is > less text in charter. - added an Item on "List of Research > papers..." > > Erik: did I understand you correctly that there should be some item > on discussing whether link-local addressing is sufficient, whether > prefix exchange is necessary? > > Dino: should LISP be included in the gap analysis draft which > includes C-ACC use-case? OR should we separate a dedicated I-D only > with gap analysis including ND, MIP, AODVv2, LISP? > > Person from mediatek: is the 'zeroconf' need in the > vehicle-to-vehicle interface illustrated good enough by the words > "moving network to nearby moving network communications"? Or is it > better to say "the 1-IP-hop between nearby moving networks must be > self-configured"? > > Nabil, Sandra: is it ok to have a working group item "List of > Research Papers for IP in V2V and V2I communications"? > > Other comments? > > Alex > > ------------------------------------------------------------------ > > > ITS (name to change) > >>> Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its >>> >>> >>> Intelligent Transportation Systems (its) >>> ---------------------------------------- Current Status: WG >>> forming >>> >>> Chairs: TBD >>> >>> Assigned Area Director: TBD >>> >>> Mailing list Address: its@ietf.org >>> 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: >>> >>> Goal ---- The goal of this group is to standardize IP-based >>> protocols for establishing direct and secure connectivity between >>> moving networks, some of which could be fixed permanently or >>> temporarily. >>> >>> Moving Network to Nearby Moving Network Communications >>> ------------------------------------------------------ The group >>> is concerned with all situations involving moving network to >>> nearby moving network communications. For example: >>> vehicle-to-vehicle communications, nomadic user wearing a PAN and >>> communicating to a homenet, vehicle-to-infrastructure >>> communications, wagon-to-wagon in a train, or >>> train-to-intersection signalling. >>> >>> Example from the automobile communications space >>> ------------------------------------------------ Automobiles and >>> vehicles of all types are increasingly connected to the >>> Internet, either as vehicle-to-vehicle, vehicle-to-infra or >>> vehicle-to-Internet. Entertainment apps enhancing comfort, >>> reliable data exchanges for road safety, and automated driving >>> are features coming in automobiles to hit the roads from now to >>> year 2020. Highlighting increased safety as an immediate result >>> of hyper-connectivity applied to vehicles, public authorities >>> worldwide are increasingly mandating secure communication >>> technology requirements in vehicles. >>> >>> Emergency apps for new instrumented ambulances carry many >>> benefits both to the users and to society in general. >>> >>> Why IP? ------- Today, there are several deployed >>> Vehicle-to-Internet technologies, including car tethering through >>> driver's cellular smartphone. However, Vehicle-to-Vehicle and >>> Vehicle-to-Infrastructure communications are still being >>> developed. To improve on a situation of link-specific data >>> exchanges, and enable independent application sets to share the >>> same links, IP data exchanges are needed. Enabling IP >>> communication between vehicles (V2V), and between vehicles and >>> the immediate infrastructure (V2I), will provide (0) ability to >>> reach the rest of the world on the Internet (1) short and >>> deterministic delays, (2) fast forwarding through scalable paths >>> of routers, (3) ease of reuse of existing Internet applications >>> in a vehicular environment. >>> >>> Moving network to nearby moving network communications involve >>> link layers such as: 802.11p OCB (Outside the Context of a Basic >>> Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible >>> Light Communications), IrDA, LTE-D. Only the IP protocols are >>> capable of running on each of these links and establish IP paths >>> across them in an interoperable manner. >>> >>> Scenarios? ---------- There are a few scenarios exhibiting the >>> need to communicate from one moving network to another nearby >>> moving network. >>> >>> In the automobile space, the Cooperative Adaptive Cruise Control >>> and Platooning features consider that vehicles close to each >>> other exchange data describing their kinematic status. At the >>> cross-roads, the moving network inside a vehicle exchanges data >>> with the moving network in the red-light pole. >>> >>> Several public safety scenarios involve moving networks. >>> Distinct organizations deploy different moving networks >>> (in-vehicle, on-person) at an incident scene. These networks >>> need to interoperate in order to more effectively understand and >>> deal with the incident scene. >>> >>> In connected rail scenarios the moving network deployed in >>> trains communicate with other moving networks at the >>> cross-points. >>> >>> What kind of solutions? ----------------------- The current >>> technical solutions considered to achieve moving network to >>> nearby moving network communications are of two kinds: IP >>> routing protocols for n-hop path management and 1-hop link-scoped >>> IP protocol enhancements. The 1-hop link-scoped protocols >>> include the protocols for route establishment involving ICMP >>> Router Advertisements. The n-hop path management protocols >>> include n-hop path establishment protocols (e.g. Babel, OSPF) and >>> n-hop path search protocols (most notably AODV and derivates). >>> >>> In this proposed Working Group the focus is on 1-hop protocols, >>> and leverage from other Working Groups for the n-hop situations. >>> >>> In some of the moving network applications the window of >>> opportunity for exchanging data with the immediate infrastructure >>> may be very short. For example, a car driving near a road-side >>> unit may have only 5s to exchange with that RSU (depending on >>> speed, RSU range and number). (ephemeral connections). >>> >>> What kind of requirements? -------------------------- The >>> requirements for mechanisms for moving network to nearby moving >>> network communications are focusing on low delays of the data >>> paths, reduced number of messages for path establishment, >>> application friendly, resilience to attacks, compatibility with >>> DHCP and Mobile IP. >>> >>> In addition, some moving network to nearby moving network >>> applications involve IP multicast mechanisms (e.g. virtual >>> siren); thus C-ACC the 1-hop IP moving network to nearby moving >>> netowrk mechanisms will need to gracefully support IP multicast. >>> >>> Due to the inherent characteristics of safety-related >>> communications, all new moving network to nearby moving network >>> mechanisms must afford authenticity and confidentiality where >>> necessary. Dynamically establishing ephemeral communication >>> paths between automobiles in public areas must offer privacy >>> safeguards for the end users (passengers). >>> >>> Establishing 1-hop IP V2V paths must not break the existing >>> on-board protocols and applications which communicate with the >>> Internet, possibly via multiple radios. >>> >>> In a moving network deployed in an automobile, typically one >>> exit point connects the moving network to other moving networks. >>> However, in a more general manner (and to support reliability) >>> any new mechanism of moving network to nearby moving network >>> communications should support multi-homing: one router to use >>> multiple interfaces towards outside the moving network, or >>> multiple routers. >>> >>> Current version of Internet protocols >>> ------------------------------------- The group will only work on >>> IPv6 solutions. >>> >>> What SDOs may need this work? ----------------------------- The >>> requirements and standards for moving network to nearby moving >>> network communications, often involving IPv6, and novel V2V and >>> V2Infra concepts, are developed mainly at ISO TC204 "Intelligent >>> Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For >>> Vehicle-to-Internet communications, 3GPP LTE and other cellular >>> technologies represent the long-range connectivity method; for >>> Vehicle-to-Vehicle communications, LTE Direct is currently >>> specified, as well as OCB mode of IEEE 802.11. Several use-cases >>> exhibit a need for IPv6 data exchanges between vehicles: ETSI's >>> Cooperative Adaptive Cruise Control and Platooning. The IEEE >>> developed a popular link for short-range communications - IEEE >>> 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V >>> communications. >>> >>> Work Items ---------- - use-cases for moving network to nearby >>> moving network communications - Problem Statement for moving >>> network to nearby moving network communications including V2V, >>> V2I and DNS. - Security and Privacy Requirements for moving >>> network to nearby moving network communications - Solutions, >>> which might include new protocols or extensions to existing >>> protocols. With MIB. - IPv6-over foo, where foo is pertinent for >>> moving network to nearby moving network communications (e.g. >>> 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in >>> the V2V domain, identifying which uses IP. >>> >>> Timeline -------- - >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>> >>> >>> -- >>> >>> =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. >>> Assistant Professor Department of Software Sungkyunkwan >>> University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>> , pauljeong@skku.edu >>> Personal Homepage: >>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>> >>> >>> >>> >>> -- >>> >>> =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. >>> Assistant Professor Department of Software Sungkyunkwan >>> University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>> , pauljeong@skku.edu >>> Personal Homepage: >>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>> >>> >> >> _______________________________________________ its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> From nobody Fri Apr 22 05:12:14 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADCB12EB30 for ; Fri, 22 Apr 2016 05:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRmtEocVKAU8 for ; Fri, 22 Apr 2016 05:12:11 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A5D12EB2B for ; Fri, 22 Apr 2016 05:12:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3MCC8YT025235 for ; Fri, 22 Apr 2016 14:12:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5ECCC2062CD for ; Fri, 22 Apr 2016 14:13:40 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 55885204907 for ; Fri, 22 Apr 2016 14:13:40 +0200 (CEST) Received: from [132.166.84.252] ([132.166.84.252]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3MCC7uk019044 for ; Fri, 22 Apr 2016 14:12:08 +0200 To: "its@ietf.org" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <4F249A9B9BE3463A89F7608549FBA84C@SRA4> <571A119A.3010701@gmail.com> From: Alexandre Petrescu Message-ID: <571A1517.9060901@gmail.com> Date: Fri, 22 Apr 2016 14:12:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <571A119A.3010701@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 12:12:13 -0000 ITSers, This is the latest charter text. Yours, Alex ----------------------------------------------------------------- Intelligent Transportation Systems (its) Chairs: Russ Housley Carlos Pignataro Assigned Area Director: Suresh Krishnan Mailing list Address: its@ietf.org 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 based on data exchanges, 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) communications are still being developed. Some vehicle communications will not use IP, including safety messages with other vehicles and infrastructure. Other vehicle communications will be IP-based protocols, especially when multiple applications need to share one data link. 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. The group is concerned with situations involving moving network to nearby moving (or fixed) network communications (V2V, V2I, I2V). For example: a moving network in a vehicle communicating to another moving network in a nearby vehicle (C-ACC, Platooning, or temporarily fixed at an incident scene); a personal area network carried by a user and connecting to an in-house fixed network (homenet); an in-car networked device receiving messages from a road-side display when passing by, wagon-to-wagon range extension in a train; train-to-intersection signalling. In these loop-free 1-IP-hop topologies there is a problem of establishing IP paths quickly and reliably. Improved safety is an immediate result of hyper-connectivity of vehicles; as such public authorities worldwide are increasingly mandating secure communication technology requirements in vehicles. Emergency applications for instrumented ambulances carry many benefits both to the users and to society in general. For these reasons, a solution to the problem of establishing IP paths between nearby moving networks will be resilient to threats such as eavesdropping. Moving network to nearby moving or fixed network communications may involve several kinds of link layers: 802.11-OCB (Outside the Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ac, 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. 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, including safety messages with other vehicles and infrastructure. If the group is successful in designing a simple 1-IP-hop solution for V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then future extensions for n-IP-hop V2V2I may be considered. Work items 1. "Problem statement for IP in V2V and V2I" including "IP addressing architecture for V2V and V2I" and including "Gap Analysis: IP protocols suited and gaps" and including "Use-cases for IP in V2V and V2I moving network To nearby moving or fixed network" 2. "Threat Analysis for IP prefix exchanges in V2V and V2I Context" 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document, including connectivity in fast and asymmetric conditions, Coverage area vs speed diagrams, below-IP congestion management. 4. "List of papers and _products_ using IP in V2V and V2I" 5. Solution for direct communication between Mobile Routers Goals and milestones Oct 2016 - submit Problem Statement to WG Oct 2016 - submit List of papers and products to WG Feb 2017 - submit Threat Analysis to WG Feb 2017 - submit IP over DSRC (802.11-OCB) to WG Jun 2017 - submit Solution for direction communication between Mobile Routers to WG Oct 2017 - start submitting to IESG From nobody Fri Apr 22 05:53:32 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A07E12E06F for ; Fri, 22 Apr 2016 05:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijM8J-8f7Xvr for ; Fri, 22 Apr 2016 05:53:29 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A92212E849 for ; Fri, 22 Apr 2016 05:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9494; q=dns/txt; s=iport; t=1461329609; x=1462539209; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ylwiejuQwg1nIv9ERCmyv04ZZQV8wTZauCTTRgAZTFA=; b=FR//O0VnbX9LV0r229y4SoVnwJ+mrc3OUo/K+n9pQZ6GJ0AkCla2OaAp nRvlXpw7bALMEK6hnENL+L/jIrN00zsCfD72KoVJJ6kni+TdjsWlg1fho 4ZB7COd/buETkVFPD8/CVsba9qaBQasUwOFVYJ5kh0JH8NPPqygQvnQAD A=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEBQDRHRpX/5BdJa1egmxMgVAGriOGa?= =?us-ascii?q?oUBgXOGDgKBJDkTAQEBAQEBAWUnhEEBAQEDAXkFCwIBCBguIRElAgQOBQ6IBwM?= =?us-ascii?q?KCLosDYRwAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGIYF1CIJOgkGFKYIrBZMeh?= =?us-ascii?q?EAxAYMngWaHEIF2gWaETYhdh1CHXgEiAj6Da2yHeH8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,517,1454976000"; d="asc'?scan'208,217";a="94749411" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Apr 2016 12:53:28 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3MCrSqj015124 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Apr 2016 12:53:28 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 22 Apr 2016 08:53:27 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Fri, 22 Apr 2016 08:53:27 -0400 From: "Carlos Pignataro (cpignata)" To: Alexandre Petrescu Thread-Topic: [its] charter ITS - proposed work items Thread-Index: AQHRlimZ01HYWrPJuEaLnvr14T/6bp+PpeUAgADvTgCAAJr8gIAAYIcAgANQwwCAABJdwYABPp2AgAAQNIA= Date: Fri, 22 Apr 2016 12:53:27 +0000 Message-ID: <3161CED1-16A1-4414-BF6F-CAA4F0FB1CFB@cisco.com> References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <04ae01d199bf$3d2938d0$b77baa70$@ing.uchile.cl> <004b01d19a0c$bb4632c0$31d29840$@eurecom.fr> <57162E84.9030507@gmail.com> <0372E48159F544E89115442BAAD41910@SRA4> <571A112F.5030603@gmail.com> In-Reply-To: <571A112F.5030603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.237.6] Content-Type: multipart/signed; boundary="Apple-Mail=_360FB508-FAE4-47D2-B295-8A8288CFBC6A"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "dickroy@alum.mit.edu" , Russ Housley , "its@ietf.org" Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 12:53:31 -0000 --Apple-Mail=_360FB508-FAE4-47D2-B295-8A8288CFBC6A Content-Type: multipart/alternative; boundary="Apple-Mail=_5BE91F57-D3AC-4B9D-9FD1-481840DA71E6" --Apple-Mail=_5BE91F57-D3AC-4B9D-9FD1-481840DA71E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Apr 22, 2016, at 7:55 AM, Alexandre Petrescu = wrote: >=20 >> I think the we need to declare that as out oaf scope for this effort >> in some place in the charter. If you do not think that is the goals >> section, please suggest another place that makes more sense to you. >=20 > I propose the following paragraph towards the end of the Charter: >=20 I particularly liked the clarification at the top in the relevant = paragraph, and not at the end =97 unless this final sentences is = intended to be a recap. > This group will not work on V2V or V2I use-cases where IP is not = well-suited, including safety messages with other vehicles and = infrastructure. >=20 What is =93well-suited=94? And how is that determined? To me, there=92s two areas to narrow-scope the effort. First, a small = but concrete set of areas like the one in this discussion =97 but not a = broad brush of =91where not well-suited=92; and second, where other SDOs = are working on it. Thanks, Carlos. > Is it ok? >=20 > Alex >=20 >=20 --Apple-Mail=_5BE91F57-D3AC-4B9D-9FD1-481840DA71E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Apr 22, 2016, at 7:55 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

I think the we need to declare that as out oaf scope for this = effort
in some place in the charter.  If you do not = think that is the goals
section, please suggest another = place that makes more sense to you.

I propose the = following paragraph towards the end of the Charter:


I= particularly liked the clarification at the top in the relevant = paragraph, and not at the end =97 unless this final sentences is = intended to be a recap.

This group will not = work on V2V or V2I use-cases where IP is not well-suited, including = safety messages with other vehicles and infrastructure.


What is =93well-suited=94? And how is that = determined?

To me, there=92s two = areas to narrow-scope the effort. First, a small but concrete set of = areas like the one in this discussion =97 but not a broad brush of = =91where not well-suited=92; and second, where other SDOs are working on = it.

Thanks,

Carlos.

Is it = ok?

Alex



= --Apple-Mail=_5BE91F57-D3AC-4B9D-9FD1-481840DA71E6-- --Apple-Mail=_360FB508-FAE4-47D2-B295-8A8288CFBC6A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXGh7HAAoJEIXgpQGOZny9ZaEP/jO2I6J/ewptOb+MKVV/D+Bj c4U3mSW5t6fNqIc/lEEfjJfoUDvXtCIiU1zPZ5o6t2lYYr1LQoe9TwJUqZcNyEp9 3Bcc2y/gMmefTKjlb6O3YOGtqm3lnP/BQmIc3PAmFJPjknCTm/axG5vmSCaolDad mshbIxTLiKY0reRqWttOigdJV9D6S8aGjTCbhx64iGwtCA5XJeiqmpOhmcLqKTug KtcV84UL3qpCmW5pfIf1VvFph7CQ/eTigACcg3Vt4Wyh3Vls40EghQENfWeUOv9j gc5DJFD7xYUCCD0MANEYiKirdWdgmrflD7e/+CgQ48Vs0mrg6JeD70NX8kGR7Ahh 1c0T3eMYVfHTICfvMzgNXPdpALSl44LUwhcEfxumP0jbNKeF1nBHdgWu+6zUp23C 3PikfD/H+xIp9HQ8WYRPTMcahzjxWQGj+amsZZLANKRkycAtsD9JP7uihZNrKa1y hhUm82SU1xeJWma2zuFSho5+o4HXBjjEAy0if4ietskmmWIjcX3CqOZ/jP8ge0YG dzAorNrmtYoIvO2iv1+4ASwN8B9hiYdPS9bcliwGPQlSwNvawF+pCC3wG+MHk/pX lquMM65IpLVuHpLn4w8yORQTNqdrIPxbaIT1+sOducIg/Lasy0U9hZw5V73YRa4K pEoQBgGscN686NMoEqir =0dCD -----END PGP SIGNATURE----- --Apple-Mail=_360FB508-FAE4-47D2-B295-8A8288CFBC6A-- From nobody Mon Apr 25 04:44:15 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21F212D1B1 for ; Mon, 25 Apr 2016 04:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuABTDrHVpzB for ; Mon, 25 Apr 2016 04:44:10 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C56012D0A5 for ; Mon, 25 Apr 2016 04:44:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3PBi4oO028065; Mon, 25 Apr 2016 13:44:04 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AA7DB212939; Mon, 25 Apr 2016 13:45:40 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9AF47212922; Mon, 25 Apr 2016 13:45:40 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3PBi4i8013794; Mon, 25 Apr 2016 13:44:04 +0200 To: dickroy@alum.mit.edu, "'Jong-Hyouk Lee'" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <57148442.4030204@gmail.com> <4F249A9B9BE3463A89F7608549FBA84C@SRA4> <571A119A.3010701@gmail.com> <12746E0EF5FA4EB38F4E79EB3089E089@SRA4> From: Alexandre Petrescu Message-ID: <571E0304.4050804@gmail.com> Date: Mon, 25 Apr 2016 13:44:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <12746E0EF5FA4EB38F4E79EB3089E089@SRA4> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: its@ietf.org Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 11:44:13 -0000 Le 22/04/2016 18:46, Richard Roy a crit : > > >> -----Original Message----- >> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] >> Sent: Friday, April 22, 2016 4:57 AM >> To: dickroy@alum.mit.edu; 'Jong-Hyouk Lee' >> Cc: its@ietf.org >> Subject: Re: [its] charter ITS - proposed work items >> >> Le 22/04/2016 01:53, Richard Roy a crit : >>> I'd like to suggest that the strict focus on ITS may be leading the >>> discussion astray somewhat. ITS is clearly an important use case >>> (and should be highlighted as such in the "reasons for doing this >>> work" document), but IPv6 mobility is generally important in other >>> application areas as well. >> >> I agree. >> >> To that end we may say 'moving network' rather than 'in-vehicle network'. >> >> And we accommodate networks deployed in trains as well: wagon-to-wagon >> IP communications is similar to vehicle-to-vehicle communications. > > [RR>] Since the wagons don't change relative position while in use, networks > in trains are local area networks that change their point of attachment to > WANs at a rate related to their velocity (it's really more like V2I in that > context.) In principle yes, that's more like V2Internet. On another hand: - in some wagons there is a need to avoid add new Ethernet cable between wagons. This leads to use WiFi to inter-connect wagons, in addition to the WiFi given to passengers. That's more of the kind V2V than V2Internet. - on-board networked equipment sending messages when passing at fixed network equipment ("beaconing") can not happen with a V2Internet technique, because of latency. It needs to happen in a more V2V straight manner. My point is that if someone intends to apply the technology developped by this group in train communications one can spot precisely some of the pertinent areas: wireless wagon-to-wagon communications, train to crossroads communications, etc. [..] >> "IP mobility" at IETF may also be understood as the DMM working group >> (Distributed Mobility Management). That deals mainly with >> infrastructure entities, not moving networks. Especially no direct >> links between moving networks in DMM. > > [RR>] Interesting ... sounds like whatever the ITS group does should be > liaised/coordinated with the DMM WG perhaps? Noted: coordinated. Alex > > RR >> >> Alex >> >>> >>> My two cents ... >>> >>> RR >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >> *From:*Jong-Hyouk Lee [mailto:jonghyouk@gmail.com] *Sent:* Monday, >>> April 18, 2016 12:32 AM *To:* Alexandre Petrescu *Cc:* its@ietf.org >>> *Subject:* Re: [its] charter ITS - proposed work items >>> >>> Thx, plz see inline. >>> >>> -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >>> Protocol Engineering Lab., Sangmyung University >>> >>> #email: jonghyouk@gmail.com #webpage: >>> https://sites.google.com/site/hurryon >>> >>>> On Apr 18, 2016, at 3:52 PM, Alexandre Petrescu >>>> >>> > wrote: >>>> >>>> Hi Jong-Hyouk, >>>> >>>> Le 17/04/2016 14:07, Jong-Hyouk Lee a crit : >>>> >>>> Hi Alex >>>> >>>> Just to clarify. -- Jong-Hyouk Lee, living somewhere between >>>> /dev/null and /dev/random Protocol Engineering Lab., Sangmyung >>>> University >>>> >>>> #email: jonghyouk@gmail.com #webpage: >>>> https://sites.google.com/site/hurryon >>>> >>>> >>>> On Apr 14, 2016, at 5:42 PM, Alexandre Petrescu >>>> wrote: >>>> >>>> ITSers, >>>> >>>> We work on a more rigorous ITS charter text. >>>> >>>> Now we propose four work items: >>>> >>>> 1. "Problem statement for IP in V2V and V2I" including "IP >>>> addressing architecture for V2V and V2I" and including "Gap >>>> Analysis: IP protocols suited and gaps" and including "Use-cases >>>> for IP in V2V and V2I moving network to nearby moving or fixed >>>> network" >>>> >>>> >>>> Are you intending to have one document that includes those three >>>> parts? >>>> >>>> >>>> Yes. >>>> >>>> Because we need to reduce the number of items. Because one of the >>>> remarks during BoF was that the scope was too large. >>>> >>> Hum.then, the document will be too broad. We may need people to work >>> on each part. >>> >>>> >>>> >>>>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>>>> context" >>>>> >>>> >>>> Is this mean that this group first go for this and later considers >>>> a general security document (e.g., security requirements for ITS) >>>> ? >>>> >>>> >>>> For now it is "Threat Analysis for IP prefix exchanges in V2V and >>>> V2I context". >>>> >>> Ok. For the document "Threat Analysis of IP prefix exchanges in V2V >>> and V2I", I just started to work on. Soon I will post. >>> >>> >>> >>> >>> "General security requirements for ITS" seems very broad - what do >>> you mean more precisely? >>> >>> We may later need one document describing general security >>> requirements for ITS that corresponds the document "PS for IP in V2V >>> and V2I". We will be later. ;) >>> >>> Good day! >>> >>> >>> >>> >>> Alex >>> >>> >>> >>> Cheers. >>> >>> >>> >>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*], >>> including connectivity in fast and asymmetric conditions, coverage >>> area vs speed diagrams, below-IP congestion management. >>> >>> 4. "List of papers and _products_ using IP in V2V and V2I" >>> >>> What do you think? >>> >>> Please respond by next Monday, April 18th. >>> >>> Alex and Dapeng [*] a typical IP-over-foo document is, for example, >>> RFC2464 "Transmission of IPv6 Packets over Ethernet Networks", where >>> "foo" is instantiated as "Ethernet". Other IPv6-over-foo documents >>> are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and more. >>> >>> Le 14/04/2016 09:42, Jrme Hrri a crit : >>> >>> Paul, >>> >>> Thanks. Btw, when I mentioned 'people' are aware of IP V2V but not >>> see the need (so far), I referred to the automotive SDOs (led by >>> automotive industries)., although there are always 'minority >>> reports' J >>> >>> Cheers, >>> >>> Jrme >>> >>> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] >>> *Sent:* Thursday 14 April 2016 09:36 *To:* Jrme Hrri *Cc:* >>> Alexandre Petrescu; its@ietf.org *Subject:* Re: >>> [its] charter ITS >>> >>> Jrme, >>> >>> I missed that you are also an academic person. >>> >>> I got it :-) >>> >>> I understand your points for industry activity related to vehicular >>> networking. >>> >>> Your observation seems true. >>> >>> BTW, I will invite you to my team for the draft for a list of >>> academic papers for V2V and V2I >>> >>> by a personal message. >>> >>> Thanks. >>> >>> Paul >>> >>> On Thu, Apr 14, 2016 at 4:09 PM, Jrme Hrri >>> >>> > wrote: >>> >>> Hi Paul, >>> >>> Thanks for your feedback. Do not get me wrong, I am an academic and >>> with my team, we also work on IP-based V2V and V2I, in particular >>> related to mobility management with DMM, but also in the context of >>> vehicular IoT. >>> >>> I just have the feeling that people are perfectly aware of the fact >>> that IP _can_ be used for V2V and V2I, but does not '_need_' to be >>> used as other solutions already perfectly fit their need. Listing >>> papers will not change this awareness. >>> >>> So, as a complement to academic papers, it would help to be able to >>> pin-point which industrial activities are using or are strongly >>> planning (short term I mean) to use pure IPv6 system in vehicles. >>> >>> My feeling here is we have a different eco-system that the >>> Automotive industry (and automotive industry-related SDO)..more >>> likely the IoT industry.and as such, we should not need to have the >>> (direct) involvement of automotive industry in the Charter. If we can >>> make this clear by an industry-based 'survey', that would help make >>> the case for the WG. >>> >>> Btw, you can count on me your draft..we can add some IP-based V2V >>> and V2I for mobility management and also IoT. >>> >>> Cheers, >>> >>> Jrme >>> >>> *From:*Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com >>> ] *Sent:* Thursday 14 April 2016 >>> 03:22 *To:* Jrme Hrri *Cc:* Alexandre Petrescu; its@ietf.org >>> *Subject:* Re: [its] >>> charter ITS >>> >>> Hi Jrme, >>> >>> I have an opinion on your comment 5) below. >>> >>> I think that a list of high-quality papers about IP-based V2V and >>> V2I >>> >>> can teach very useful lessons to software designers of IP in V2V and >>> V2I >>> >>> in the industry. >>> >>> Multiple people are working for this IP-based V2V and V2I >>> >>> (including Sandra Cespedes and me) in academia and >>> >>> more people(including Nabil Benamar) are willing to work for this >>> area. >>> >>> I think we need to utilize the list of such papers as the ground for >>> our ITS group >>> >>> through a WI. Note that the draft of the list will include the >>> summary of the main >>> >>> ideas of the papers. >>> >>> For the industry current activities for this area, I believe that >>> you can share them >>> >>> as references through our ITS mailing list rather than through a WI. >>> >>> Could you join my team that are making efforts for a list of such >>> papers? >>> >>> Thanks. >>> >>> Best Regards, >>> >>> Paul >>> >>> On Thu, Apr 7, 2016 at 8:11 AM, Jrme Hrri >>> >>> > wrote: >>> >>> Dear ITSers, Dear Alex, >>> >>> Here are some comments on the updated charter: >>> >>> 1)Can we keep a reference to IEEE 802.11p, considering it does not >>> exist anymore? It is now fully integrated into IEEE 802.11-2012 as >>> OCB mode (and 10Mhz @5.9Ghz) of course. >>> >>> 2)Should we really keep C-ACC (or Platooning) in the charter >>> explicitly as use case, considering it is a seriously controversial >>> aspect with some SDOs (ex. In Automotive SDOs)? In the ISO >>> presentation, Thierry mentions traffic efficiency/infotainment >>> applications, such as in-signage applications... >>> >>> a.We might have to aim at less controversial use cases to attract >>> automotive industries >>> >>> 3)One potential WI I could think of (rather a basic one): >>> _definition of a vehicular wireless 'link' in an automotive context_ >>> >>> a.To me, this is a fundamental brick in the larger IETF WG ITS >>> house.. >>> >>> 4)I would suggest to be more explicit in the foreseen challenges of >>> this WG, instead of mentioning general use case (which end up be >>> controversial) >>> >>> a.Example: maintaining IPv6 connectivity in fast and asymmetric >>> wireless links; also under quickly changing topologies (actually >>> suggested by Dick Roy on the chat room) >>> >>> b.Example: IPv6 addressing in link-local scope.. >>> >>> c.Example: guaranteeing privacy in IPv6 moving networks etc.. >>> >>> 5)Before listing academic papers referring to IPv6 in vehicles, I >>> would suggest to first try to list commercial products/solutions >>> that are in vehicles and are using IPv6, possibly suffering from a >>> silo limitations (ex. restricted to a single technology, single use >>> case.) >>> >>> a.I think we need to get to products first, before academic visions >>> >>> My two cents.. >>> >>> Best Regards, >>> >>> Jrme >>> >>> *From:*its [mailto:its-bounces@ietf.org >>> ] *On Behalf Of *Alexandre Petrescu >>> *Sent:* Wednesday 06 April 2016 23:45 *To:* its@ietf.org >>> *Subject:* [its] charter >>> ITS >>> >>> ITSers, >>> >>> Please see below the current charter. >>> >>> - the two Problem Statements drafts V2V and V2I joined, so there is >>> less text in charter. - added an Item on "List of Research >>> papers..." >>> >>> Erik: did I understand you correctly that there should be some item >>> on discussing whether link-local addressing is sufficient, whether >>> prefix exchange is necessary? >>> >>> Dino: should LISP be included in the gap analysis draft which >>> includes C-ACC use-case? OR should we separate a dedicated I-D only >>> with gap analysis including ND, MIP, AODVv2, LISP? >>> >>> Person from mediatek: is the 'zeroconf' need in the >>> vehicle-to-vehicle interface illustrated good enough by the words >>> "moving network to nearby moving network communications"? Or is it >>> better to say "the 1-IP-hop between nearby moving networks must be >>> self-configured"? >>> >>> Nabil, Sandra: is it ok to have a working group item "List of >>> Research Papers for IP in V2V and V2I communications"? >>> >>> Other comments? >>> >>> Alex >>> >>> ------------------------------------------------------------------ >>> >>> >>> ITS (name to change) >>> >>>>> Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> Intelligent Transportation Systems (its) >>>>> ---------------------------------------- Current Status: WG >>>>> forming >>>>> >>>>> Chairs: TBD >>>>> >>>>> Assigned Area Director: TBD >>>>> >>>>> Mailing list Address: its@ietf.org >>>>> 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: >>>>> >>>>> Goal ---- The goal of this group is to standardize IP-based >>>>> protocols for establishing direct and secure connectivity between >>>>> moving networks, some of which could be fixed permanently or >>>>> temporarily. >>>>> >>>>> Moving Network to Nearby Moving Network Communications >>>>> ------------------------------------------------------ The group >>>>> is concerned with all situations involving moving network to >>>>> nearby moving network communications. For example: >>>>> vehicle-to-vehicle communications, nomadic user wearing a PAN and >>>>> communicating to a homenet, vehicle-to-infrastructure >>>>> communications, wagon-to-wagon in a train, or >>>>> train-to-intersection signalling. >>>>> >>>>> Example from the automobile communications space >>>>> ------------------------------------------------ Automobiles and >>>>> vehicles of all types are increasingly connected to the >>>>> Internet, either as vehicle-to-vehicle, vehicle-to-infra or >>>>> vehicle-to-Internet. Entertainment apps enhancing comfort, >>>>> reliable data exchanges for road safety, and automated driving >>>>> are features coming in automobiles to hit the roads from now to >>>>> year 2020. Highlighting increased safety as an immediate result >>>>> of hyper-connectivity applied to vehicles, public authorities >>>>> worldwide are increasingly mandating secure communication >>>>> technology requirements in vehicles. >>>>> >>>>> Emergency apps for new instrumented ambulances carry many >>>>> benefits both to the users and to society in general. >>>>> >>>>> Why IP? ------- Today, there are several deployed >>>>> Vehicle-to-Internet technologies, including car tethering through >>>>> driver's cellular smartphone. However, Vehicle-to-Vehicle and >>>>> Vehicle-to-Infrastructure communications are still being >>>>> developed. To improve on a situation of link-specific data >>>>> exchanges, and enable independent application sets to share the >>>>> same links, IP data exchanges are needed. Enabling IP >>>>> communication between vehicles (V2V), and between vehicles and >>>>> the immediate infrastructure (V2I), will provide (0) ability to >>>>> reach the rest of the world on the Internet (1) short and >>>>> deterministic delays, (2) fast forwarding through scalable paths >>>>> of routers, (3) ease of reuse of existing Internet applications >>>>> in a vehicular environment. >>>>> >>>>> Moving network to nearby moving network communications involve >>>>> link layers such as: 802.11p OCB (Outside the Context of a Basic >>>>> Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible >>>>> Light Communications), IrDA, LTE-D. Only the IP protocols are >>>>> capable of running on each of these links and establish IP paths >>>>> across them in an interoperable manner. >>>>> >>>>> Scenarios? ---------- There are a few scenarios exhibiting the >>>>> need to communicate from one moving network to another nearby >>>>> moving network. >>>>> >>>>> In the automobile space, the Cooperative Adaptive Cruise Control >>>>> and Platooning features consider that vehicles close to each >>>>> other exchange data describing their kinematic status. At the >>>>> cross-roads, the moving network inside a vehicle exchanges data >>>>> with the moving network in the red-light pole. >>>>> >>>>> Several public safety scenarios involve moving networks. >>>>> Distinct organizations deploy different moving networks >>>>> (in-vehicle, on-person) at an incident scene. These networks >>>>> need to interoperate in order to more effectively understand and >>>>> deal with the incident scene. >>>>> >>>>> In connected rail scenarios the moving network deployed in >>>>> trains communicate with other moving networks at the >>>>> cross-points. >>>>> >>>>> What kind of solutions? ----------------------- The current >>>>> technical solutions considered to achieve moving network to >>>>> nearby moving network communications are of two kinds: IP >>>>> routing protocols for n-hop path management and 1-hop link-scoped >>>>> IP protocol enhancements. The 1-hop link-scoped protocols >>>>> include the protocols for route establishment involving ICMP >>>>> Router Advertisements. The n-hop path management protocols >>>>> include n-hop path establishment protocols (e.g. Babel, OSPF) and >>>>> n-hop path search protocols (most notably AODV and derivates). >>>>> >>>>> In this proposed Working Group the focus is on 1-hop protocols, >>>>> and leverage from other Working Groups for the n-hop situations. >>>>> >>>>> In some of the moving network applications the window of >>>>> opportunity for exchanging data with the immediate infrastructure >>>>> may be very short. For example, a car driving near a road-side >>>>> unit may have only 5s to exchange with that RSU (depending on >>>>> speed, RSU range and number). (ephemeral connections). >>>>> >>>>> What kind of requirements? -------------------------- The >>>>> requirements for mechanisms for moving network to nearby moving >>>>> network communications are focusing on low delays of the data >>>>> paths, reduced number of messages for path establishment, >>>>> application friendly, resilience to attacks, compatibility with >>>>> DHCP and Mobile IP. >>>>> >>>>> In addition, some moving network to nearby moving network >>>>> applications involve IP multicast mechanisms (e.g. virtual >>>>> siren); thus C-ACC the 1-hop IP moving network to nearby moving >>>>> netowrk mechanisms will need to gracefully support IP multicast. >>>>> >>>>> Due to the inherent characteristics of safety-related >>>>> communications, all new moving network to nearby moving network >>>>> mechanisms must afford authenticity and confidentiality where >>>>> necessary. Dynamically establishing ephemeral communication >>>>> paths between automobiles in public areas must offer privacy >>>>> safeguards for the end users (passengers). >>>>> >>>>> Establishing 1-hop IP V2V paths must not break the existing >>>>> on-board protocols and applications which communicate with the >>>>> Internet, possibly via multiple radios. >>>>> >>>>> In a moving network deployed in an automobile, typically one >>>>> exit point connects the moving network to other moving networks. >>>>> However, in a more general manner (and to support reliability) >>>>> any new mechanism of moving network to nearby moving network >>>>> communications should support multi-homing: one router to use >>>>> multiple interfaces towards outside the moving network, or >>>>> multiple routers. >>>>> >>>>> Current version of Internet protocols >>>>> ------------------------------------- The group will only work on >>>>> IPv6 solutions. >>>>> >>>>> What SDOs may need this work? ----------------------------- The >>>>> requirements and standards for moving network to nearby moving >>>>> network communications, often involving IPv6, and novel V2V and >>>>> V2Infra concepts, are developed mainly at ISO TC204 "Intelligent >>>>> Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For >>>>> Vehicle-to-Internet communications, 3GPP LTE and other cellular >>>>> technologies represent the long-range connectivity method; for >>>>> Vehicle-to-Vehicle communications, LTE Direct is currently >>>>> specified, as well as OCB mode of IEEE 802.11. Several use-cases >>>>> exhibit a need for IPv6 data exchanges between vehicles: ETSI's >>>>> Cooperative Adaptive Cruise Control and Platooning. The IEEE >>>>> developed a popular link for short-range communications - IEEE >>>>> 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V >>>>> communications. >>>>> >>>>> Work Items ---------- - use-cases for moving network to nearby >>>>> moving network communications - Problem Statement for moving >>>>> network to nearby moving network communications including V2V, >>>>> V2I and DNS. - Security and Privacy Requirements for moving >>>>> network to nearby moving network communications - Solutions, >>>>> which might include new protocols or extensions to existing >>>>> protocols. With MIB. - IPv6-over foo, where foo is pertinent for >>>>> moving network to nearby moving network communications (e.g. >>>>> 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in >>>>> the V2V domain, identifying which uses IP. >>>>> >>>>> Timeline -------- - >>>>> >>>>> >>>>> _______________________________________________ its mailing list >>>>> its@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. >>>>> Assistant Professor Department of Software Sungkyunkwan >>>>> University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>>>> , pauljeong@skku.edu >>>>> Personal Homepage: >>>>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. >>>>> Assistant Professor Department of Software Sungkyunkwan >>>>> University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com >>>>> , pauljeong@skku.edu >>>>> Personal Homepage: >>>>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>> >>>>> >>>> >>>> _______________________________________________ its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>>> > > From nobody Mon Apr 25 04:52:34 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23AC12D0A5 for ; Mon, 25 Apr 2016 04:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJImxargfDYW for ; Mon, 25 Apr 2016 04:52:31 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FC512D15B for ; Mon, 25 Apr 2016 04:52:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3PBqRv4031279; Mon, 25 Apr 2016 13:52:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0FE3A212874; Mon, 25 Apr 2016 13:54:03 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 01F5220165D; Mon, 25 Apr 2016 13:54:03 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3PBqQGf020648; Mon, 25 Apr 2016 13:52:27 +0200 To: dickroy@alum.mit.edu, "'Russ Housley'" References: <57058375.6050101@gmail.com> <009301d19059$96917820$c3b46860$@eurecom.fr> <009501d1961c$9c5127b0$d4f37710$@eurecom.fr> <00eb01d19621$430b0d60$c9212820$@eurecom.fr> <570F57EB.4060606@gmail.com> <04ae01d199bf$3d2938d0$b77baa70$@ing.uchile.cl> <004b01d19a0c$bb4632c0$31d29840$@eurecom.fr> <57162E84.9030507@gmail.com> <0372E48159F544E89115442BAAD41910@SRA4> <571A112F.5030603@gmail.com> <7DC116554CA44B96AA1A18544763EFE1@SRA4> From: Alexandre Petrescu Message-ID: <571E04FA.2070904@gmail.com> Date: Mon, 25 Apr 2016 13:52:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7DC116554CA44B96AA1A18544763EFE1@SRA4> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: its@ietf.org Subject: Re: [its] charter ITS - proposed work items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 11:52:33 -0000 Le 22/04/2016 18:38, Richard Roy a crit : > If you want to add something like: > > " This group will not work on V2V or V2I use-cases where IP is not > well-suited, including safety messages with other vehicles and > infrastructure." > > might I suggest: > > "This group will work on V2V and V2I use-cases where IP is > well-suited as a networking technology, including applications involving > exchange of safety-related messages with other vehicles and > infrastructure where use of IP is advantageous." > > No need to be negative. Stating all the things the project will NOT do > would be a "never-ending story" and is really not useful. Noted, included. (without being negative, it's good in a charter and in documents to state what it does _and_ what it does not) Alex > > RR > >> -----Original Message----- >> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] >> Sent: Friday, April 22, 2016 4:55 AM >> To: Russ Housley; dickroy@alum.mit.edu >> Cc: its@ietf.org >> Subject: Re: [its] charter ITS - proposed work items >> >> >> >> Le 21/04/2016 22:54, Russ Housley a crit : >>> Richard: >>> >>>> >>>>> >>>>>> You ask whether the draft proposes IPv6 mainly for >>>>>> safety-criticial apps: no, the current text uses other >>>>>> motivators for IPv6. >>>>> >>>>> I think that the answer to this question belongs in an update to >>>>> the Goals in the draft charter text. >>>>> >>>>> At the BOF, I heard several people point out that there are many >>>>> safety communications that will not use IPv6. The charter text >>>>> needs to recognize this situation by saying that those single-hop >>>>> V2V and V2I communications are out of scope for this effort. >>>>> After all, those are being standardized elsewhere, and this >>>>> effort should not overlap with them. >>>>> >>>>> The current draft charter says that the goal of this effort is >>>>> to: >>>>> >>>>> The goal of this group is to standardize IP-based protocols for >>>>> establishing direct and secure connectivity between moving >>>>> networks, some of which could be fixed permanently or >>>>> temporarily. >>>> >>>> [RR>] Fair enough, however to indicate that a "moving network" is >>>> "fixed permanently" begs the question of the definition of a >>>> "moving network":^)) That is: How can a "moving network" be >>>> "permanently fixed"??? >>> >>> I think that the text proposed below resolves this point you raise. >>> >>>>> I throw this out to start discussion: >>>>> >>>>> Some vehicle communications will not use IP, including safety >>>>> messages with other vehicles and infrastructure. Other vehicle >>>>> communications will be IP-based protocols, especially when >>>>> multiple applications need to share one data link. This group >>>>> will develop IP-based protocols to establish direct and secure >>>>> connectivity between a vehicle, which are 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. >>>>> >>>>> Russ >>>> >>>> [RR>] Perhaps it would make sense just to focus on those use cases >>>> where IP has value and simply ignore those where it may not be >>>> used. By mentioning applications and services to which IP is not >>>> well-suited just confuses people without adding any value to the >>>> discussion or the effort. Also, I believe in several places above >>>> where there is reference to communication life-times what is really >>>> meant is "communication session" life-times and "session (layer) >>>> continuity using IP networking". >>> >>> I think the we need to declare that as out oaf scope for this effort >>> in some place in the charter. If you do not think that is the goals >>> section, please suggest another place that makes more sense to you. >> >> I propose the following paragraph towards the end of the Charter: >> >> This group will not work on V2V or V2I use-cases where IP is not >> well-suited, including safety messages with other vehicles and >> infrastructure. >> >> Is it ok? >> >> Alex >> >>> >>> Russ >>> >>> > > From nobody Mon Apr 25 05:01:09 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47D712D197 for ; Mon, 25 Apr 2016 05:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGd4B4oPiVus for ; Mon, 25 Apr 2016 05:01:06 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1694E12D15B for ; Mon, 25 Apr 2016 05:01:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3PC14hk002220 for ; Mon, 25 Apr 2016 14:01:04 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1A3832129A7 for ; Mon, 25 Apr 2016 14:02:40 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0ECA9212990 for ; Mon, 25 Apr 2016 14:02:40 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3PC13tZ026950 for ; Mon, 25 Apr 2016 14:01:04 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: <571E06FF.9060404@gmail.com> Date: Mon, 25 Apr 2016 14:01:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020403030202070401000005" Archived-At: Subject: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 12:01:09 -0000 This is a multi-part message in MIME format. --------------020403030202070401000005 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit ITSers, You will find below the latest charter text. It includes changes issued from discussions with Dick. Alex -------------------------------------------------------------------- Intelligent Transportation Systems (its) Chairs: Russ Housley Carlos Pignataro Assigned Area Director: Suresh Krishnan Mailing list Address: its@ietf.org 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 based on 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. In general, this group is concerned with situations involving moving network to nearby moving, or fixed, network communications (V2V, V2I, I2V). For example: a moving network in a vehicle communicating to another moving network in a nearby vehicle (for C-ACC, Platooning, or at an incident scene); a personal area network carried by a user and connecting to an in-house fixed network (homenet); an in-car networked device receiving messages from a road-side display when passing by, wagon-to-wagon range extension in a train; train-to-intersection signalling. In these loop-free 1-IP-hop topologies there is a problem of establishing IP paths quickly and reliably. Improved safety is an immediate result of hyper-connectivity of vehicles; as such public authorities worldwide are increasingly mandating secure communication technology requirements in vehicles. Emergency applications for instrumented ambulances carry many benefits both to the users and to society in general. For these reasons, a solution to the problem of establishing IP paths between nearby moving networks will be resilient to threats such as eavesdropping. 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. 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. If the group is successful in designing a simple 1-IP-hop solution for V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then future extensions for n-IP-hop V2V2I may be considered. Work items 1. "Problem statement for IP in V2V and V2I" including "IP addressing architecture for V2V and V2I" and including "Gap Analysis: IP protocols suited and gaps" and including "Use-cases for IP in V2V and V2I moving network To nearby moving or fixed network" 2. "Threat Analysis for IP prefix exchanges in V2V and V2I Context" 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document, including connectivity in fast and asymmetric conditions, Coverage area vs speed diagrams, below-IP congestion management. 4. "List of papers and _products_ using IP in V2V and V2I" 5. "Solution for direct communication between moving networks" Goals and milestones Oct 2016 - submit “Problem Statement” to WG Oct 2016 - submit “List of papers and products” to WG Feb 2017 - submit “Threat Analysis” to WG Feb 2017 - submit “IP over DSRC (802.11-OCB)” to WG Jun 2017 - submit “Solution for direction communication between moving networks” to WG Oct 2017 - start submitting to IESG --------------020403030202070401000005 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit ITSers,

You will find below the latest charter text.

It includes changes issued from discussions with Dick.

Alex
--------------------------------------------------------------------
Intelligent Transportation Systems (its)

Chairs:
   Russ Housley
   Carlos Pignataro

Assigned Area Director:
   Suresh Krishnan

Mailing list
   Address: its@ietf.org
   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 based on 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.

In general, this group is concerned with situations involving moving
network to nearby moving, or fixed, network communications (V2V, V2I,
I2V).  For example: a moving network in a vehicle communicating to
another moving network in a nearby vehicle (for C-ACC, Platooning, or
at an incident scene); a personal area network carried by a user and
connecting to an in-house fixed network (homenet); an in-car networked
device receiving messages from a road-side display when passing by,
wagon-to-wagon range extension in a train; train-to-intersection
signalling.  In these loop-free 1-IP-hop topologies there is a problem
of establishing IP paths quickly and reliably.

Improved safety is an immediate result of hyper-connectivity of
vehicles; as such public authorities worldwide are increasingly
mandating secure communication technology requirements in vehicles.
Emergency applications for instrumented ambulances carry many benefits
both to the users and to society in general.  For these reasons, a
solution to the problem of establishing IP paths between nearby moving
networks will be resilient to threats such as eavesdropping.

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.

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.

If the group is successful in designing a simple 1-IP-hop solution for
V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then
future extensions for n-IP-hop V2V2I may be considered.

Work items
1. "Problem statement for IP in V2V and V2I"
   including "IP addressing architecture for V2V and V2I"
   and including "Gap Analysis: IP protocols suited and gaps"
   and including "Use-cases for IP in V2V and V2I moving network
   To nearby moving or fixed network"

2. "Threat Analysis for IP prefix exchanges in V2V and V2I
   Context"

3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document,
   including connectivity in fast and asymmetric conditions,
   Coverage area vs speed diagrams, below-IP congestion
   management.

4. "List of papers and _products_ using IP in V2V and V2I"

5. "Solution for direct communication between moving networks"

Goals and milestones
Oct 2016 - submit “Problem Statement” to WG
Oct 2016 - submit “List of papers and products” to WG
Feb 2017 - submit “Threat Analysis” to WG
Feb 2017 - submit “IP over DSRC (802.11-OCB)” to WG
Jun 2017 - submit “Solution for direction communication between
                   moving networks” to WG
Oct 2017 - start submitting to IESG

 --------------020403030202070401000005-- From nobody Mon Apr 25 05:45:16 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E23312D1DF for ; Mon, 25 Apr 2016 05:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6blZ9bA6CTg for ; Mon, 25 Apr 2016 05:45:12 -0700 (PDT) Received: from mail-pa0-x243.google.com (mail-pa0-x243.google.com [IPv6:2607:f8b0:400e:c03::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAAD12D59D for ; Mon, 25 Apr 2016 05:45:12 -0700 (PDT) Received: by mail-pa0-x243.google.com with SMTP id zy2so18042731pac.2 for ; Mon, 25 Apr 2016 05:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=xmVzbaxg456RYAFodiQs61qq9heh0+2EXxQ/cTWRBMM=; b=yN+pUm5wvNXT28dxdehdjg+zaqq67KQGHSiQvSRy2t6LReq6hBXi4kfO2alTmZ3G/y gS4hC4TGzH3AIpHll6qIy7/3/CuW/ncEspXLdISpt3rLQqRVmyAmgcc18Y+dT+QWoRfO 5KNCL/44J9JUbZiraG8VsbCSJZDMCdbN7ALj5x8NXAKAf/6QZVLdKqdjlalANRV18joP Yl4nEMLz98PoYXTWRPM3EOYoE/e5RpLJQH47wxOGMQCcvGnZtUdrfGDkdwh/mrwsHQIA mTJEbHa6jAPvax6p1pMOKlkUSS0biD/dTRs5HnFT0dxE1QwTS4jl0wIgSkJeXxO5be/3 cCDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=xmVzbaxg456RYAFodiQs61qq9heh0+2EXxQ/cTWRBMM=; b=HGu0K31kcrAMadDoUyGYkc4/zj0GHmSYRCSiehHjeBKvMfykOW00xRuMNbpVwBTgQH IaFLlyaeaDrc1+nTmO/6EiQi2LM8p20047g5tUuVGjSWdl6yfrE/qwCHml2teuTnX/A0 W04+Tqkep1UnHlsWQkKFNDAYZd8YYPMLTsBwGLzGK1LKp+SCCFpOkROOsZAOYe/cMyGb l+o5ikliYtHBO0uMygx5IlwL/0n46KzarMh7B3y4vqaZo+ZscgG27OAWIDRdgjlHDYN0 7Kl3/QafZO79bxcZCCPQGfHk/4NC17UaOkgYcjm4F5Ef9Z4aEO5/pAkY00K/QvGByazK R46g== X-Gm-Message-State: AOPr4FVijsS9IdM5Lht7Q4/fNmcLvIE7nZ5E8hgetJGgTn7nGOzc4xRR0hivCsQ0YrjFcQ== X-Received: by 10.66.232.226 with SMTP id tr2mr48594136pac.44.1461588311651; Mon, 25 Apr 2016 05:45:11 -0700 (PDT) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id v75sm18592083pfa.94.2016.04.25.05.45.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Apr 2016 05:45:10 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_E2B5E9E4-9AE4-426A-8E83-204C20724F70" From: Jong-Hyouk Lee In-Reply-To: <571E06FF.9060404@gmail.com> Date: Mon, 25 Apr 2016 21:45:01 +0900 Message-Id: <49C8475F-8C77-4272-B227-CAF681B066F4@gmail.com> References: <571E06FF.9060404@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 12:45:14 -0000 --Apple-Mail=_E2B5E9E4-9AE4-426A-8E83-204C20724F70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alex, As the work item =E2=80=9CSolution for direction communication between = moving networks=E2=80=9D is one of explicit requests from ISO TC204, it = is better to put the work item on a priority. J.=20 -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 25, 2016, at 9:01 PM, Alexandre Petrescu = wrote: >=20 > ITSers, >=20 > You will find below the latest charter text. >=20 > It includes changes issued from discussions with Dick. >=20 > Alex > -------------------------------------------------------------------- > Intelligent Transportation Systems (its) >=20 > Chairs: > Russ Housley > Carlos Pignataro >=20 > Assigned Area Director: > Suresh Krishnan >=20 > Mailing list > Address: its@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/its = > Archive: > http://www.ietf.org/mail-archive/web/its/current/maillist.html = >=20 > Additional web page > TBD >=20 > Charter >=20 > Automobiles and vehicles of all types are increasingly connected to > the Internet. Comfort-enhancing entertainment applications, road > safety applications based on 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > In general, this group is concerned with situations involving moving > network to nearby moving, or fixed, network communications (V2V, V2I, > I2V). For example: a moving network in a vehicle communicating to > another moving network in a nearby vehicle (for C-ACC, Platooning, or > at an incident scene); a personal area network carried by a user and > connecting to an in-house fixed network (homenet); an in-car networked > device receiving messages from a road-side display when passing by, > wagon-to-wagon range extension in a train; train-to-intersection > signalling. In these loop-free 1-IP-hop topologies there is a problem > of establishing IP paths quickly and reliably. >=20 > Improved safety is an immediate result of hyper-connectivity of > vehicles; as such public authorities worldwide are increasingly > mandating secure communication technology requirements in vehicles. > Emergency applications for instrumented ambulances carry many benefits > both to the users and to society in general. For these reasons, a > solution to the problem of establishing IP paths between nearby moving > networks will be resilient to threats such as eavesdropping. >=20 > 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. >=20 > The group will only work on IPv6 solutions. >=20 > 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. >=20 > The SDOs interested in this work are: ISO/TC204, ETSI TC ITS, 3GPP, > NHTSA and more. >=20 > This group will not work on V2V or V2I use-cases where IP is not > well-suited. >=20 > If the group is successful in designing a simple 1-IP-hop solution for > V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then > future extensions for n-IP-hop V2V2I may be considered. >=20 > Work items > 1. "Problem statement for IP in V2V and V2I" > including "IP addressing architecture for V2V and V2I" > and including "Gap Analysis: IP protocols suited and gaps" > and including "Use-cases for IP in V2V and V2I moving network=20 > To nearby moving or fixed network" >=20 > 2. "Threat Analysis for IP prefix exchanges in V2V and V2I=20 > Context" >=20 > 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document, > including connectivity in fast and asymmetric conditions,=20 > Coverage area vs speed diagrams, below-IP congestion=20 > management. >=20 > 4. "List of papers and _products_ using IP in V2V and V2I" >=20 > 5. "Solution for direct communication between moving networks" >=20 > Goals and milestones > Oct 2016 - submit =E2=80=9CProblem Statement=E2=80=9D to WG > Oct 2016 - submit =E2=80=9CList of papers and products=E2=80=9D to WG > Feb 2017 - submit =E2=80=9CThreat Analysis=E2=80=9D to WG > Feb 2017 - submit =E2=80=9CIP over DSRC (802.11-OCB)=E2=80=9D to WG > Jun 2017 - submit =E2=80=9CSolution for direction communication = between > moving networks=E2=80=9D to WG > Oct 2017 - start submitting to IESG >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_E2B5E9E4-9AE4-426A-8E83-204C20724F70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Alex,

As= the work item =E2=80=9CSolution for direction communication = between moving networks=E2=80=9D is one of explicit requests from ISO = TC204, it is better to put the work item on a priority.

J. 
--
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Apr 25, 2016, at 9:01 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

=20 =20
ITSers,

You will find below the latest charter text.

It includes changes issued from discussions with Dick.

Alex
--------------------------------------------------------------------
Intelligent Transportation Systems (its)

Chairs:
   Russ Housley
   Carlos Pignataro

Assigned Area Director:
   Suresh Krishnan

Mailing list
   Address: its@ietf.org
   To Subscribe: https://www.ietf.org/ma= ilman/listinfo/its
   Archive:
   ht= tp://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 based on 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.

In general, this group is concerned with situations involving moving
network to nearby moving, or fixed, network communications (V2V, V2I,
I2V).  For example: a moving network in a vehicle = communicating to
another moving network in a nearby vehicle (for C-ACC, Platooning, or
at an incident scene); a personal area network carried by a user and
connecting to an in-house fixed network (homenet); an in-car networked
device receiving messages from a road-side display when passing by,
wagon-to-wagon range extension in a train; = train-to-intersection
signalling.  In these loop-free 1-IP-hop topologies there is = a problem
of establishing IP paths quickly and reliably.

Improved safety is an immediate result of hyper-connectivity of
vehicles; as such public authorities worldwide are increasingly
mandating secure communication technology requirements in vehicles.
Emergency applications for instrumented ambulances carry many benefits
both to the users and to society in general.  For these = reasons, a
solution to the problem of establishing IP paths between nearby moving
networks will be resilient to threats such as eavesdropping.

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.

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.

If the group is successful in designing a simple 1-IP-hop solution for
V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then
future extensions for n-IP-hop V2V2I may be considered.

Work items
1. "Problem statement for IP in V2V and V2I"
   including "IP addressing architecture for V2V and = V2I"
   and including "Gap Analysis: IP protocols suited and = gaps"
   and including "Use-cases for IP in V2V and V2I moving = network
   To nearby moving or fixed network"

2. "Threat Analysis for IP prefix exchanges in V2V and V2I
   Context"

3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document,
   including connectivity in fast and asymmetric = conditions,
   Coverage area vs speed diagrams, below-IP congestion =
   management.

4. "List of papers and _products_ using IP in V2V and V2I"

5. "Solution for direct communication between moving networks"

Goals and milestones
Oct 2016 - submit =E2=80=9CProblem Statement=E2=80=9D to WG
Oct 2016 - submit =E2=80=9CList of papers and products=E2=80=9D to = WG
Feb 2017 - submit =E2=80=9CThreat Analysis=E2=80=9D to WG
Feb 2017 - submit =E2=80=9CIP over DSRC (802.11-OCB)=E2=80=9D to = WG
Jun 2017 - submit =E2=80=9CSolution for direction communication = between
=             &n= bsp;      moving networks=E2=80=9D to WG
Oct 2017 - start submitting to IESG
_______________________________________________
its = mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

= --Apple-Mail=_E2B5E9E4-9AE4-426A-8E83-204C20724F70-- From nobody Mon Apr 25 05:59:22 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83BC12D5B5 for ; Mon, 25 Apr 2016 05:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTmA-HZrOthx for ; Mon, 25 Apr 2016 05:59:18 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDBC12D1EB for ; Mon, 25 Apr 2016 05:59:18 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E5BD8F2402E for ; Mon, 25 Apr 2016 08:59:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id doCuHF4yyRa5 for ; Mon, 25 Apr 2016 08:43:31 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7A959F2401F for ; Mon, 25 Apr 2016 08:59:17 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> Date: Mon, 25 Apr 2016 08:59:16 -0400 To: its@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 12:59:20 -0000 Carlos and I had a telephone conversation with our Area Director for = this group, Suresh Krishnan. The result of the discussion was some = pretty clear and pragmatic suggestions about the charter. The suggestion is that the ITS WG have only two deliverables in the = initial charter. Once these two documents are delivered to the IESG, = then the group can recharter to tackle other things. An Informational RFC that covers: - What is ITS? =97 Explain V2V, V2I, and so on - Why is IPv6 needed? =97 Explain why some traffic will not use IPv6 =97 Explain why other traffic will use IPv6 - Problem statement - Use-cases - Security considerations - Privacy considerations A Standards-Track RFC that covers: - IPv6 over DSRC Russ= From nobody Mon Apr 25 08:30:24 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1452012D612 for ; Mon, 25 Apr 2016 08:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.186 X-Spam-Level: X-Spam-Status: No, score=-5.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcZEj_CS6EOl for ; Mon, 25 Apr 2016 08:30:19 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9379112D603 for ; Mon, 25 Apr 2016 08:30:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u3PFUSX6009675; Mon, 25 Apr 2016 08:30:28 -0700 Received: from XCH15-05-02.nw.nos.boeing.com (xch15-05-02.nw.nos.boeing.com [137.137.100.59]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u3PFUOXe009621 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 25 Apr 2016 08:30:24 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-02.nw.nos.boeing.com (2002:8989:643b::8989:643b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 25 Apr 2016 08:30:13 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 25 Apr 2016 08:30:13 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , "its@ietf.org" Thread-Topic: [its] latest charter text Thread-Index: AQHRnuovD0zPM4Y86k2Lvn9a/gJsy5+a0K8A Date: Mon, 25 Apr 2016 15:30:13 +0000 Message-ID: <06cb15e70fe04a07abe10678600daf8a@XCH15-05-05.nw.nos.boeing.com> References: <571E06FF.9060404@gmail.com> In-Reply-To: <571E06FF.9060404@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_06cb15e70fe04a07abe10678600daf8aXCH150505nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 15:30:23 -0000 --_000_06cb15e70fe04a07abe10678600daf8aXCH150505nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxleCwNCg0KV2lsbCB0aGVyZSBiZSB3b3JrIGl0ZW1zIGNvdmVyaW5nIGNpdmlsIGF2aWF0 aW9uIGFuZCB1bm1hbm5lZCBhaXIgc3lzdGVtDQp1c2UgY2FzZXM/DQoNClRoYW5rcyAtIEZyZWQN Cg0KRnJvbTogaXRzIFttYWlsdG86aXRzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBB bGV4YW5kcmUgUGV0cmVzY3UNClNlbnQ6IE1vbmRheSwgQXByaWwgMjUsIDIwMTYgNTowMSBBTQ0K VG86IGl0c0BpZXRmLm9yZw0KU3ViamVjdDogW2l0c10gbGF0ZXN0IGNoYXJ0ZXIgdGV4dA0KDQpJ VFNlcnMsDQoNCllvdSB3aWxsIGZpbmQgYmVsb3cgdGhlIGxhdGVzdCBjaGFydGVyIHRleHQuDQoN Ckl0IGluY2x1ZGVzIGNoYW5nZXMgaXNzdWVkIGZyb20gZGlzY3Vzc2lvbnMgd2l0aCBEaWNrLg0K DQpBbGV4DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KSW50ZWxsaWdlbnQgVHJhbnNwb3J0YXRpb24gU3lzdGVtcyAo aXRzKQ0KDQpDaGFpcnM6DQogICBSdXNzIEhvdXNsZXkNCiAgIENhcmxvcyBQaWduYXRhcm8NCg0K QXNzaWduZWQgQXJlYSBEaXJlY3RvcjoNCiAgIFN1cmVzaCBLcmlzaG5hbg0KDQpNYWlsaW5nIGxp c3QNCiAgIEFkZHJlc3M6IGl0c0BpZXRmLm9yZzxtYWlsdG86aXRzQGlldGYub3JnPg0KICAgVG8g U3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KICAg QXJjaGl2ZToNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pdHMvY3Vy cmVudC9tYWlsbGlzdC5odG1sDQoNCkFkZGl0aW9uYWwgd2ViIHBhZ2UNCiAgIFRCRA0KDQpDaGFy dGVyDQoNCkF1dG9tb2JpbGVzIGFuZCB2ZWhpY2xlcyBvZiBhbGwgdHlwZXMgYXJlIGluY3JlYXNp bmdseSBjb25uZWN0ZWQgdG8NCnRoZSBJbnRlcm5ldC4gIENvbWZvcnQtZW5oYW5jaW5nIGVudGVy dGFpbm1lbnQgYXBwbGljYXRpb25zLCByb2FkDQpzYWZldHkgYXBwbGljYXRpb25zIGJhc2VkIG9u IGJpZGlyZWN0aW9uYWwgZGF0YSBmbG93cywgYW5kIGNvbm5lY3RlZA0KYXV0b21hdGVkIGRyaXZp bmcgYXJlIGJ1dCBhIGZldyBuZXcgZmVhdHVyZXMgZXhwZWN0ZWQgaW4gYXV0b21vYmlsZXMNCnRv IGhpdCB0aGUgcm9hZHMgZnJvbSBub3cgdG8geWVhciAyMDIwLg0KDQpUb2RheSwgdGhlcmUgYXJl IHNldmVyYWwgZGVwbG95ZWQgVmVoaWNsZS10by1JbnRlcm5ldCB0ZWNobm9sb2dpZXMNCihWMklu dGVybmV0KSB0aGF0IG1ha2UgdXNlIG9mIGVtYmVkZGVkIEludGVybmV0IG1vZHVsZXMsIG9yIHRo cm91Z2gNCmRyaXZlcidzIGNlbGx1bGFyIHNtYXJ0cGhvbmU6IG1pcnJvcmxpbmssIGNhcnBsYXks IGFuZHJvaWQgYXV0by4NCkhvd2V2ZXIsIFZlaGljbGUtdG8tVmVoaWNsZSAoVjJWKSBhbmQgVmVo aWNsZS10by1JbmZyYXN0cnVjdHVyZSAoVjJJLA0Kbm90IHRvIGJlIG1pc3Rha2VuIHdpdGggVjJJ bnRlcm5ldCkgY29tbXVuaWNhdGlvbnMgYXJlIHN0aWxsIGJlaW5nDQpkZXZlbG9wZWQuDQoNCklu IHRoZSBmdXR1cmUsIHNvbWUgdmVoaWNsZSBjb21tdW5pY2F0aW9ucyBtYXkgbm90IHVzZSBJUCBm b3INCmV4Y2hhbmdpbmcgc2FmZXR5IG1lc3NhZ2VzIHdpdGggb3RoZXIgdmVoaWNsZXMgYW5kIGlu ZnJhc3RydWN0dXJlLg0KT3RoZXIgdmVoaWNsZSBjb21tdW5pY2F0aW9ucyBtYXkgaW52b2x2ZSBJ UC1iYXNlZCBwcm90b2NvbHMsDQplc3BlY2lhbGx5IHdoZW4gbXVsdGlwbGUgYXBwbGljYXRpb25z IG5lZWQgdG8gc2hhcmUgb25lIGRhdGEgbGluay4NCg0KVGhpcyBncm91cCB3aWxsIHdvcmsgb24g VjJWIGFuZCBWMkkgdXNlLWNhc2VzIHdoZXJlIElQIGlzIHdlbGwtc3VpdGVkDQphcyBhIG5ldHdv cmtpbmcgdGVjaG5vbG9neSwgc3VwcG9ydGluZyBhbHNvIGFwcGxpY2F0aW9ucyB0aGF0IGludm9s dmUNCmV4Y2hhbmdlcyBvZiBzYWZldHktcmVsYXRlZCBtZXNzYWdlcyBiZXR3ZWVuIHZlaGljbGVz IGFuZA0KaW5mcmFzdHJ1Y3R1cmUgaWYgbmVjZXNzYXJ5Lg0KDQpUaGlzIGdyb3VwIHdpbGwgZGV2 ZWxvcCBJUC1iYXNlZCBwcm90b2NvbHMgdG8gZXN0YWJsaXNoIGRpcmVjdCBhbmQNCnNlY3VyZSBj b25uZWN0aXZpdHkgYmV0d2VlbiBhIHZlaGljbGUsIHdoaWNoIGlzIG9mdGVuIGNvbXByaXNlZCBv Zg0KbW92aW5nIG5ldHdvcmtzLCBhbmQgb3RoZXIgdmVoaWNsZXMgYW5kIHN0YXRpb25hcnkgc3lz dGVtcy4gIFNvbWUNCmNvbW11bmljYXRpb25zIHdpbGwgYmUgZXh0cmVtZWx5IHNob3J0IGxpdmVk LCBidXQgb3RoZXJzIHdpbGwgbGFzdCBmb3INCm1hbnkgaG91cnMgb3IgZGF5cy4NCg0KSW4gZ2Vu ZXJhbCwgdGhpcyBncm91cCBpcyBjb25jZXJuZWQgd2l0aCBzaXR1YXRpb25zIGludm9sdmluZyBt b3ZpbmcNCm5ldHdvcmsgdG8gbmVhcmJ5IG1vdmluZywgb3IgZml4ZWQsIG5ldHdvcmsgY29tbXVu aWNhdGlvbnMgKFYyViwgVjJJLA0KSTJWKS4gIEZvciBleGFtcGxlOiBhIG1vdmluZyBuZXR3b3Jr IGluIGEgdmVoaWNsZSBjb21tdW5pY2F0aW5nIHRvDQphbm90aGVyIG1vdmluZyBuZXR3b3JrIGlu IGEgbmVhcmJ5IHZlaGljbGUgKGZvciBDLUFDQywgUGxhdG9vbmluZywgb3INCmF0IGFuIGluY2lk ZW50IHNjZW5lKTsgYSBwZXJzb25hbCBhcmVhIG5ldHdvcmsgY2FycmllZCBieSBhIHVzZXIgYW5k DQpjb25uZWN0aW5nIHRvIGFuIGluLWhvdXNlIGZpeGVkIG5ldHdvcmsgKGhvbWVuZXQpOyBhbiBp bi1jYXIgbmV0d29ya2VkDQpkZXZpY2UgcmVjZWl2aW5nIG1lc3NhZ2VzIGZyb20gYSByb2FkLXNp ZGUgZGlzcGxheSB3aGVuIHBhc3NpbmcgYnksDQp3YWdvbi10by13YWdvbiByYW5nZSBleHRlbnNp b24gaW4gYSB0cmFpbjsgdHJhaW4tdG8taW50ZXJzZWN0aW9uDQpzaWduYWxsaW5nLiAgSW4gdGhl c2UgbG9vcC1mcmVlIDEtSVAtaG9wIHRvcG9sb2dpZXMgdGhlcmUgaXMgYSBwcm9ibGVtDQpvZiBl c3RhYmxpc2hpbmcgSVAgcGF0aHMgcXVpY2tseSBhbmQgcmVsaWFibHkuDQoNCkltcHJvdmVkIHNh ZmV0eSBpcyBhbiBpbW1lZGlhdGUgcmVzdWx0IG9mIGh5cGVyLWNvbm5lY3Rpdml0eSBvZg0KdmVo aWNsZXM7IGFzIHN1Y2ggcHVibGljIGF1dGhvcml0aWVzIHdvcmxkd2lkZSBhcmUgaW5jcmVhc2lu Z2x5DQptYW5kYXRpbmcgc2VjdXJlIGNvbW11bmljYXRpb24gdGVjaG5vbG9neSByZXF1aXJlbWVu dHMgaW4gdmVoaWNsZXMuDQpFbWVyZ2VuY3kgYXBwbGljYXRpb25zIGZvciBpbnN0cnVtZW50ZWQg YW1idWxhbmNlcyBjYXJyeSBtYW55IGJlbmVmaXRzDQpib3RoIHRvIHRoZSB1c2VycyBhbmQgdG8g c29jaWV0eSBpbiBnZW5lcmFsLiAgRm9yIHRoZXNlIHJlYXNvbnMsIGENCnNvbHV0aW9uIHRvIHRo ZSBwcm9ibGVtIG9mIGVzdGFibGlzaGluZyBJUCBwYXRocyBiZXR3ZWVuIG5lYXJieSBtb3ZpbmcN Cm5ldHdvcmtzIHdpbGwgYmUgcmVzaWxpZW50IHRvIHRocmVhdHMgc3VjaCBhcyBlYXZlc2Ryb3Bw aW5nLg0KDQpNb3ZpbmcgbmV0d29yayB0byBuZWFyYnkgbW92aW5nIG9yIGZpeGVkIG5ldHdvcmsg Y29tbXVuaWNhdGlvbnMgbWF5DQppbnZvbHZlIHZhcmlvdXMga2luZHMgb2YgbGluayBsYXllcnM6 IDgwMi4xMS1PQ0IgKE91dHNpZGUgdGhlIENvbnRleHQNCm9mIGEgQmFzaWMgU2VydmljZSBTZXQp LCA4MDIuMTUuNCB3aXRoIDZsb3dwYW4sIDgwMi4xMWFkLCBWTEMgKFZpc2libGUNCkxpZ2h0IENv bW11bmljYXRpb25zKSwgSXJEQSwgTFRFLUQsIExQLVdBTi4gIE9uZSBvZiB0aGUgbW9zdCB1c2Vk IGxpbmsNCmxheWVycyBmb3IgdmVoaWN1bGFyIG5ldHdvcmtzIGlzIElFRUUgODAyLjExLU9DQiwg YXMgYSBiYXNpcyBmb3IgRFNSQy4NCkhvd2V2ZXIsIElQdjYgb24gODAyLjExLU9DQiBpcyBub3Qg eWV0IGRlZmluZWQuDQoNClRoZSBncm91cCB3aWxsIG9ubHkgd29yayBvbiBJUHY2IHNvbHV0aW9u cy4NCg0KVGhlIGdyb3VwIHdpbGwgbGV2ZXJhZ2Ugb24gdGVjaG5vbG9naWVzIGZvciBJbnRlcm5l dCBvZiBUaGluZ3MgKElvVCkNCndoaWNoIGFyZSBkZXZlbG9wZWQgaW4gb3RoZXIgSUVURiBlZmZv cnRzOiA2bG8sIExQLVdBTiwgVDJULg0KQ28tZXhpc3RlbmNlIHdpdGggdGVjaG5pcXVlcyBvZiBp bmZyYXN0cnVjdHVyZSBtb2JpbGl0eSBtYW5hZ2VtZW50DQp3aWxsIGJlIGNvb3JkaW5hdGVkIHdp dGggdGhlIERNTSBXb3JraW5nIEdyb3VwLg0KDQpUaGUgU0RPcyBpbnRlcmVzdGVkIGluIHRoaXMg d29yayBhcmU6IElTTy9UQzIwNCwgRVRTSSBUQyBJVFMsIDNHUFAsDQpOSFRTQSBhbmQgbW9yZS4N Cg0KVGhpcyBncm91cCB3aWxsIG5vdCB3b3JrIG9uIFYyViBvciBWMkkgdXNlLWNhc2VzIHdoZXJl IElQIGlzIG5vdA0Kd2VsbC1zdWl0ZWQuDQoNCklmIHRoZSBncm91cCBpcyBzdWNjZXNzZnVsIGlu IGRlc2lnbmluZyBhIHNpbXBsZSAxLUlQLWhvcCBzb2x1dGlvbiBmb3INClYyVi9WMkkvSTJWLCBh bmQgaWYgZGVwbG95bWVudHMgcHJvdmUgdXNlZnVsLCBpbiByZWFzb25hYmxlIHRpbWUsIHRoZW4N CmZ1dHVyZSBleHRlbnNpb25zIGZvciBuLUlQLWhvcCBWMlYySSBtYXkgYmUgY29uc2lkZXJlZC4N Cg0KV29yayBpdGVtcw0KMS4gIlByb2JsZW0gc3RhdGVtZW50IGZvciBJUCBpbiBWMlYgYW5kIFYy SSINCiAgIGluY2x1ZGluZyAiSVAgYWRkcmVzc2luZyBhcmNoaXRlY3R1cmUgZm9yIFYyViBhbmQg VjJJIg0KICAgYW5kIGluY2x1ZGluZyAiR2FwIEFuYWx5c2lzOiBJUCBwcm90b2NvbHMgc3VpdGVk IGFuZCBnYXBzIg0KICAgYW5kIGluY2x1ZGluZyAiVXNlLWNhc2VzIGZvciBJUCBpbiBWMlYgYW5k IFYySSBtb3ZpbmcgbmV0d29yaw0KICAgVG8gbmVhcmJ5IG1vdmluZyBvciBmaXhlZCBuZXR3b3Jr Ig0KDQoyLiAiVGhyZWF0IEFuYWx5c2lzIGZvciBJUCBwcmVmaXggZXhjaGFuZ2VzIGluIFYyViBh bmQgVjJJDQogICBDb250ZXh0Ig0KDQozLiAiSVAgb3ZlciBEU1JDICg4MDIuMTEtT0NCKSIgdHlw aWNhbCBJUC1vdmVyLWZvbyBkb2N1bWVudCwNCiAgIGluY2x1ZGluZyBjb25uZWN0aXZpdHkgaW4g ZmFzdCBhbmQgYXN5bW1ldHJpYyBjb25kaXRpb25zLA0KICAgQ292ZXJhZ2UgYXJlYSB2cyBzcGVl ZCBkaWFncmFtcywgYmVsb3ctSVAgY29uZ2VzdGlvbg0KICAgbWFuYWdlbWVudC4NCg0KNC4gIkxp c3Qgb2YgcGFwZXJzIGFuZCBfcHJvZHVjdHNfIHVzaW5nIElQIGluIFYyViBhbmQgVjJJIg0KDQo1 LiAiU29sdXRpb24gZm9yIGRpcmVjdCBjb21tdW5pY2F0aW9uIGJldHdlZW4gbW92aW5nIG5ldHdv cmtzIg0KDQpHb2FscyBhbmQgbWlsZXN0b25lcw0KT2N0IDIwMTYgLSBzdWJtaXQg4oCcUHJvYmxl bSBTdGF0ZW1lbnTigJ0gdG8gV0cNCk9jdCAyMDE2IC0gc3VibWl0IOKAnExpc3Qgb2YgcGFwZXJz IGFuZCBwcm9kdWN0c+KAnSB0byBXRw0KRmViIDIwMTcgLSBzdWJtaXQg4oCcVGhyZWF0IEFuYWx5 c2lz4oCdIHRvIFdHDQpGZWIgMjAxNyAtIHN1Ym1pdCDigJxJUCBvdmVyIERTUkMgKDgwMi4xMS1P Q0Ip4oCdIHRvIFdHDQpKdW4gMjAxNyAtIHN1Ym1pdCDigJxTb2x1dGlvbiBmb3IgZGlyZWN0aW9u IGNvbW11bmljYXRpb24gYmV0d2Vlbg0KICAgICAgICAgICAgICAgICAgIG1vdmluZyBuZXR3b3Jr c+KAnSB0byBXRw0KT2N0IDIwMTcgLSBzdGFydCBzdWJtaXR0aW5nIHRvIElFU0cNCg== --_000_06cb15e70fe04a07abe10678600daf8aXCH150505nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsN Cgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFsZXgsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaWxsIHRoZXJlIGJlIHdv cmsgaXRlbXMgY292ZXJpbmcgY2l2aWwgYXZpYXRpb24gYW5kIHVubWFubmVkIGFpciBzeXN0ZW08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+dXNlIGNhc2VzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOndpbmRvd3RleHQiPiBpdHMgW21haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+QWxleGFuZHJlIFBldHJlc2N1PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgQXByaWwgMjUsIDIwMTYgNTowMSBBTTxicj4NCjxiPlRvOjwvYj4gaXRzQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFtpdHNdIGxhdGVzdCBjaGFydGVyIHRleHQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ SVRTZXJzLDxicj4NCjxicj4NCllvdSB3aWxsIGZpbmQgYmVsb3cgdGhlIGxhdGVzdCBjaGFydGVy IHRleHQuPGJyPg0KPGJyPg0KSXQgaW5jbHVkZXMgY2hhbmdlcyBpc3N1ZWQgZnJvbSBkaXNjdXNz aW9ucyB3aXRoIERpY2suPGJyPg0KPGJyPg0KQWxleDxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KSW50 ZWxsaWdlbnQgVHJhbnNwb3J0YXRpb24gU3lzdGVtcyAoaXRzKTxicj4NCjxicj4NCkNoYWlyczo8 YnI+DQombmJzcDsmbmJzcDsgUnVzcyBIb3VzbGV5PGJyPg0KJm5ic3A7Jm5ic3A7IENhcmxvcyBQ aWduYXRhcm88YnI+DQo8YnI+DQpBc3NpZ25lZCBBcmVhIERpcmVjdG9yOjxicj4NCiZuYnNwOyZu YnNwOyBTdXJlc2ggS3Jpc2huYW48YnI+DQo8YnI+DQpNYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsm bmJzcDsgQWRkcmVzczogPGEgaHJlZj0ibWFpbHRvOml0c0BpZXRmLm9yZyI+aXRzQGlldGYub3Jn PC9hPjxicj4NCiZuYnNwOyZuYnNwOyBUbyBTdWJzY3JpYmU6IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2l0czwvYT48YnI+DQombmJzcDsmbmJzcDsgQXJjaGl2ZTo8YnI+DQombmJz cDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2l0 cy9jdXJyZW50L21haWxsaXN0Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9pdHMvY3VycmVudC9tYWlsbGlzdC5odG1sPC9hPjxicj4NCjxicj4NCkFkZGl0aW9uYWwg d2ViIHBhZ2U8YnI+DQombmJzcDsmbmJzcDsgVEJEPGJyPg0KPGJyPg0KQ2hhcnRlcjxicj4NCjxi cj4NCkF1dG9tb2JpbGVzIGFuZCB2ZWhpY2xlcyBvZiBhbGwgdHlwZXMgYXJlIGluY3JlYXNpbmds eSBjb25uZWN0ZWQgdG88YnI+DQp0aGUgSW50ZXJuZXQuJm5ic3A7IENvbWZvcnQtZW5oYW5jaW5n IGVudGVydGFpbm1lbnQgYXBwbGljYXRpb25zLCByb2FkPGJyPg0Kc2FmZXR5IGFwcGxpY2F0aW9u cyBiYXNlZCBvbiBiaWRpcmVjdGlvbmFsIGRhdGEgZmxvd3MsIGFuZCBjb25uZWN0ZWQ8YnI+DQph dXRvbWF0ZWQgZHJpdmluZyBhcmUgYnV0IGEgZmV3IG5ldyBmZWF0dXJlcyBleHBlY3RlZCBpbiBh dXRvbW9iaWxlczxicj4NCnRvIGhpdCB0aGUgcm9hZHMgZnJvbSBub3cgdG8geWVhciAyMDIwLjxi cj4NCjxicj4NClRvZGF5LCB0aGVyZSBhcmUgc2V2ZXJhbCBkZXBsb3llZCBWZWhpY2xlLXRvLUlu dGVybmV0IHRlY2hub2xvZ2llczxicj4NCihWMkludGVybmV0KSB0aGF0IG1ha2UgdXNlIG9mIGVt YmVkZGVkIEludGVybmV0IG1vZHVsZXMsIG9yIHRocm91Z2g8YnI+DQpkcml2ZXIncyBjZWxsdWxh ciBzbWFydHBob25lOiBtaXJyb3JsaW5rLCBjYXJwbGF5LCBhbmRyb2lkIGF1dG8uPGJyPg0KSG93 ZXZlciwgVmVoaWNsZS10by1WZWhpY2xlIChWMlYpIGFuZCBWZWhpY2xlLXRvLUluZnJhc3RydWN0 dXJlIChWMkksPGJyPg0Kbm90IHRvIGJlIG1pc3Rha2VuIHdpdGggVjJJbnRlcm5ldCkgY29tbXVu aWNhdGlvbnMgYXJlIHN0aWxsIGJlaW5nPGJyPg0KZGV2ZWxvcGVkLjxicj4NCjxicj4NCkluIHRo ZSBmdXR1cmUsIHNvbWUgdmVoaWNsZSBjb21tdW5pY2F0aW9ucyBtYXkgbm90IHVzZSBJUCBmb3I8 YnI+DQpleGNoYW5naW5nIHNhZmV0eSBtZXNzYWdlcyB3aXRoIG90aGVyIHZlaGljbGVzIGFuZCBp bmZyYXN0cnVjdHVyZS48YnI+DQpPdGhlciB2ZWhpY2xlIGNvbW11bmljYXRpb25zIG1heSBpbnZv bHZlIElQLWJhc2VkIHByb3RvY29scyw8YnI+DQplc3BlY2lhbGx5IHdoZW4gbXVsdGlwbGUgYXBw bGljYXRpb25zIG5lZWQgdG8gc2hhcmUgb25lIGRhdGEgbGluay48YnI+DQo8YnI+DQpUaGlzIGdy b3VwIHdpbGwgd29yayBvbiBWMlYgYW5kIFYySSB1c2UtY2FzZXMgd2hlcmUgSVAgaXMgd2VsbC1z dWl0ZWQ8YnI+DQphcyBhIG5ldHdvcmtpbmcgdGVjaG5vbG9neSwgc3VwcG9ydGluZyBhbHNvIGFw cGxpY2F0aW9ucyB0aGF0IGludm9sdmU8YnI+DQpleGNoYW5nZXMgb2Ygc2FmZXR5LXJlbGF0ZWQg bWVzc2FnZXMgYmV0d2VlbiB2ZWhpY2xlcyBhbmQ8YnI+DQppbmZyYXN0cnVjdHVyZSBpZiBuZWNl c3NhcnkuPGJyPg0KPGJyPg0KVGhpcyBncm91cCB3aWxsIGRldmVsb3AgSVAtYmFzZWQgcHJvdG9j b2xzIHRvIGVzdGFibGlzaCBkaXJlY3QgYW5kPGJyPg0Kc2VjdXJlIGNvbm5lY3Rpdml0eSBiZXR3 ZWVuIGEgdmVoaWNsZSwgd2hpY2ggaXMgb2Z0ZW4gY29tcHJpc2VkIG9mPGJyPg0KbW92aW5nIG5l dHdvcmtzLCBhbmQgb3RoZXIgdmVoaWNsZXMgYW5kIHN0YXRpb25hcnkgc3lzdGVtcy4mbmJzcDsg U29tZTxicj4NCmNvbW11bmljYXRpb25zIHdpbGwgYmUgZXh0cmVtZWx5IHNob3J0IGxpdmVkLCBi dXQgb3RoZXJzIHdpbGwgbGFzdCBmb3I8YnI+DQptYW55IGhvdXJzIG9yIGRheXMuPGJyPg0KPGJy Pg0KSW4gZ2VuZXJhbCwgdGhpcyBncm91cCBpcyBjb25jZXJuZWQgd2l0aCBzaXR1YXRpb25zIGlu dm9sdmluZyBtb3Zpbmc8YnI+DQpuZXR3b3JrIHRvIG5lYXJieSBtb3ZpbmcsIG9yIGZpeGVkLCBu ZXR3b3JrIGNvbW11bmljYXRpb25zIChWMlYsIFYySSw8YnI+DQpJMlYpLiZuYnNwOyBGb3IgZXhh bXBsZTogYSBtb3ZpbmcgbmV0d29yayBpbiBhIHZlaGljbGUgY29tbXVuaWNhdGluZyB0bzxicj4N CmFub3RoZXIgbW92aW5nIG5ldHdvcmsgaW4gYSBuZWFyYnkgdmVoaWNsZSAoZm9yIEMtQUNDLCBQ bGF0b29uaW5nLCBvcjxicj4NCmF0IGFuIGluY2lkZW50IHNjZW5lKTsgYSBwZXJzb25hbCBhcmVh IG5ldHdvcmsgY2FycmllZCBieSBhIHVzZXIgYW5kPGJyPg0KY29ubmVjdGluZyB0byBhbiBpbi1o b3VzZSBmaXhlZCBuZXR3b3JrIChob21lbmV0KTsgYW4gaW4tY2FyIG5ldHdvcmtlZDxicj4NCmRl dmljZSByZWNlaXZpbmcgbWVzc2FnZXMgZnJvbSBhIHJvYWQtc2lkZSBkaXNwbGF5IHdoZW4gcGFz c2luZyBieSw8YnI+DQp3YWdvbi10by13YWdvbiByYW5nZSBleHRlbnNpb24gaW4gYSB0cmFpbjsg dHJhaW4tdG8taW50ZXJzZWN0aW9uPGJyPg0Kc2lnbmFsbGluZy4mbmJzcDsgSW4gdGhlc2UgbG9v cC1mcmVlIDEtSVAtaG9wIHRvcG9sb2dpZXMgdGhlcmUgaXMgYSBwcm9ibGVtPGJyPg0Kb2YgZXN0 YWJsaXNoaW5nIElQIHBhdGhzIHF1aWNrbHkgYW5kIHJlbGlhYmx5Ljxicj4NCjxicj4NCkltcHJv dmVkIHNhZmV0eSBpcyBhbiBpbW1lZGlhdGUgcmVzdWx0IG9mIGh5cGVyLWNvbm5lY3Rpdml0eSBv Zjxicj4NCnZlaGljbGVzOyBhcyBzdWNoIHB1YmxpYyBhdXRob3JpdGllcyB3b3JsZHdpZGUgYXJl IGluY3JlYXNpbmdseTxicj4NCm1hbmRhdGluZyBzZWN1cmUgY29tbXVuaWNhdGlvbiB0ZWNobm9s b2d5IHJlcXVpcmVtZW50cyBpbiB2ZWhpY2xlcy48YnI+DQpFbWVyZ2VuY3kgYXBwbGljYXRpb25z IGZvciBpbnN0cnVtZW50ZWQgYW1idWxhbmNlcyBjYXJyeSBtYW55IGJlbmVmaXRzPGJyPg0KYm90 aCB0byB0aGUgdXNlcnMgYW5kIHRvIHNvY2lldHkgaW4gZ2VuZXJhbC4mbmJzcDsgRm9yIHRoZXNl IHJlYXNvbnMsIGE8YnI+DQpzb2x1dGlvbiB0byB0aGUgcHJvYmxlbSBvZiBlc3RhYmxpc2hpbmcg SVAgcGF0aHMgYmV0d2VlbiBuZWFyYnkgbW92aW5nPGJyPg0KbmV0d29ya3Mgd2lsbCBiZSByZXNp bGllbnQgdG8gdGhyZWF0cyBzdWNoIGFzIGVhdmVzZHJvcHBpbmcuPGJyPg0KPGJyPg0KTW92aW5n IG5ldHdvcmsgdG8gbmVhcmJ5IG1vdmluZyBvciBmaXhlZCBuZXR3b3JrIGNvbW11bmljYXRpb25z IG1heTxicj4NCmludm9sdmUgdmFyaW91cyBraW5kcyBvZiBsaW5rIGxheWVyczogODAyLjExLU9D QiAoT3V0c2lkZSB0aGUgQ29udGV4dDxicj4NCm9mIGEgQmFzaWMgU2VydmljZSBTZXQpLCA4MDIu MTUuNCB3aXRoIDZsb3dwYW4sIDgwMi4xMWFkLCBWTEMgKFZpc2libGU8YnI+DQpMaWdodCBDb21t dW5pY2F0aW9ucyksIElyREEsIExURS1ELCBMUC1XQU4uJm5ic3A7IE9uZSBvZiB0aGUgbW9zdCB1 c2VkIGxpbms8YnI+DQpsYXllcnMgZm9yIHZlaGljdWxhciBuZXR3b3JrcyBpcyBJRUVFIDgwMi4x MS1PQ0IsIGFzIGEgYmFzaXMgZm9yIERTUkMuPGJyPg0KSG93ZXZlciwgSVB2NiBvbiA4MDIuMTEt T0NCIGlzIG5vdCB5ZXQgZGVmaW5lZC48YnI+DQo8YnI+DQpUaGUgZ3JvdXAgd2lsbCBvbmx5IHdv cmsgb24gSVB2NiBzb2x1dGlvbnMuPGJyPg0KPGJyPg0KVGhlIGdyb3VwIHdpbGwgbGV2ZXJhZ2Ug b24gdGVjaG5vbG9naWVzIGZvciBJbnRlcm5ldCBvZiBUaGluZ3MgKElvVCk8YnI+DQp3aGljaCBh cmUgZGV2ZWxvcGVkIGluIG90aGVyIElFVEYgZWZmb3J0czogNmxvLCBMUC1XQU4sIFQyVC48YnI+ DQpDby1leGlzdGVuY2Ugd2l0aCB0ZWNobmlxdWVzIG9mIGluZnJhc3RydWN0dXJlIG1vYmlsaXR5 IG1hbmFnZW1lbnQ8YnI+DQp3aWxsIGJlIGNvb3JkaW5hdGVkIHdpdGggdGhlIERNTSBXb3JraW5n IEdyb3VwLjxicj4NCjxicj4NClRoZSBTRE9zIGludGVyZXN0ZWQgaW4gdGhpcyB3b3JrIGFyZTog SVNPL1RDMjA0LCBFVFNJIFRDIElUUywgM0dQUCw8YnI+DQpOSFRTQSBhbmQgbW9yZS48YnI+DQo8 YnI+DQpUaGlzIGdyb3VwIHdpbGwgbm90IHdvcmsgb24gVjJWIG9yIFYySSB1c2UtY2FzZXMgd2hl cmUgSVAgaXMgbm90PGJyPg0Kd2VsbC1zdWl0ZWQuPGJyPg0KPGJyPg0KSWYgdGhlIGdyb3VwIGlz IHN1Y2Nlc3NmdWwgaW4gZGVzaWduaW5nIGEgc2ltcGxlIDEtSVAtaG9wIHNvbHV0aW9uIGZvcjxi cj4NClYyVi9WMkkvSTJWLCBhbmQgaWYgZGVwbG95bWVudHMgcHJvdmUgdXNlZnVsLCBpbiByZWFz b25hYmxlIHRpbWUsIHRoZW48YnI+DQpmdXR1cmUgZXh0ZW5zaW9ucyBmb3Igbi1JUC1ob3AgVjJW MkkgbWF5IGJlIGNvbnNpZGVyZWQuPGJyPg0KPGJyPg0KV29yayBpdGVtczxicj4NCjEuICZxdW90 O1Byb2JsZW0gc3RhdGVtZW50IGZvciBJUCBpbiBWMlYgYW5kIFYySSZxdW90Ozxicj4NCiZuYnNw OyZuYnNwOyBpbmNsdWRpbmcgJnF1b3Q7SVAgYWRkcmVzc2luZyBhcmNoaXRlY3R1cmUgZm9yIFYy ViBhbmQgVjJJJnF1b3Q7PGJyPg0KJm5ic3A7Jm5ic3A7IGFuZCBpbmNsdWRpbmcgJnF1b3Q7R2Fw IEFuYWx5c2lzOiBJUCBwcm90b2NvbHMgc3VpdGVkIGFuZCBnYXBzJnF1b3Q7PGJyPg0KJm5ic3A7 Jm5ic3A7IGFuZCBpbmNsdWRpbmcgJnF1b3Q7VXNlLWNhc2VzIGZvciBJUCBpbiBWMlYgYW5kIFYy SSBtb3ZpbmcgbmV0d29yayA8YnI+DQombmJzcDsmbmJzcDsgVG8gbmVhcmJ5IG1vdmluZyBvciBm aXhlZCBuZXR3b3JrJnF1b3Q7PGJyPg0KPGJyPg0KMi4gJnF1b3Q7VGhyZWF0IEFuYWx5c2lzIGZv ciBJUCBwcmVmaXggZXhjaGFuZ2VzIGluIFYyViBhbmQgVjJJIDxicj4NCiZuYnNwOyZuYnNwOyBD b250ZXh0JnF1b3Q7PGJyPg0KPGJyPg0KMy4gJnF1b3Q7SVAgb3ZlciBEU1JDICg4MDIuMTEtT0NC KSZxdW90OyB0eXBpY2FsIElQLW92ZXItZm9vIGRvY3VtZW50LDxicj4NCiZuYnNwOyZuYnNwOyBp bmNsdWRpbmcgY29ubmVjdGl2aXR5IGluIGZhc3QgYW5kIGFzeW1tZXRyaWMgY29uZGl0aW9ucywg PGJyPg0KJm5ic3A7Jm5ic3A7IENvdmVyYWdlIGFyZWEgdnMgc3BlZWQgZGlhZ3JhbXMsIGJlbG93 LUlQIGNvbmdlc3Rpb24gPGJyPg0KJm5ic3A7Jm5ic3A7IG1hbmFnZW1lbnQuPGJyPg0KPGJyPg0K NC4gJnF1b3Q7TGlzdCBvZiBwYXBlcnMgYW5kIF9wcm9kdWN0c18gdXNpbmcgSVAgaW4gVjJWIGFu ZCBWMkkmcXVvdDs8YnI+DQo8YnI+DQo1LiAmcXVvdDtTb2x1dGlvbiBmb3IgZGlyZWN0IGNvbW11 bmljYXRpb24gYmV0d2VlbiBtb3ZpbmcgbmV0d29ya3MmcXVvdDs8YnI+DQo8YnI+DQpHb2FscyBh bmQgbWlsZXN0b25lczxicj4NCk9jdCAyMDE2IC0gc3VibWl0IOKAnFByb2JsZW0gU3RhdGVtZW50 4oCdIHRvIFdHPGJyPg0KT2N0IDIwMTYgLSBzdWJtaXQg4oCcTGlzdCBvZiBwYXBlcnMgYW5kIHBy b2R1Y3Rz4oCdIHRvIFdHPGJyPg0KRmViIDIwMTcgLSBzdWJtaXQg4oCcVGhyZWF0IEFuYWx5c2lz 4oCdIHRvIFdHPGJyPg0KRmViIDIwMTcgLSBzdWJtaXQg4oCcSVAgb3ZlciBEU1JDICg4MDIuMTEt T0NCKeKAnSB0byBXRzxicj4NCkp1biAyMDE3IC0gc3VibWl0IOKAnFNvbHV0aW9uIGZvciBkaXJl Y3Rpb24gY29tbXVuaWNhdGlvbiBiZXR3ZWVuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1vdmluZyBuZXR3b3Jrc+KAnSB0byBXRzxicj4N Ck9jdCAyMDE3IC0gc3RhcnQgc3VibWl0dGluZyB0byBJRVNHPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_06cb15e70fe04a07abe10678600daf8aXCH150505nwnosboeingcom_-- From nobody Mon Apr 25 10:09:21 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4CE12D634 for ; Mon, 25 Apr 2016 10:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.186 X-Spam-Level: X-Spam-Status: No, score=-5.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suirW_kbtW9m for ; Mon, 25 Apr 2016 10:09:18 -0700 (PDT) Received: from ndjsvnpf101.ndc.nasa.gov (NDJSVNPF101.ndc.nasa.gov [198.117.1.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF1012B018 for ; Mon, 25 Apr 2016 10:09:18 -0700 (PDT) Received: from ndjsppt105.ndc.nasa.gov (ndjsppt105.ndc.nasa.gov [198.117.1.199]) by ndjsvnpf101.ndc.nasa.gov (Postfix) with ESMTP id 053364005C4D; Mon, 25 Apr 2016 12:09:18 -0500 (CDT) Received: from NDJSCHT108.ndc.nasa.gov (ndjscht108-pub.ndc.nasa.gov [198.117.1.208]) by ndjsppt105.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id u3PH9H8G014685; Mon, 25 Apr 2016 12:09:17 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.156]) by NDJSCHT108.ndc.nasa.gov ([198.117.1.208]) with mapi id 14.03.0266.001; Mon, 25 Apr 2016 12:09:17 -0500 From: "Ivancic, William D. (GRC-LCA0)" To: "Templin, Fred L" , Alexandre Petrescu , "its@ietf.org" Thread-Topic: [its] latest charter text Thread-Index: AQHRnuorLjlEZTjFAESLZDmp0kOeRp+bJLWA///Y6QA= Date: Mon, 25 Apr 2016 17:09:16 +0000 Message-ID: References: <571E06FF.9060404@gmail.com> <06cb15e70fe04a07abe10678600daf8a@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: <06cb15e70fe04a07abe10678600daf8a@XCH15-05-05.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [139.88.111.195] Content-Type: multipart/alternative; boundary="_000_D343C53C45549williamdivancicnasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-25_08:, , signatures=0 Archived-At: Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 17:09:20 -0000 --_000_D343C53C45549williamdivancicnasagov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >From what I see, ITS is IPv6 ONLY items. Not DTN, but IPv6 provides potential discovery and validation. Not Information Centric Networking. Not others that are not IPv6 related. I was at IETF-95, but MP-TCP and ITS were at the same time. :-( It would be nice to fix ADS-B In. But you probably don=92t need IPv6 to do= it. But you could. I was at the Integrated Communications, Navigation and Surveillance (I-CNS)= conference last week and ask the FAA manager for the Next Generation Airsp= ace System (NextGen) about ADS-B In and got a " =85.. Well=85. Perhaps we c= an=92t discuss it in this forum. " Really good overview. https://media.blackhat.com/bh-us-12/Briefings/Costin/BH_US_12_Costin_Ghosts= _In_Air_Slides.pdf https://www.google.com/url?sa=3Dt&rct=3Dj&q=3D&esrc=3Ds&source=3Dweb&cd=3D3= &cad=3Drja&uact=3D8&ved=3D0ahUKEwiWjdL1oarMAhWPQD4KHT0pCG0QtwIIKTAC&url=3Dh= ttps%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DmY2uiLfXmaI&usg=3DAFQjCNGnegT_l8= lQ7MLE74MYFG5VZv4iMQ&sig2=3DXD6tloGhoGfFQvu3vgFFvg Will From: its > on behalf of = "Templin, Fred L" > Date: Monday, April 25, 2016 at 11:30 AM To: Alexandre Petrescu >, "its@ietf.org" > Subject: Re: [its] latest charter text Hi Alex, Will there be work items covering civil aviation and unmanned air system use cases? Thanks - Fred From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Monday, April 25, 2016 5:01 AM To: its@ietf.org Subject: [its] latest charter text ITSers, You will find below the latest charter text. It includes changes issued from discussions with Dick. Alex -------------------------------------------------------------------- Intelligent Transportation Systems (its) Chairs: Russ Housley Carlos Pignataro Assigned Area Director: Suresh Krishnan Mailing list Address: its@ietf.org 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 based on 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. In general, this group is concerned with situations involving moving network to nearby moving, or fixed, network communications (V2V, V2I, I2V). For example: a moving network in a vehicle communicating to another moving network in a nearby vehicle (for C-ACC, Platooning, or at an incident scene); a personal area network carried by a user and connecting to an in-house fixed network (homenet); an in-car networked device receiving messages from a road-side display when passing by, wagon-to-wagon range extension in a train; train-to-intersection signalling. In these loop-free 1-IP-hop topologies there is a problem of establishing IP paths quickly and reliably. Improved safety is an immediate result of hyper-connectivity of vehicles; as such public authorities worldwide are increasingly mandating secure communication technology requirements in vehicles. Emergency applications for instrumented ambulances carry many benefits both to the users and to society in general. For these reasons, a solution to the problem of establishing IP paths between nearby moving networks will be resilient to threats such as eavesdropping. 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. 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. If the group is successful in designing a simple 1-IP-hop solution for V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then future extensions for n-IP-hop V2V2I may be considered. Work items 1. "Problem statement for IP in V2V and V2I" including "IP addressing architecture for V2V and V2I" and including "Gap Analysis: IP protocols suited and gaps" and including "Use-cases for IP in V2V and V2I moving network To nearby moving or fixed network" 2. "Threat Analysis for IP prefix exchanges in V2V and V2I Context" 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document, including connectivity in fast and asymmetric conditions, Coverage area vs speed diagrams, below-IP congestion management. 4. "List of papers and _products_ using IP in V2V and V2I" 5. "Solution for direct communication between moving networks" Goals and milestones Oct 2016 - submit =93Problem Statement=94 to WG Oct 2016 - submit =93List of papers and products=94 to WG Feb 2017 - submit =93Threat Analysis=94 to WG Feb 2017 - submit =93IP over DSRC (802.11-OCB)=94 to WG Jun 2017 - submit =93Solution for direction communication between moving networks=94 to WG Oct 2017 - start submitting to IESG --_000_D343C53C45549williamdivancicnasagov_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9CF8A10DF51F0C4E8273A9CF6A25C3C4@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable
From what I see, ITS is IPv6 ONLY items.  

Not DTN, but IPv6 provides potential discovery and validation.
Not Information Centric Networking. 
Not others that are not IPv6 related.

I was at IETF-95, but MP-TCP and ITS were at the same time.  :-(<= /div>

It would be nice to fix ADS-B In.  But you probably don=92t need = IPv6 to do it.  But you could.

I was at the Integrated Communications, Navigation and Surveillance (I= -CNS) conference last week and ask the FAA manager for the Next Generation = Airspace System (NextGen) about ADS-B In and got a " =85.. Well=85. Pe= rhaps we can=92t discuss it in this forum. "


Really good overview.
https://media.blackhat.com/bh-us-12/Briefings/Costin/BH_US_12_Costin_G= hosts_In_Air_Slides.pdf

https://www.google.com/url?sa=3Dt&rct=3Dj&q=3D&esrc=3Ds&am= p;source=3Dweb&cd=3D3&cad=3Drja&uact=3D8&ved=3D0ahUKEwiWjdL= 1oarMAhWPQD4KHT0pCG0QtwIIKTAC&url=3Dhttps%3A%2F%2Fwww.youtube.com%2Fwat= ch%3Fv%3DmY2uiLfXmaI&usg=3DAFQjCNGnegT_l8lQ7MLE74MYFG5VZv4iMQ&sig2= =3DXD6tloGhoGfFQvu3vgFFvg


Will

From: its <its-bounces@ietf.org> on behalf of "Templin,= Fred L" <Fred.L.Templ= in@boeing.com>
Date: Monday, April 25, 2016 at 11:= 30 AM
To: Alexandre Petrescu <alexandre.petrescu@gmail.com&g= t;, "its@ietf.org" <its@ietf.org>
Subject: Re: [its] latest charter t= ext

Hi Alex,

 

Will there be work items covering c= ivil aviation and unmanned air system

use cases?

 

Thanks - Fred

 

From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Monday, April 25, 2016 5:01 AM
To: its@ietf.org
Subject: [its] latest charter text

 

ITSers,

You will find below the latest charter text.

It includes changes issued from discussions with Dick.

Alex
--------------------------------------------------------------------
Intelligent Transportation Systems (its)

Chairs:
   Russ Housley
   Carlos Pignataro

Assigned Area Director:
   Suresh Krishnan

Mailing list
   Address: its@ietf.org
   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 based on 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.

In general, this group is concerned with situations involving moving
network to nearby moving, or fixed, network communications (V2V, V2I,
I2V).  For example: a moving network in a vehicle communicating to
another moving network in a nearby vehicle (for C-ACC, Platooning, or
at an incident scene); a personal area network carried by a user and
connecting to an in-house fixed network (homenet); an in-car networked
device receiving messages from a road-side display when passing by,
wagon-to-wagon range extension in a train; train-to-intersection
signalling.  In these loop-free 1-IP-hop topologies there is a problem=
of establishing IP paths quickly and reliably.

Improved safety is an immediate result of hyper-connectivity of
vehicles; as such public authorities worldwide are increasingly
mandating secure communication technology requirements in vehicles.
Emergency applications for instrumented ambulances carry many benefits
both to the users and to society in general.  For these reasons, a
solution to the problem of establishing IP paths between nearby moving
networks will be resilient to threats such as eavesdropping.

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.

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.

If the group is successful in designing a simple 1-IP-hop solution for
V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then
future extensions for n-IP-hop V2V2I may be considered.

Work items
1. "Problem statement for IP in V2V and V2I"
   including "IP addressing architecture for V2V and V2I&quo= t;
   and including "Gap Analysis: IP protocols suited and gaps= "
   and including "Use-cases for IP in V2V and V2I moving net= work
   To nearby moving or fixed network"

2. "Threat Analysis for IP prefix exchanges in V2V and V2I
   Context"

3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document,
   including connectivity in fast and asymmetric conditions,
   Coverage area vs speed diagrams, below-IP congestion
   management.

4. "List of papers and _products_ using IP in V2V and V2I"

5. "Solution for direct communication between moving networks"
Goals and milestones
Oct 2016 - submit =93Problem Statement=94 to WG
Oct 2016 - submit =93List of papers and products=94 to WG
Feb 2017 - submit =93Threat Analysis=94 to WG
Feb 2017 - submit =93IP over DSRC (802.11-OCB)=94 to WG
Jun 2017 - submit =93Solution for direction communication between
            &nb= sp;      moving networks=94 to WG
Oct 2017 - start submitting to IESG

 --_000_D343C53C45549williamdivancicnasagov_-- From nobody Mon Apr 25 10:18:57 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869C912D187 for ; Mon, 25 Apr 2016 10:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.186 X-Spam-Level: X-Spam-Status: No, score=-5.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMyF0PGHDt3o for ; Mon, 25 Apr 2016 10:18:54 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DF312B018 for ; Mon, 25 Apr 2016 10:18:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u3PHJ3oU011172; Mon, 25 Apr 2016 10:19:03 -0700 Received: from XCH15-05-06.nw.nos.boeing.com (xch15-05-06.nw.nos.boeing.com [137.137.100.84]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u3PHIwPH011123 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 25 Apr 2016 10:18:58 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-06.nw.nos.boeing.com (2002:8989:6454::8989:6454) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 25 Apr 2016 10:18:48 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 25 Apr 2016 10:18:47 -0700 From: "Templin, Fred L" To: "Ivancic, William D. (GRC-LCA0)" , "Alexandre Petrescu" , "its@ietf.org" Thread-Topic: [its] latest charter text Thread-Index: AQHRnuovD0zPM4Y86k2Lvn9a/gJsy5+a0K8AgACROgD//4uYsA== Date: Mon, 25 Apr 2016 17:18:47 +0000 Message-ID: References: <571E06FF.9060404@gmail.com> <06cb15e70fe04a07abe10678600daf8a@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_acff618853e146eb8f5c0ab3d506d396XCH150505nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 17:18:56 -0000 --_000_acff618853e146eb8f5c0ab3d506d396XCH150505nwnosboeingcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Will, Yes, we have been thinking about ADS-B too. A proposal we came up with was to include position and heading information in an IPv6 extension header: https://datatracker.ietf.org/doc/draft-skeen-6man-ipv6geo/ That way, we can include both user data and position/heading information in a single IPv6 packet instead of having to send multiple packets. And, un= like ADS-B, it can be secured using IP and/or link-layer security mechanisms. Thanks - Fred From: Ivancic, William D. (GRC-LCA0) [mailto:william.d.ivancic@nasa.gov] Sent: Monday, April 25, 2016 10:09 AM To: Templin, Fred L ; Alexandre Petrescu ; its@ietf.org Subject: Re: [its] latest charter text >From what I see, ITS is IPv6 ONLY items. Not DTN, but IPv6 provides potential discovery and validation. Not Information Centric Networking. Not others that are not IPv6 related. I was at IETF-95, but MP-TCP and ITS were at the same time. :-( It would be nice to fix ADS-B In. But you probably don't need IPv6 to do i= t. But you could. I was at the Integrated Communications, Navigation and Surveillance (I-CNS)= conference last week and ask the FAA manager for the Next Generation Airsp= ace System (NextGen) about ADS-B In and got a " ..... Well.... Perhaps we c= an't discuss it in this forum. " Really good overview. https://media.blackhat.com/bh-us-12/Briefings/Costin/BH_US_12_Costin_Ghosts= _In_Air_Slides.pdf https://www.google.com/url?sa=3Dt&rct=3Dj&q=3D&esrc=3Ds&source=3Dweb&cd=3D3= &cad=3Drja&uact=3D8&ved=3D0ahUKEwiWjdL1oarMAhWPQD4KHT0pCG0QtwIIKTAC&url=3Dh= ttps%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DmY2uiLfXmaI&usg=3DAFQjCNGnegT_l8= lQ7MLE74MYFG5VZv4iMQ&sig2=3DXD6tloGhoGfFQvu3vgFFvg Will From: its > on behalf of = "Templin, Fred L" > Date: Monday, April 25, 2016 at 11:30 AM To: Alexandre Petrescu >, "its@ietf.org" > Subject: Re: [its] latest charter text Hi Alex, Will there be work items covering civil aviation and unmanned air system use cases? Thanks - Fred From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Monday, April 25, 2016 5:01 AM To: its@ietf.org Subject: [its] latest charter text ITSers, You will find below the latest charter text. It includes changes issued from discussions with Dick. Alex -------------------------------------------------------------------- Intelligent Transportation Systems (its) Chairs: Russ Housley Carlos Pignataro Assigned Area Director: Suresh Krishnan Mailing list Address: its@ietf.org 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 based on 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. In general, this group is concerned with situations involving moving network to nearby moving, or fixed, network communications (V2V, V2I, I2V). For example: a moving network in a vehicle communicating to another moving network in a nearby vehicle (for C-ACC, Platooning, or at an incident scene); a personal area network carried by a user and connecting to an in-house fixed network (homenet); an in-car networked device receiving messages from a road-side display when passing by, wagon-to-wagon range extension in a train; train-to-intersection signalling. In these loop-free 1-IP-hop topologies there is a problem of establishing IP paths quickly and reliably. Improved safety is an immediate result of hyper-connectivity of vehicles; as such public authorities worldwide are increasingly mandating secure communication technology requirements in vehicles. Emergency applications for instrumented ambulances carry many benefits both to the users and to society in general. For these reasons, a solution to the problem of establishing IP paths between nearby moving networks will be resilient to threats such as eavesdropping. 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. 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. If the group is successful in designing a simple 1-IP-hop solution for V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then future extensions for n-IP-hop V2V2I may be considered. Work items 1. "Problem statement for IP in V2V and V2I" including "IP addressing architecture for V2V and V2I" and including "Gap Analysis: IP protocols suited and gaps" and including "Use-cases for IP in V2V and V2I moving network To nearby moving or fixed network" 2. "Threat Analysis for IP prefix exchanges in V2V and V2I Context" 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document, including connectivity in fast and asymmetric conditions, Coverage area vs speed diagrams, below-IP congestion management. 4. "List of papers and _products_ using IP in V2V and V2I" 5. "Solution for direct communication between moving networks" Goals and milestones Oct 2016 - submit "Problem Statement" to WG Oct 2016 - submit "List of papers and products" to WG Feb 2017 - submit "Threat Analysis" to WG Feb 2017 - submit "IP over DSRC (802.11-OCB)" to WG Jun 2017 - submit "Solution for direction communication between moving networks" to WG Oct 2017 - start submitting to IESG --_000_acff618853e146eb8f5c0ab3d506d396XCH150505nwnosboeingcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Will,

 

Yes, we have been thinking about ADS-= B too. A proposal we came up with was

to include position and heading infor= mation in an IPv6 extension header:

 

https://datatracker.ietf.org/doc/draft-sk= een-6man-ipv6geo/

 

That way, we can include both user da= ta and position/heading information

in a single IPv6 packet instead of ha= ving to send multiple packets. And, unlike

ADS-B, it can be secured using IP and= /or link-layer security mechanisms.

 

Thanks - Fred

 

From: Ivancic, William D. (GRC-LCA0) [mailto:william.d.ivancic@nasa.gov]
Sent: Monday, April 25, 2016 10:09 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com>; Alexandre Pet= rescu <alexandre.petrescu@gmail.com>; its@ietf.org
Subject: Re: [its] latest charter text

 

From what I see, ITS is IPv6 ONLY items.  

 

Not DTN, but IPv6 provides potential discovery and = validation.

Not Information Centric Networking. 

Not others that are not IPv6 related.

 

I was at IETF-95, but MP-TCP and ITS were at the sa= me time.  :-(

 

It would be nice to fix ADS-B In.  But you pro= bably don’t need IPv6 to do it.  But you could.

 

I was at the Integrated Communications, Navigation = and Surveillance (I-CNS) conference last week and ask the FAA manager for t= he Next Generation Airspace System (NextGen) about ADS-B In and got a " ….. Well…. Perhaps we can’t di= scuss it in this forum. "

 

 

Really good overview.

 

 

 

Will

 

From: its <its-bounces@ie= tf.org> on behalf of "Templin, Fred L" <Fred.L.Templin@boeing.com>
Date: Monday, April 25, 2016 at 11:30 AM
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "its@ietf.org" <its@ietf= .org>
Subject: Re: [its] latest charter text

 

Hi Alex,

 

Will there be work items covering civ= il aviation and unmanned air system

use cases?

 

Thanks - Fred

 

From: its [mailto:its-bounces@ietf.or= g] On Behalf Of Alexandre Petrescu
Sent: Monday, April 25, 2016 5:01 AM
To: its@ietf.org
Subject: [its] latest charter text

 

ITSers,

You will find below the latest charter text.

It includes changes issued from discussions with Dick.

Alex
--------------------------------------------------------------------
Intelligent Transportation Systems (its)

Chairs:
   Russ Housley
   Carlos Pignataro

Assigned Area Director:
   Suresh Krishnan

Mailing list
   Address: its@ietf.org
   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 based on 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.

In general, this group is concerned with situations involving moving
network to nearby moving, or fixed, network communications (V2V, V2I,
I2V).  For example: a moving network in a vehicle communicating to
another moving network in a nearby vehicle (for C-ACC, Platooning, or
at an incident scene); a personal area network carried by a user and
connecting to an in-house fixed network (homenet); an in-car networked
device receiving messages from a road-side display when passing by,
wagon-to-wagon range extension in a train; train-to-intersection
signalling.  In these loop-free 1-IP-hop topologies there is a problem=
of establishing IP paths quickly and reliably.

Improved safety is an immediate result of hyper-connectivity of
vehicles; as such public authorities worldwide are increasingly
mandating secure communication technology requirements in vehicles.
Emergency applications for instrumented ambulances carry many benefits
both to the users and to society in general.  For these reasons, a
solution to the problem of establishing IP paths between nearby moving
networks will be resilient to threats such as eavesdropping.

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.

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.

If the group is successful in designing a simple 1-IP-hop solution for
V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then
future extensions for n-IP-hop V2V2I may be considered.

Work items
1. "Problem statement for IP in V2V and V2I"
   including "IP addressing architecture for V2V and V2I&quo= t;
   and including "Gap Analysis: IP protocols suited and gaps= "
   and including "Use-cases for IP in V2V and V2I moving net= work
   To nearby moving or fixed network"

2. "Threat Analysis for IP prefix exchanges in V2V and V2I
   Context"

3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document,
   including connectivity in fast and asymmetric conditions,
   Coverage area vs speed diagrams, below-IP congestion
   management.

4. "List of papers and _products_ using IP in V2V and V2I"

5. "Solution for direct communication between moving networks"
Goals and milestones
Oct 2016 - submit “Problem Statement” to WG
Oct 2016 - submit “List of papers and products” to WG
Feb 2017 - submit “Threat Analysis” to WG
Feb 2017 - submit “IP over DSRC (802.11-OCB)” to WG
Jun 2017 - submit “Solution for direction communication between
            &nb= sp;      moving networks” to WG
Oct 2017 - start submitting to IESG

--_000_acff618853e146eb8f5c0ab3d506d396XCH150505nwnosboeingcom_-- From nobody Mon Apr 25 12:09:14 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A13F12D69A for ; Mon, 25 Apr 2016 12:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07Vk5UHD7T1S for ; Mon, 25 Apr 2016 12:09:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537A412D69E for ; Mon, 25 Apr 2016 12:09:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A6F632002A; Mon, 25 Apr 2016 15:13:46 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DFB3663755; Mon, 25 Apr 2016 15:09:07 -0400 (EDT) From: Michael Richardson To: Russ Housley In-Reply-To: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> References: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: its@ietf.org Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 19:09:13 -0000 --=-=-= Content-Type: text/plain Russ Housley wrote: > Carlos and I had a telephone conversation with our Area Director for > this group, Suresh Krishnan. The result of the discussion was some > pretty clear and pragmatic suggestions about the charter. > The suggestion is that the ITS WG have only two deliverables in the > initial charter. Once these two documents are delivered to the IESG, > then the group can recharter to tackle other things. This charter sounds reasonable to me. Do we have enough participation from non-IETF ITS-types to actually get this done? (I mean, other than Alex P) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVx5rUYCLcPvd0N1lAQK/3Af/a0il6A7JoHqDfdFzJPP3vboGz195vwXA CyhfKlazqpmpyyB5BUwKQR0wTQO4BMSJlpKeXeerLEGnrsKvX8aQ4dkZ8E2WzV5s KzB0Jj950bXc1C+JMYISMosyCgEnS1qjTJOT/jlxBRApGL9J9lSI5PI/rA/cK+WH W2sEvIhz7VKSW3/eOPULVRdUaacKRMNX0UB03DbKOi6wqLwS/17AY+ABCr4y944e KayD/46SkwCjShP0R0BXnsWdmiXSN7jbGWpH5NO1Wjef300bcTB6OFpRuNOvnuPV Gki49IT7nieDCs8fBb2s+bDo96RIdw6FukPMW0Q0bMeqXZbsWnx+uw== =GYWV -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 25 14:06:38 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFB212D67F for ; Mon, 25 Apr 2016 14:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcEsTM3pWgad for ; Mon, 25 Apr 2016 14:06:36 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id F1E9C12D1AB for ; Mon, 25 Apr 2016 14:06:35 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id BD919F2401F; Mon, 25 Apr 2016 17:06:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id fgr62gEP6lk3; Mon, 25 Apr 2016 16:50:48 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 4C9F2F24013; Mon, 25 Apr 2016 17:06:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <8385.1461611347@obiwan.sandelman.ca> Date: Mon, 25 Apr 2016 17:06:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> <8385.1461611347@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: its@ietf.org Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 21:06:36 -0000 >> Carlos and I had a telephone conversation with our Area Director for >> this group, Suresh Krishnan. The result of the discussion was some >> pretty clear and pragmatic suggestions about the charter. >=20 >> The suggestion is that the ITS WG have only two deliverables in the >> initial charter. Once these two documents are delivered to the IESG, >> then the group can recharter to tackle other things. >=20 > This charter sounds reasonable to me. > Do we have enough participation from non-IETF ITS-types to actually = get this > done? (I mean, other than Alex P) There have been a fair number of people joining the mail list. I hope = some of them have this background needed. I would lie to hear from them = on the list. Russ From nobody Tue Apr 26 01:28:53 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EA912B058 for ; Tue, 26 Apr 2016 01:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GrvWo_brXNn for ; Tue, 26 Apr 2016 01:28:49 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BE212D0D9 for ; Tue, 26 Apr 2016 01:28:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3Q8SR2H014227; Tue, 26 Apr 2016 10:28:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8A0B42051A5; Tue, 26 Apr 2016 10:30:04 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7D8F0205040; Tue, 26 Apr 2016 10:30:04 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3Q8SPCi013652; Tue, 26 Apr 2016 10:28:26 +0200 To: "Templin, Fred L" References: <571E06FF.9060404@gmail.com> <06cb15e70fe04a07abe10678600daf8a@XCH15-05-05.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <571F26A9.80409@gmail.com> Date: Tue, 26 Apr 2016 10:28:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <06cb15e70fe04a07abe10678600daf8a@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 08:28:52 -0000 Le 25/04/2016 17:30, Templin, Fred L a écrit : > Hi Alex, > > Will there be work items covering civil aviation and unmanned air system > use cases? Hi Fred, The aviation use-case was expressed at the mic during the BoF as well. In my understanding, a use-case involving IP moving networks in planes, or in unmanned air systems, do make sense. Because it is similar to drones docked on automobiles, which have been demonstrated often. However, the IESG suggestion is to focus now on ITS (V2V/V2I) and IPv6 over DSRC. For "later" (if successful with the above): - are there use-cases of civil aviation and unmanned air systems which involve DSRC; - is civil aviation considering IPv6 in use-cases of Plane-to-Ground or Plane-to-Plane communications. - what is the name of links that are specific to civil aviation and unmanned air systems and has IPv6 been run on it. Alex > > Thanks - Fred > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre Petrescu > *Sent:* Monday, April 25, 2016 5:01 AM > *To:* its@ietf.org > *Subject:* [its] latest charter text > > ITSers, > > You will find below the latest charter text. > > It includes changes issued from discussions with Dick. > > Alex > -------------------------------------------------------------------- > Intelligent Transportation Systems (its) > > Chairs: > Russ Housley > Carlos Pignataro > > Assigned Area Director: > Suresh Krishnan > > Mailing list > Address: its@ietf.org > 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 based on 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. > > In general, this group is concerned with situations involving moving > network to nearby moving, or fixed, network communications (V2V, V2I, > I2V). For example: a moving network in a vehicle communicating to > another moving network in a nearby vehicle (for C-ACC, Platooning, or > at an incident scene); a personal area network carried by a user and > connecting to an in-house fixed network (homenet); an in-car networked > device receiving messages from a road-side display when passing by, > wagon-to-wagon range extension in a train; train-to-intersection > signalling. In these loop-free 1-IP-hop topologies there is a problem > of establishing IP paths quickly and reliably. > > Improved safety is an immediate result of hyper-connectivity of > vehicles; as such public authorities worldwide are increasingly > mandating secure communication technology requirements in vehicles. > Emergency applications for instrumented ambulances carry many benefits > both to the users and to society in general. For these reasons, a > solution to the problem of establishing IP paths between nearby moving > networks will be resilient to threats such as eavesdropping. > > 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. > > 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. > > If the group is successful in designing a simple 1-IP-hop solution for > V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then > future extensions for n-IP-hop V2V2I may be considered. > > Work items > 1. "Problem statement for IP in V2V and V2I" > including "IP addressing architecture for V2V and V2I" > and including "Gap Analysis: IP protocols suited and gaps" > and including "Use-cases for IP in V2V and V2I moving network > To nearby moving or fixed network" > > 2. "Threat Analysis for IP prefix exchanges in V2V and V2I > Context" > > 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document, > including connectivity in fast and asymmetric conditions, > Coverage area vs speed diagrams, below-IP congestion > management. > > 4. "List of papers and _products_ using IP in V2V and V2I" > > 5. "Solution for direct communication between moving networks" > > Goals and milestones > Oct 2016 - submit “Problem Statement” to WG > Oct 2016 - submit “List of papers and products” to WG > Feb 2017 - submit “Threat Analysis” to WG > Feb 2017 - submit “IP over DSRC (802.11-OCB)” to WG > Jun 2017 - submit “Solution for direction communication between > moving networks” to WG > Oct 2017 - start submitting to IESG > From nobody Tue Apr 26 01:34:13 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2288112D0D9 for ; Tue, 26 Apr 2016 01:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.353 X-Spam-Level: X-Spam-Status: No, score=-4.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rm6ZPzqXo7vM for ; Tue, 26 Apr 2016 01:34:05 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485C712B03E for ; Tue, 26 Apr 2016 01:34:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3Q8Y2TV017191; Tue, 26 Apr 2016 10:34:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B1D8520520B; Tue, 26 Apr 2016 10:35:39 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A4C1D2050B8; Tue, 26 Apr 2016 10:35:39 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3Q8Y2Ht022208; Tue, 26 Apr 2016 10:34:02 +0200 To: Jong-Hyouk Lee References: <571E06FF.9060404@gmail.com> <49C8475F-8C77-4272-B227-CAF681B066F4@gmail.com> From: Alexandre Petrescu Message-ID: <571F27FA.40509@gmail.com> Date: Tue, 26 Apr 2016 10:34:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <49C8475F-8C77-4272-B227-CAF681B066F4@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 08:34:12 -0000 Hi Jong-Hyouk, You have seen the recommendation from IESG. The ISO TC204 request can be understood together with the IESG recommendation, if we try. We can write IPv6-over-DSRC such as to satisfy some parts of the ISO TC204 request as well. You were one of the earliest to say, verbally, that IPv6 runs ok over 802.11p - why dont you put that in an I-D? Otherwise, we can save the MNPP behaviour for later anyways. Alex Le 25/04/2016 14:45, Jong-Hyouk Lee a écrit : > Hi Alex, > > As the work item “Solution for direction communication between moving > networks” is one of explicit requests from ISO TC204, it is better to > put the work item on a priority. > > J. > -- > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > Protocol Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com > #webpage: https://sites.google.com/site/hurryon > >> On Apr 25, 2016, at 9:01 PM, Alexandre Petrescu >> > >> wrote: >> >> ITSers, >> >> You will find below the latest charter text. >> >> It includes changes issued from discussions with Dick. >> >> Alex >> -------------------------------------------------------------------- >> Intelligent Transportation Systems (its) >> >> Chairs: >> Russ Housley >> Carlos Pignataro >> >> Assigned Area Director: >> Suresh Krishnan >> >> Mailing list >> Address: its@ietf.org >> 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 based on 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. >> >> In general, this group is concerned with situations involving moving >> network to nearby moving, or fixed, network communications (V2V, V2I, >> I2V). For example: a moving network in a vehicle communicating to >> another moving network in a nearby vehicle (for C-ACC, Platooning, or >> at an incident scene); a personal area network carried by a user and >> connecting to an in-house fixed network (homenet); an in-car networked >> device receiving messages from a road-side display when passing by, >> wagon-to-wagon range extension in a train; train-to-intersection >> signalling. In these loop-free 1-IP-hop topologies there is a problem >> of establishing IP paths quickly and reliably. >> >> Improved safety is an immediate result of hyper-connectivity of >> vehicles; as such public authorities worldwide are increasingly >> mandating secure communication technology requirements in vehicles. >> Emergency applications for instrumented ambulances carry many benefits >> both to the users and to society in general. For these reasons, a >> solution to the problem of establishing IP paths between nearby moving >> networks will be resilient to threats such as eavesdropping. >> >> 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. >> >> 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. >> >> If the group is successful in designing a simple 1-IP-hop solution for >> V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then >> future extensions for n-IP-hop V2V2I may be considered. >> >> Work items >> 1. "Problem statement for IP in V2V and V2I" >> including "IP addressing architecture for V2V and V2I" >> and including "Gap Analysis: IP protocols suited and gaps" >> and including "Use-cases for IP in V2V and V2I moving network >> To nearby moving or fixed network" >> >> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >> Context" >> >> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document, >> including connectivity in fast and asymmetric conditions, >> Coverage area vs speed diagrams, below-IP congestion >> management. >> >> 4. "List of papers and _products_ using IP in V2V and V2I" >> >> 5. "Solution for direct communication between moving networks" >> >> Goals and milestones >> Oct 2016 - submit “Problem Statement” to WG >> Oct 2016 - submit “List of papers and products” to WG >> Feb 2017 - submit “Threat Analysis” to WG >> Feb 2017 - submit “IP over DSRC (802.11-OCB)” to WG >> Jun 2017 - submit “Solution for direction communication between >> moving networks” to WG >> Oct 2017 - start submitting to IESG >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > From nobody Tue Apr 26 01:45:18 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9C812D0FC for ; Tue, 26 Apr 2016 01:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nn-4iS4EYN8c for ; Tue, 26 Apr 2016 01:45:14 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C181A12D0D9 for ; Tue, 26 Apr 2016 01:45:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3Q8j84d022972; Tue, 26 Apr 2016 10:45:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 406B9205256; Tue, 26 Apr 2016 10:46:45 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3117F2051C3; Tue, 26 Apr 2016 10:46:45 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3Q8j79v004152; Tue, 26 Apr 2016 10:45:07 +0200 To: "Ivancic, William D. (GRC-LCA0)" , "Templin, Fred L" , "its@ietf.org" References: <571E06FF.9060404@gmail.com> <06cb15e70fe04a07abe10678600daf8a@XCH15-05-05.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <571F2A93.8000004@gmail.com> Date: Tue, 26 Apr 2016 10:45:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 08:45:17 -0000 Le 25/04/2016 19:09, Ivancic, William D. (GRC-LCA0) a crit : [...] > It would be nice to fix ADS-B In. But you probably dont need IPv6 to > do it. But you could. [...] ADS-B: Automatic dependent surveillance broadcast; a method by which plane tells everybody around where it is (such that we dont find ourselves again desperately seeking MH370). This is an application which can be run over UDP, and over IP. If you do it with IP (rathern than just radio broadcast) then you get some advantages, e.g. easy integration in databases and immediate availability to qualified experts. Seismographic data, thunder strike data, and similar, are other examples which moved from analogous to Internet. This can be possible if we have IP-over-ADS-B. ButI suppose ADS-B is very much different than DSRC? Alex > > I was at the Integrated Communications, Navigation and Surveillance > (I-CNS) conference last week and ask the FAA manager for the Next > Generation Airspace System (NextGen) about ADS-B In and got a " .. > Well. Perhaps we cant discuss it in this forum. " > > > Really good overview. > https://media.blackhat.com/bh-us-12/Briefings/Costin/BH_US_12_Costin_Ghosts_In_Air_Slides.pdf > > https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0ahUKEwiWjdL1oarMAhWPQD4KHT0pCG0QtwIIKTAC&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DmY2uiLfXmaI&usg=AFQjCNGnegT_l8lQ7MLE74MYFG5VZv4iMQ&sig2=XD6tloGhoGfFQvu3vgFFvg > > > Will > > From: its > on behalf > of "Templin, Fred L" > > Date: Monday, April 25, 2016 at 11:30 AM > To: Alexandre Petrescu >, "its@ietf.org > " > > Subject: Re: [its] latest charter text > > Hi Alex, > > Will there be work items covering civil aviation and unmanned air system > > use cases? > > Thanks - Fred > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre > Petrescu > *Sent:* Monday, April 25, 2016 5:01 AM > *To:* its@ietf.org > *Subject:* [its] latest charter text > > ITSers, > > You will find below the latest charter text. > > It includes changes issued from discussions with Dick. > > Alex > -------------------------------------------------------------------- > Intelligent Transportation Systems (its) > > Chairs: > Russ Housley > Carlos Pignataro > > Assigned Area Director: > Suresh Krishnan > > Mailing list > Address: its@ietf.org > 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 based on 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. > > In general, this group is concerned with situations involving moving > network to nearby moving, or fixed, network communications (V2V, V2I, > I2V). For example: a moving network in a vehicle communicating to > another moving network in a nearby vehicle (for C-ACC, Platooning, or > at an incident scene); a personal area network carried by a user and > connecting to an in-house fixed network (homenet); an in-car networked > device receiving messages from a road-side display when passing by, > wagon-to-wagon range extension in a train; train-to-intersection > signalling. In these loop-free 1-IP-hop topologies there is a problem > of establishing IP paths quickly and reliably. > > Improved safety is an immediate result of hyper-connectivity of > vehicles; as such public authorities worldwide are increasingly > mandating secure communication technology requirements in vehicles. > Emergency applications for instrumented ambulances carry many benefits > both to the users and to society in general. For these reasons, a > solution to the problem of establishing IP paths between nearby moving > networks will be resilient to threats such as eavesdropping. > > 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. > > 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. > > If the group is successful in designing a simple 1-IP-hop solution for > V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then > future extensions for n-IP-hop V2V2I may be considered. > > Work items > 1. "Problem statement for IP in V2V and V2I" > including "IP addressing architecture for V2V and V2I" > and including "Gap Analysis: IP protocols suited and gaps" > and including "Use-cases for IP in V2V and V2I moving network > To nearby moving or fixed network" > > 2. "Threat Analysis for IP prefix exchanges in V2V and V2I > Context" > > 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document, > including connectivity in fast and asymmetric conditions, > Coverage area vs speed diagrams, below-IP congestion > management. > > 4. "List of papers and _products_ using IP in V2V and V2I" > > 5. "Solution for direct communication between moving networks" > > Goals and milestones > Oct 2016 - submit Problem Statement to WG > Oct 2016 - submit List of papers and products to WG > Feb 2017 - submit Threat Analysis to WG > Feb 2017 - submit IP over DSRC (802.11-OCB) to WG > Jun 2017 - submit Solution for direction communication between > moving networks to WG > Oct 2017 - start submitting to IESG > From nobody Tue Apr 26 02:27:18 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4097112D0DB for ; Tue, 26 Apr 2016 02:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCyyNZg3FNa6 for ; Tue, 26 Apr 2016 02:27:14 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E36A12B069 for ; Tue, 26 Apr 2016 02:27:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3Q9RBt1012539; Tue, 26 Apr 2016 11:27:11 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 05168205321; Tue, 26 Apr 2016 11:28:49 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EBAD320530E; Tue, 26 Apr 2016 11:28:48 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3Q9RB5t026554; Tue, 26 Apr 2016 11:27:11 +0200 To: Lei Chen References: <544A6D4F.3060401@gmail.com> <544E5FE4.4000503@gmail.com> From: Alexandru Petrescu Message-ID: <571F346F.6060500@gmail.com> Date: Tue, 26 Apr 2016 11:27:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] 802.11p and gcdc 2016 (was: long ago) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 09:27:17 -0000 Hi Lei, I hope the GCDC 2016 plan is advancing well. Any idea what are the 802.11p drivers people will use at this event? Is now 802.11p integrated in the mainline kernel? Yours, Alex Le 27/10/2014 18:24, Lei Chen a écrit : > Dear Alex, > > Thanks very much for the detailed explanation and also the > opportunity to share with our community about GCDC 2016. > > Please see the following for details. > > Best regards, Lei > >> On 27 Oct 2014, at 16:08, Alexandru Petrescu >> wrote: >> >> Dear Lei Chen, >> >> Thank you for the reply. >> >> Le 27/10/2014 14:03, Lei Chen a écrit : >>> Dear all, >>> >>> Just a bit self introduction, we are working on the second >>> edition of cooperative driving challenge (www.gcdc.net >>> ) and somehow we came across the same topics >>> here. >> >> GCDC is the same organization that issued the first freely >> available 802.11p driver? > > Last time, GCDC implemented 802.11p thanks to the work with Eric > Koenders. It is open-source, I hope that is the same one you are > talking about. >> >>> Thanks to Alex to bring this topic up, it is very relevant for >>> the platoon applications. >>> >>> Basically, like Andras and John said, V2V through DSRC will be >>> the first implementation for initial application of platooning. >>> IP will most probably be used for Day2 applications that require >>> more data communications, for example, video streaming between >>> platoon vehicles or LDM. >> >> [LDM? (light-based communications, LiFi?)] > > Sorry for that, LDM = local dynamic map. Using DSRC and based on CAM > messages, LDM is able to be constructed, but if we consider more > accurate and complex LDM for environmental perception, I would say IP > will be needed. > >> >> I am happy to see IP communications are considered, even that is in >> the second day. I personally do not worry very much of being maybe >> later, because I think IP will support more applications, currently >> unspoken of. >> >>> It seems ETSI does this with an adaption layer (EN302 636-6-1, >>> TS102 636-6-1) for IPv6 to work with GeoNet. >> >> Yes, there is an adaptation layer for IPv6 and geonet. It may be >> highly necessary in the initial steps of bringing IPv6 as close as >> possible to the deployment. >> >> IPv6-straight-over-80211p also uses an Adaptation Layer (the >> Ethernet Adaptation Layer used by 802.11b). >> >>> Anyway, GeoNet seems to be in the protocol stack for C-ITS no >>> matter what. >> >> Thanks for the remark. It is true that GeoNet of ETSI ITS is >> present there but one should distinguish the cases where it is >> absolutely necessary - something else can not do its role. These >> cases are the communications depending extensively on location: >> geo-dissemination, etc. >> > > Absolutely agree! In general, for infotainment application or less > time critical applications, IP network (LTE for example) will be the > best choice. However, for time critical applications or as you said, > geo-dependent applications, GeoNet over 802.11p may be necessary, at > least for the near future applications. If we consider further with > 5G, where the latency is expected to be significantly reduced, I > guess everything can be done through IP. But it is hard to draw > conclusions about it at the current stage. Anyway,I guess the > cross-layer Decentralized Congestion Control (DCC) in C-ITS should be > able to take care of this based on the QoS requirement at the > application layer and direct the traffic to appropriate transport and > access methods, at least it is supposed to do this. > >>> If IPv6 is considered, then the transport layer will be TCP/UDP >>> over IPv6 over GeoNet, though I am not sure about the protocol >>> overhead. It is an interesting issue to investigate. >> >> Yes, it is an issue to investigate. >> >> At IETF there is a document called IPv6-over-80211p that I author. >> The ideas expressed in this document could be used in this >> investigation. The document itself lacks certain aspects that >> anyone interested could contribute. > > Thanks, I am checking with the document, I would say IPv6 over > 802.11p is absolutely an option and we are investigating the > possibilities. I hope we can also contribute to this topic. > >> >>> For platooning in Day1 applications, GeoNet (BTP and GeoNet for >>> transport) over G5 maybe the most appropriate choice at the >>> current stage because of the advantages of time delay. >> >> Not sure what you mean by 'time delay'? >> >> If you mean latency between vehicles, then I think 802.11p gives >> better latency, in the order of tens of millseconds. >> >> Or you mean that products implementing ETSI ITS GeoNet have a time >> advantage being already there? If so then I agree with you. > > Yes, it is latency. 802.11p based access generally have better > latency, and a light weight BTP&GeoNet also contributes to the > latency issue. I guess IP over 802.11p may achieve similar latency > performance, though I need to check a bit more over that. As for IPv6 > over GeoNet over 802.11p, as we already mentioned, the overhead is > worth investigating further. It is also one topic we will look at. > >> >>> We are looking at different implementations of GeoNet for >>> potential deployment in GCDC. As we work towards Day2 >>> applications, IPv6 is potentially considered. INRIA has been >>> working on the implementation through CarGeo6. If you guys have >>> more information about the implementation now, it is very >>> appreciated that you share with us. >> >> Sure, certainly. I downloaded CarGeo6 and looked at the code. I >> have the feeling that with it a car sends its position to another >> car. >> >> At my place we have another implementation of exchanging IPv6 >> routing information over 802.11p. We also have an update version >> of the original 802.11p GCDC driver for most recent linux kernels >> as well as other reliability improvements. >> > We are investigating CarGeo6 now. But it is very interesting you have > an update version of the 802.11p protocol. I am not sure if you > already make it open source or not. If so, it will be absolutely a > great help for us to check the possibilities of applying IPv6 over > 802.11p. Could you indicate me how and where I can check and then I > can talk with my colleagues both at Viktoria and TNO for further > discussions? If we prove the performance with IP over 802.11p during > the challenge, I would say that will be a great contribution to > C-ITS, at least for some part. Thanks very much beforehand:-) > >>> Also, if you know teams that want to show their implementations >>> of cooperative driving to the world, GCDC 2016 is the place to >>> go. They are free to contact us for registration or check >>> www.gcdc.net for details. >> >> YEs, this is a good announcement. Please state here what are the >> participating conditions - is it free to join, what are the fees >> involved, in which country is it happening. > > Thanks Alex, it is my pleasure to share with our community the > announcement. > > GCDC2016, or i-GAME (www.gcdc.net) is the second edition of GCDC > based on its success in 2011 and with the purpose to accelerate > cooperative driving through public challenge. GCDC2016 will mainly > focus on the interoperability of communications, e.g. communications > are vendor independent and teams are very welcome to implement based > on different equipments from different vendors . However, the > communications protocol will align to the latest C-ITS standards > (Release 1) and potentially will contribute to Release 2. > > It is totally free to join the challenge and in addition to that, > teams will get support from organizers (TNO and TU/e from holland, > Viktoria Swedish ICT from Sweden and IDIADA from Spain). The final > challenge will be Q2 2016 at the test site in Helmond in Holland, > exactly the same test site as GCDC 2011. GCDC2016 have two challenge > scenarios and one demo scenario. Challenge scenarios include both > urban (intersection passing) and highway (platoon merge due to > roadwork). Demo scenario is about emergency vehicle passing. All > scenarios are defined to be close to reality and the implementations > are also expected to be as close-to market as possible. We want to > show the benefits of cooperative driving and also raise the awareness > from both government and public. > > The call on registrations is on-going. Notice that the registration > is not binding at this stage. Teams can show interest and ask for > further information and if possible, the organizers may help to > assist to find partners. Teams are also very welcome to contribute to > the implementation of communication protocols together with us. Just > drop us emails :-) > > For those who are interested, some general requirements are as > follows, •A vehicle that will be fitted with the requirements > •Minimum longitudinal automation •Interoperable V2X communication and > interaction – will be tested both remotely online and physically at > the challenge site •Drivers are in the vehicles, safety is critical > •Drivers and support crew •Budget for travel, transport and > subsistence •Taking part in preparative workshops and the rigorous > functional testing before the challenge •Be ready by Spring 2016! > > In return, the teams will get •Once in a lifetime opportunity to work > with universities, OEMs and authorities to forward the state of > cooperative autonomous driving •Get in contact with world class > companies and people in this field •Collaborate at the forefront of > standardization efforts •Help your institution learn and build its > reputation •Win the challenge and eternal fame! > > Just a video introduction of last time’s challenge > (https://www.youtube.com/watch?v=lmRifLzw8iA) for those who are > interested. Teams now can register at www.gcdc.net or contact the > following people. > > For registration and team information: l.r.r.schrijnemakers@tue.nl > (Laurens Schrijnemakers) > > For project information and collaboration: sander.maas@tno.nl (Sander > Maas) > > We sincerely look forward for teams from all over the world to > participate :) > >> >> Alex >> >>> >>> Best regards, Lei >>> >>> >>> *Lei Chen, PhD* Senior Researcher Cooperative Systems >>> >>> >>> >>> *Viktoria Swedish ICT AB* Lindholmspiren 3A SE-417 56 Göteborg, >>> Sweden Tel: +46 76 777 1449 E-mail: lei.chen@viktoria.se >>> www.viktoria.se >>> >>> Part of RISE >>> >>>> On 27 Oct 2014, at 12:22, Varadi , Andras (lesswire AG Ungarn) >>>> > wrote: >>>> >>>> Dear Alex, John I agree with John, but would like to point out >>>> that I think its likely that we will need to extend EU >>>> Geonetworking (EN 302 636) to work over IP (e.g. LTE) links >>>> also. I think we will have such requirements for EU Day2 or 3 >>>> (2^nd , Third generation C-ITS) (example: update our Local >>>> Dynamic Map with a new Warning message received over cellular >>>> connection (not G5/11p)) Üdvözlettel / Best regards, András >>>> Váradi Project Manager – C2X/ITS Systems >>>> >>>> Automotive & WLAN Group lesswire Hungary***|***Office: +36 >>>> 23521 667***|***Email:Varadi@lesswire.com >>>> *From:*its >>>> [mailto:its-bounces@ietf.org]*On Behalf Of*John Kenney >>>> *Sent:*Saturday, October 25, 2014 1:45 AM *To:*Alexandru >>>> Petrescu *Cc:*its@ietf.org *Subject:*Re: >>>> [geonet/its] FYI - ETSI ITS - work on cooperative cruise >>>> control, platooning Hi Alex, Thanks for sharing this. I think >>>> many of us in the DSRC/Cooperative ITS community consider these >>>> two applications to be a very natural fit for the technology. >>>> Furthermore, my expectation is that the applications can work >>>> well with one-hop V2V communication of the type that does not >>>> typically use IP. So, I don't see a benefit of including IP. >>>> That doesn't mean it wouldn't work, but as you know the DSRC >>>> community generally plans to use a lighter weight protocol, >>>> WSMP, for applications that do not need IP. I expect ETSI will >>>> think along similar lines. Best Regards, John -- John Kenney >>>> Principal Researcher Toyota InfoTechnology Center, USA 465 >>>> Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. >>>> Mobile: 650-224-6644 On Fri, Oct 24, 2014 at 8:16 AM, Alexandru >>>> Petrescu >>> > wrote: Hello >>>> geonet/itsers, >>>> >>>> ETSI ITS group is an SDO in Europe. They produced many >>>> standards in the past for vehicular communications, e.g. ETSI >>>> ITS geo-networking among others. >>>> >>>> ETSI ITS recently agreed to start working on >>>> pre-standardization items called "Cooperative Cruise Control" >>>> and "Platooning". These two applications make automobiles (and >>>> trucks) talk to each other continuously to keep speed constant. >>>> It helps relieve automobile driver stress in jam situation or >>>> reduce gas consumption by 'platooning'. >>>> >>>> Currently the focus is on requirements including communication >>>> requirements. >>>> >>>> In my oppinion, and this is why I forward it to this group, >>>> establishing direct IP connections between vehicles may open >>>> paths for exchanging IP data containing speed/location and >>>> trigger a control process of adapting the speed. One already >>>> controls vehicles by sending IP data to them, from the >>>> infrastructure. It would be a simple matter for IP experts to >>>> send that same data from other vehicle, without going to the >>>> infrastructure. >>>> >>>> Thoughts? >>>> >>>> Yours, >>>> >>>> Alex >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Tue Apr 26 04:11:08 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EB912D14B for ; Tue, 26 Apr 2016 04:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uwGa1DWdhie for ; Tue, 26 Apr 2016 04:11:02 -0700 (PDT) Received: from mail.it-partner.se (owa.it-partner.se [195.211.132.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0723112B069 for ; Tue, 26 Apr 2016 04:11:01 -0700 (PDT) Received: from evryitpmb1.it-partner.se (172.17.212.120) by evryitpmb1.it-partner.se (172.17.212.120) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 26 Apr 2016 13:10:56 +0200 Received: from evryitpmb1.it-partner.se ([::1]) by evryitpmb1.it-partner.se ([::1]) with mapi id 15.00.0913.011; Tue, 26 Apr 2016 13:10:56 +0200 From: Lei Chen To: Alexandru Petrescu Thread-Topic: 802.11p and gcdc 2016 (was: long ago) Thread-Index: AQHRn53SY5VKAH5Ir02NH/E8aLVW4p+b99kA Date: Tue, 26 Apr 2016 11:10:56 +0000 Message-ID: <7DA761D0-F7E3-4438-AB58-F989B430E321@viktoria.se> References: <544A6D4F.3060401@gmail.com> <544E5FE4.4000503@gmail.com> <571F346F.6060500@gmail.com> In-Reply-To: <571F346F.6060500@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.16.145.8] Content-Type: multipart/related; boundary="_004_7DA761D0F7E34438AB58F989B430E321viktoriase_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] 802.11p and gcdc 2016 (was: long ago) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 11:11:07 -0000 --_004_7DA761D0F7E34438AB58F989B430E321viktoriase_ Content-Type: multipart/alternative; boundary="_000_7DA761D0F7E34438AB58F989B430E321viktoriase_" --_000_7DA761D0F7E34438AB58F989B430E321viktoriase_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEFsZXgsIGl0IGlzIGdvaW5nIHdlbGwgd2l0aCBHQ0RDMjAxNi4gV2UgaGF2ZSBzdWNj ZXNzZnVsbHkgY29uZHVjdGVkIHNhZmV0eSBhbmQgY29tbXVuaWNhdGlvbiB0ZXN0IGF0IHRoZSB0 aGUgdGVzdCBzaXRlIGluIElESUFEQS4gIFdlIGFyZSBub3cgYXQgdGhlIGZpbmFsIHN0YWdlIG9m IHBsYW5uaW5nIGFuZCB0aGUgQ2hhbGxlbmdlIHdpbGwgYmUgb24gMjggLSAyOSBNYXkuIFRoZXJl IHdpbGwgYWxzbyBiZSBvbmUgd2VlayBwcmVwYXJhdGlvbiB3b3Jrc2hvcCBhdCBIZWxtb25kLCBh bmQgb25lIGRheSBjb25ncmVzcyBmb2xsb3dpbmcgdGhlIGNoYWxsZW5nZS4NCg0KVGhlIDgwMi4x MXAgZHJpdmVycyBpcyB0aGUgb25lIG1vZGlmaWVkIGJ5IENUVS1JSUcgKGh0dHBzOi8vZ2l0aHVi LmNvbS9DVFUtSUlHKS4gQXMgZGVzY3JpYmVkIGhlcmUgKGh0dHBzOi8vZ2l0aHViLmNvbS9hbGV4 dm9yb25vdi9nZW9uZXR3b3JraW5nL2Jsb2IvbWFzdGVyL0hBUkRXQVJFLm1kKSB3aXRoIG15IGNv bGxlYWd1ZSBBbGV4LCBpdCBzZWVtcyA4MDIuMTFwIGlzIG5vdCB5ZXQgdmVyeSB3ZWxsIGludGVn cmF0ZWQuIEFuZCBHQ0RDIHByb3ZpZGVzIHdpdGggYSBzdGVwIGJ5IHN0ZXAgaW5zdGFsbGF0aW9u IGd1aWRlIGZvciA4MDIuMTFwIG9uIEFMSVggQVBVMUQgcnVubmluZyBWb3lhZ2UuIEFsbCBpbmZv cm1hdGlvbiBjYW4gYmUgZm91bmQgYXQgR0NEQyBzaXRlIChodHRwOi8vZ2NkYy5uZXQvZW4vKS4N Cg0KQWdhaW4sIHdlIHRha2UgdGhlIG9wcG9ydHVuaXR5IHRvIGludml0ZSBhbGwgSVRTIGV4cGVy dHMgdG8gY29tZSBhbmQgam9pbiB0aGUgY2hhbGxlbmdlLiBQcm9taXNlIGl0IHdpbGwgYmUgZXhj aXRpbmcuDQoNCkJSDQpMZWkNCg0KT24gMjYgQXByIDIwMTYsIGF0IDExOjI3LCBBbGV4YW5kcnUg UGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb208bWFpbHRvOmFsZXhhbmRydS5w ZXRyZXNjdUBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGkgTGVpLA0KDQpJIGhvcGUgdGhlIEdDREMg MjAxNiBwbGFuIGlzIGFkdmFuY2luZyB3ZWxsLg0KDQpBbnkgaWRlYSB3aGF0IGFyZSB0aGUgODAy LjExcCBkcml2ZXJzIHBlb3BsZSB3aWxsIHVzZSBhdCB0aGlzIGV2ZW50PyAgSXMgbm93IDgwMi4x MXAgaW50ZWdyYXRlZCBpbiB0aGUgbWFpbmxpbmUga2VybmVsPw0KDQpZb3VycywNCg0KQWxleA0K DQoNCg0KTGUgMjcvMTAvMjAxNCAxODoyNCwgTGVpIENoZW4gYSDDqWNyaXQgOg0KRGVhciBBbGV4 LA0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciB0aGUgZGV0YWlsZWQgZXhwbGFuYXRpb24gYW5kIGFs c28gdGhlDQpvcHBvcnR1bml0eSB0byBzaGFyZSB3aXRoIG91ciBjb21tdW5pdHkgYWJvdXQgR0NE QyAyMDE2Lg0KDQpQbGVhc2Ugc2VlIHRoZSBmb2xsb3dpbmcgZm9yIGRldGFpbHMuDQoNCkJlc3Qg cmVnYXJkcywgTGVpDQoNCk9uIDI3IE9jdCAyMDE0LCBhdCAxNjowOCwgQWxleGFuZHJ1IFBldHJl c2N1DQo8YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbTxtYWlsdG86YWxleGFuZHJ1LnBldHJl c2N1QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpEZWFyIExlaSBDaGVuLA0KDQpUaGFuayB5b3UgZm9y IHRoZSByZXBseS4NCg0KTGUgMjcvMTAvMjAxNCAxNDowMywgTGVpIENoZW4gYSDDqWNyaXQgOg0K RGVhciBhbGwsDQoNCkp1c3QgYSBiaXQgc2VsZiBpbnRyb2R1Y3Rpb24sIHdlIGFyZSB3b3JraW5n IG9uIHRoZSBzZWNvbmQNCmVkaXRpb24gb2YgY29vcGVyYXRpdmUgZHJpdmluZyBjaGFsbGVuZ2Ug KHd3dy5nY2RjLm5ldDxodHRwOi8vd3d3LmdjZGMubmV0Pg0KPGh0dHA6Ly93d3cuZ2NkYy5uZXQ+ KSBhbmQgc29tZWhvdyB3ZSBjYW1lIGFjcm9zcyB0aGUgc2FtZSB0b3BpY3MNCmhlcmUuDQoNCkdD REMgaXMgdGhlIHNhbWUgb3JnYW5pemF0aW9uIHRoYXQgaXNzdWVkIHRoZSBmaXJzdCBmcmVlbHkN CmF2YWlsYWJsZSA4MDIuMTFwIGRyaXZlcj8NCg0KTGFzdCB0aW1lLCBHQ0RDIGltcGxlbWVudGVk IDgwMi4xMXAgdGhhbmtzIHRvIHRoZSB3b3JrIHdpdGggRXJpYw0KS29lbmRlcnMuIEl0IGlzIG9w ZW4tc291cmNlLCBJIGhvcGUgdGhhdCBpcyB0aGUgc2FtZSBvbmUgeW91IGFyZQ0KdGFsa2luZyBh Ym91dC4NCg0KVGhhbmtzIHRvIEFsZXggdG8gYnJpbmcgdGhpcyB0b3BpYyB1cCwgaXQgaXMgdmVy eSByZWxldmFudCBmb3INCnRoZSBwbGF0b29uIGFwcGxpY2F0aW9ucy4NCg0KQmFzaWNhbGx5LCBs aWtlIEFuZHJhcyBhbmQgSm9obiBzYWlkLCBWMlYgdGhyb3VnaCBEU1JDIHdpbGwgYmUNCnRoZSBm aXJzdCBpbXBsZW1lbnRhdGlvbiBmb3IgaW5pdGlhbCBhcHBsaWNhdGlvbiBvZiBwbGF0b29uaW5n Lg0KSVAgd2lsbCBtb3N0IHByb2JhYmx5IGJlIHVzZWQgZm9yIERheTIgYXBwbGljYXRpb25zIHRo YXQgcmVxdWlyZQ0KbW9yZSBkYXRhIGNvbW11bmljYXRpb25zLCBmb3IgZXhhbXBsZSwgdmlkZW8g c3RyZWFtaW5nIGJldHdlZW4NCnBsYXRvb24gdmVoaWNsZXMgb3IgTERNLg0KDQpbTERNPyAgKGxp Z2h0LWJhc2VkIGNvbW11bmljYXRpb25zLCBMaUZpPyldDQoNClNvcnJ5IGZvciB0aGF0LCAgTERN ID0gbG9jYWwgZHluYW1pYyBtYXAuIFVzaW5nIERTUkMgYW5kIGJhc2VkIG9uIENBTQ0KbWVzc2Fn ZXMsIExETSBpcyBhYmxlIHRvIGJlIGNvbnN0cnVjdGVkLCBidXQgaWYgd2UgY29uc2lkZXIgbW9y ZQ0KYWNjdXJhdGUgYW5kIGNvbXBsZXggTERNIGZvciBlbnZpcm9ubWVudGFsIHBlcmNlcHRpb24s IEkgd291bGQgc2F5IElQDQp3aWxsIGJlIG5lZWRlZC4NCg0KDQpJIGFtIGhhcHB5IHRvIHNlZSBJ UCBjb21tdW5pY2F0aW9ucyBhcmUgY29uc2lkZXJlZCwgZXZlbiB0aGF0IGlzIGluDQp0aGUgc2Vj b25kIGRheS4gIEkgcGVyc29uYWxseSBkbyBub3Qgd29ycnkgdmVyeSBtdWNoIG9mIGJlaW5nIG1h eWJlDQpsYXRlciwgYmVjYXVzZSBJIHRoaW5rIElQIHdpbGwgc3VwcG9ydCBtb3JlIGFwcGxpY2F0 aW9ucywgY3VycmVudGx5DQp1bnNwb2tlbiBvZi4NCg0KSXQgc2VlbXMgRVRTSSBkb2VzIHRoaXMg d2l0aCBhbiBhZGFwdGlvbiBsYXllciAoRU4zMDIgNjM2LTYtMSwNClRTMTAyIDYzNi02LTEpIGZv ciBJUHY2IHRvIHdvcmsgd2l0aCBHZW9OZXQuDQoNClllcywgdGhlcmUgaXMgYW4gYWRhcHRhdGlv biBsYXllciBmb3IgSVB2NiBhbmQgZ2VvbmV0LiAgSXQgbWF5IGJlDQpoaWdobHkgbmVjZXNzYXJ5 IGluIHRoZSBpbml0aWFsIHN0ZXBzIG9mIGJyaW5naW5nIElQdjYgYXMgY2xvc2UgYXMNCnBvc3Np YmxlIHRvIHRoZSBkZXBsb3ltZW50Lg0KDQpJUHY2LXN0cmFpZ2h0LW92ZXItODAyMTFwIGFsc28g dXNlcyBhbiBBZGFwdGF0aW9uIExheWVyICh0aGUNCkV0aGVybmV0IEFkYXB0YXRpb24gTGF5ZXIg dXNlZCBieSA4MDIuMTFiKS4NCg0KQW55d2F5LCBHZW9OZXQgc2VlbXMgdG8gYmUgaW4gdGhlIHBy b3RvY29sIHN0YWNrIGZvciBDLUlUUyBubw0KbWF0dGVyIHdoYXQuDQoNClRoYW5rcyBmb3IgdGhl IHJlbWFyay4gIEl0IGlzIHRydWUgdGhhdCBHZW9OZXQgb2YgRVRTSSBJVFMgaXMNCnByZXNlbnQg dGhlcmUgYnV0IG9uZSBzaG91bGQgZGlzdGluZ3Vpc2ggdGhlIGNhc2VzIHdoZXJlIGl0IGlzDQph YnNvbHV0ZWx5IG5lY2Vzc2FyeSAtIHNvbWV0aGluZyBlbHNlIGNhbiBub3QgZG8gaXRzIHJvbGUu ICBUaGVzZQ0KY2FzZXMgYXJlIHRoZSBjb21tdW5pY2F0aW9ucyBkZXBlbmRpbmcgZXh0ZW5zaXZl bHkgb24gbG9jYXRpb246DQpnZW8tZGlzc2VtaW5hdGlvbiwgZXRjLg0KDQoNCkFic29sdXRlbHkg YWdyZWUhIEluIGdlbmVyYWwsIGZvciBpbmZvdGFpbm1lbnQgYXBwbGljYXRpb24gb3IgbGVzcw0K dGltZSBjcml0aWNhbCBhcHBsaWNhdGlvbnMsIElQIG5ldHdvcmsgKExURSBmb3IgZXhhbXBsZSkg d2lsbCBiZSB0aGUNCmJlc3QgY2hvaWNlLiBIb3dldmVyLCBmb3IgdGltZSBjcml0aWNhbCBhcHBs aWNhdGlvbnMgb3IgYXMgeW91IHNhaWQsDQpnZW8tZGVwZW5kZW50IGFwcGxpY2F0aW9ucywgR2Vv TmV0IG92ZXIgODAyLjExcCBtYXkgYmUgbmVjZXNzYXJ5LCBhdA0KbGVhc3QgZm9yIHRoZSBuZWFy IGZ1dHVyZSBhcHBsaWNhdGlvbnMuIElmIHdlIGNvbnNpZGVyIGZ1cnRoZXIgd2l0aA0KNUcsIHdo ZXJlIHRoZSBsYXRlbmN5IGlzIGV4cGVjdGVkIHRvIGJlIHNpZ25pZmljYW50bHkgcmVkdWNlZCwg SQ0KZ3Vlc3MgZXZlcnl0aGluZyBjYW4gYmUgZG9uZSB0aHJvdWdoIElQLiBCdXQgaXQgaXMgaGFy ZCB0byBkcmF3DQpjb25jbHVzaW9ucyBhYm91dCBpdCBhdCB0aGUgY3VycmVudCBzdGFnZS4gQW55 d2F5LEkgZ3Vlc3MgdGhlDQpjcm9zcy1sYXllciBEZWNlbnRyYWxpemVkIENvbmdlc3Rpb24gQ29u dHJvbCAoRENDKSBpbiBDLUlUUyBzaG91bGQgYmUNCmFibGUgdG8gdGFrZSBjYXJlIG9mIHRoaXMg YmFzZWQgb24gdGhlIFFvUyByZXF1aXJlbWVudCBhdCB0aGUNCmFwcGxpY2F0aW9uIGxheWVyIGFu ZCBkaXJlY3QgdGhlIHRyYWZmaWMgdG8gYXBwcm9wcmlhdGUgdHJhbnNwb3J0IGFuZA0KYWNjZXNz IG1ldGhvZHMsIGF0IGxlYXN0IGl0IGlzIHN1cHBvc2VkIHRvIGRvIHRoaXMuDQoNCklmIElQdjYg aXMgY29uc2lkZXJlZCwgdGhlbiB0aGUgdHJhbnNwb3J0IGxheWVyIHdpbGwgYmUgVENQL1VEUA0K b3ZlciBJUHY2IG92ZXIgR2VvTmV0LCB0aG91Z2ggSSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgcHJv dG9jb2wNCm92ZXJoZWFkLiBJdCBpcyBhbiBpbnRlcmVzdGluZyBpc3N1ZSB0byBpbnZlc3RpZ2F0 ZS4NCg0KWWVzLCBpdCBpcyBhbiBpc3N1ZSB0byBpbnZlc3RpZ2F0ZS4NCg0KQXQgSUVURiB0aGVy ZSBpcyBhIGRvY3VtZW50IGNhbGxlZCBJUHY2LW92ZXItODAyMTFwIHRoYXQgSSBhdXRob3IuDQpU aGUgaWRlYXMgZXhwcmVzc2VkIGluIHRoaXMgZG9jdW1lbnQgY291bGQgYmUgdXNlZCBpbiB0aGlz DQppbnZlc3RpZ2F0aW9uLiBUaGUgZG9jdW1lbnQgaXRzZWxmIGxhY2tzIGNlcnRhaW4gYXNwZWN0 cyB0aGF0DQphbnlvbmUgaW50ZXJlc3RlZCBjb3VsZCBjb250cmlidXRlLg0KDQpUaGFua3MsIEkg YW0gY2hlY2tpbmcgd2l0aCB0aGUgZG9jdW1lbnQsIEkgd291bGQgc2F5IElQdjYgb3Zlcg0KODAy LjExcCBpcyBhYnNvbHV0ZWx5IGFuIG9wdGlvbiBhbmQgd2UgYXJlIGludmVzdGlnYXRpbmcgdGhl DQpwb3NzaWJpbGl0aWVzLiBJIGhvcGUgd2UgY2FuIGFsc28gY29udHJpYnV0ZSB0byB0aGlzIHRv cGljLg0KDQoNCkZvciBwbGF0b29uaW5nIGluIERheTEgYXBwbGljYXRpb25zLCBHZW9OZXQgKEJU UCBhbmQgR2VvTmV0IGZvcg0KdHJhbnNwb3J0KSBvdmVyIEc1IG1heWJlIHRoZSBtb3N0IGFwcHJv cHJpYXRlIGNob2ljZSBhdCB0aGUNCmN1cnJlbnQgc3RhZ2UgYmVjYXVzZSBvZiB0aGUgYWR2YW50 YWdlcyBvZiB0aW1lIGRlbGF5Lg0KDQpOb3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5ICd0aW1lIGRl bGF5Jz8NCg0KSWYgeW91IG1lYW4gbGF0ZW5jeSBiZXR3ZWVuIHZlaGljbGVzLCB0aGVuIEkgdGhp bmsgODAyLjExcCBnaXZlcw0KYmV0dGVyIGxhdGVuY3ksIGluIHRoZSBvcmRlciBvZiB0ZW5zIG9m IG1pbGxzZWNvbmRzLg0KDQpPciB5b3UgbWVhbiB0aGF0IHByb2R1Y3RzIGltcGxlbWVudGluZyBF VFNJIElUUyBHZW9OZXQgaGF2ZSBhIHRpbWUNCmFkdmFudGFnZSBiZWluZyBhbHJlYWR5IHRoZXJl PyAgSWYgc28gdGhlbiBJIGFncmVlIHdpdGggeW91Lg0KDQpZZXMsIGl0IGlzIGxhdGVuY3kuIDgw Mi4xMXAgYmFzZWQgYWNjZXNzIGdlbmVyYWxseSBoYXZlIGJldHRlcg0KbGF0ZW5jeSwgYW5kIGEg bGlnaHQgd2VpZ2h0IEJUUCZHZW9OZXQgYWxzbyBjb250cmlidXRlcyB0byB0aGUNCmxhdGVuY3kg aXNzdWUuIEkgZ3Vlc3MgSVAgb3ZlciA4MDIuMTFwIG1heSBhY2hpZXZlIHNpbWlsYXIgbGF0ZW5j eQ0KcGVyZm9ybWFuY2UsIHRob3VnaCBJIG5lZWQgdG8gY2hlY2sgYSBiaXQgbW9yZSBvdmVyIHRo YXQuIEFzIGZvciBJUHY2DQpvdmVyIEdlb05ldCBvdmVyIDgwMi4xMXAsIGFzIHdlIGFscmVhZHkg bWVudGlvbmVkLCB0aGUgb3ZlcmhlYWQgaXMNCndvcnRoIGludmVzdGlnYXRpbmcgZnVydGhlci4g SXQgaXMgYWxzbyBvbmUgdG9waWMgd2Ugd2lsbCBsb29rIGF0Lg0KDQoNCldlIGFyZSBsb29raW5n IGF0IGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgb2YgR2VvTmV0IGZvcg0KcG90ZW50aWFsIGRl cGxveW1lbnQgaW4gR0NEQy4gQXMgd2Ugd29yayB0b3dhcmRzIERheTINCmFwcGxpY2F0aW9ucywg SVB2NiBpcyBwb3RlbnRpYWxseSBjb25zaWRlcmVkLiBJTlJJQSBoYXMgYmVlbg0Kd29ya2luZyBv biB0aGUgaW1wbGVtZW50YXRpb24gdGhyb3VnaCBDYXJHZW82LiBJZiB5b3UgZ3V5cyBoYXZlDQpt b3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBpbXBsZW1lbnRhdGlvbiBub3csIGl0IGlzIHZlcnkN CmFwcHJlY2lhdGVkIHRoYXQgeW91IHNoYXJlIHdpdGggdXMuDQoNClN1cmUsIGNlcnRhaW5seS4g IEkgZG93bmxvYWRlZCBDYXJHZW82IGFuZCBsb29rZWQgYXQgdGhlIGNvZGUuICBJDQpoYXZlIHRo ZSBmZWVsaW5nIHRoYXQgd2l0aCBpdCBhIGNhciBzZW5kcyBpdHMgcG9zaXRpb24gdG8gYW5vdGhl cg0KY2FyLg0KDQpBdCBteSBwbGFjZSB3ZSBoYXZlIGFub3RoZXIgaW1wbGVtZW50YXRpb24gb2Yg ZXhjaGFuZ2luZyBJUHY2DQpyb3V0aW5nIGluZm9ybWF0aW9uIG92ZXIgODAyLjExcC4gIFdlIGFs c28gaGF2ZSBhbiB1cGRhdGUgdmVyc2lvbg0Kb2YgdGhlIG9yaWdpbmFsIDgwMi4xMXAgR0NEQyBk cml2ZXIgZm9yIG1vc3QgcmVjZW50IGxpbnV4IGtlcm5lbHMNCmFzIHdlbGwgYXMgb3RoZXIgcmVs aWFiaWxpdHkgaW1wcm92ZW1lbnRzLg0KDQpXZSBhcmUgaW52ZXN0aWdhdGluZyBDYXJHZW82IG5v dy4gQnV0IGl0IGlzIHZlcnkgaW50ZXJlc3RpbmcgeW91IGhhdmUNCmFuIHVwZGF0ZSB2ZXJzaW9u IG9mIHRoZSA4MDIuMTFwIHByb3RvY29sLiBJIGFtIG5vdCBzdXJlIGlmIHlvdQ0KYWxyZWFkeSBt YWtlIGl0IG9wZW4gc291cmNlIG9yIG5vdC4gSWYgc28sIGl0IHdpbGwgYmUgYWJzb2x1dGVseSBh DQpncmVhdCBoZWxwIGZvciB1cyB0byBjaGVjayB0aGUgcG9zc2liaWxpdGllcyBvZiBhcHBseWlu ZyBJUHY2IG92ZXINCjgwMi4xMXAuIENvdWxkIHlvdSBpbmRpY2F0ZSBtZSBob3cgYW5kIHdoZXJl IEkgY2FuIGNoZWNrIGFuZCB0aGVuIEkNCmNhbiB0YWxrIHdpdGggbXkgY29sbGVhZ3VlcyBib3Ro IGF0IFZpa3RvcmlhIGFuZCBUTk8gZm9yIGZ1cnRoZXINCmRpc2N1c3Npb25zPyBJZiB3ZSBwcm92 ZSB0aGUgcGVyZm9ybWFuY2Ugd2l0aCBJUCBvdmVyIDgwMi4xMXAgZHVyaW5nDQp0aGUgY2hhbGxl bmdlLCBJIHdvdWxkIHNheSB0aGF0IHdpbGwgYmUgYSBncmVhdCBjb250cmlidXRpb24gdG8NCkMt SVRTLCBhdCBsZWFzdCBmb3Igc29tZSBwYXJ0LiBUaGFua3MgdmVyeSBtdWNoIGJlZm9yZWhhbmQ6 LSkNCg0KQWxzbywgaWYgeW91IGtub3cgdGVhbXMgdGhhdCB3YW50IHRvIHNob3cgdGhlaXIgaW1w bGVtZW50YXRpb25zDQpvZiBjb29wZXJhdGl2ZSBkcml2aW5nIHRvIHRoZSB3b3JsZCwgR0NEQyAy MDE2IGlzIHRoZSBwbGFjZSB0bw0KZ28uIFRoZXkgYXJlIGZyZWUgdG8gY29udGFjdCB1cyBmb3Ig cmVnaXN0cmF0aW9uIG9yIGNoZWNrDQp3d3cuZ2NkYy5uZXQ8aHR0cDovL3d3dy5nY2RjLm5ldD4g PGh0dHA6Ly93d3cuZ2NkYy5uZXQ+IGZvciBkZXRhaWxzLg0KDQpZRXMsIHRoaXMgaXMgYSBnb29k IGFubm91bmNlbWVudC4gIFBsZWFzZSBzdGF0ZSBoZXJlIHdoYXQgYXJlIHRoZQ0KcGFydGljaXBh dGluZyBjb25kaXRpb25zIC0gaXMgaXQgZnJlZSB0byBqb2luLCB3aGF0IGFyZSB0aGUgZmVlcw0K aW52b2x2ZWQsIGluIHdoaWNoIGNvdW50cnkgaXMgaXQgaGFwcGVuaW5nLg0KDQpUaGFua3MgQWxl eCwgaXQgaXMgbXkgcGxlYXN1cmUgdG8gc2hhcmUgd2l0aCBvdXIgY29tbXVuaXR5IHRoZQ0KYW5u b3VuY2VtZW50Lg0KDQpHQ0RDMjAxNiwgb3IgaS1HQU1FICh3d3cuZ2NkYy5uZXQ8aHR0cDovL3d3 dy5nY2RjLm5ldD4pIGlzIHRoZSBzZWNvbmQgZWRpdGlvbiBvZiBHQ0RDDQpiYXNlZCBvbiBpdHMg c3VjY2VzcyBpbiAyMDExIGFuZCB3aXRoIHRoZSBwdXJwb3NlIHRvIGFjY2VsZXJhdGUNCmNvb3Bl cmF0aXZlIGRyaXZpbmcgdGhyb3VnaCBwdWJsaWMgY2hhbGxlbmdlLiBHQ0RDMjAxNiB3aWxsIG1h aW5seQ0KZm9jdXMgb24gdGhlIGludGVyb3BlcmFiaWxpdHkgb2YgY29tbXVuaWNhdGlvbnMsIGUu Zy4gY29tbXVuaWNhdGlvbnMNCmFyZSB2ZW5kb3IgaW5kZXBlbmRlbnQgYW5kIHRlYW1zIGFyZSB2 ZXJ5IHdlbGNvbWUgdG8gaW1wbGVtZW50IGJhc2VkDQpvbiBkaWZmZXJlbnQgZXF1aXBtZW50cyBm cm9tIGRpZmZlcmVudCB2ZW5kb3JzIC4gSG93ZXZlciwgdGhlDQpjb21tdW5pY2F0aW9ucyBwcm90 b2NvbCB3aWxsIGFsaWduIHRvIHRoZSBsYXRlc3QgQy1JVFMgc3RhbmRhcmRzDQooUmVsZWFzZSAx KSBhbmQgcG90ZW50aWFsbHkgd2lsbCBjb250cmlidXRlIHRvIFJlbGVhc2UgMi4NCg0KSXQgaXMg dG90YWxseSBmcmVlIHRvIGpvaW4gdGhlIGNoYWxsZW5nZSBhbmQgaW4gYWRkaXRpb24gdG8gdGhh dCwNCnRlYW1zIHdpbGwgZ2V0IHN1cHBvcnQgZnJvbSBvcmdhbml6ZXJzIChUTk8gYW5kIFRVL2Ug ZnJvbSBob2xsYW5kLA0KVmlrdG9yaWEgU3dlZGlzaCBJQ1QgZnJvbSBTd2VkZW4gYW5kIElESUFE QSBmcm9tIFNwYWluKS4gVGhlIGZpbmFsDQpjaGFsbGVuZ2Ugd2lsbCBiZSBRMiAyMDE2IGF0IHRo ZSB0ZXN0IHNpdGUgaW4gSGVsbW9uZCBpbiBIb2xsYW5kLA0KZXhhY3RseSB0aGUgc2FtZSB0ZXN0 IHNpdGUgYXMgR0NEQyAyMDExLiBHQ0RDMjAxNiBoYXZlIHR3byBjaGFsbGVuZ2UNCnNjZW5hcmlv cyBhbmQgb25lIGRlbW8gc2NlbmFyaW8uIENoYWxsZW5nZSBzY2VuYXJpb3MgaW5jbHVkZSBib3Ro DQp1cmJhbiAoaW50ZXJzZWN0aW9uIHBhc3NpbmcpIGFuZCBoaWdod2F5IChwbGF0b29uIG1lcmdl IGR1ZSB0bw0Kcm9hZHdvcmspLiBEZW1vIHNjZW5hcmlvIGlzIGFib3V0IGVtZXJnZW5jeSB2ZWhp Y2xlIHBhc3NpbmcuIEFsbA0Kc2NlbmFyaW9zIGFyZSBkZWZpbmVkIHRvIGJlIGNsb3NlIHRvIHJl YWxpdHkgYW5kIHRoZSBpbXBsZW1lbnRhdGlvbnMNCmFyZSBhbHNvIGV4cGVjdGVkIHRvIGJlIGFz IGNsb3NlLXRvIG1hcmtldCBhcyBwb3NzaWJsZS4gV2Ugd2FudCB0bw0Kc2hvdyB0aGUgYmVuZWZp dHMgb2YgY29vcGVyYXRpdmUgZHJpdmluZyBhbmQgYWxzbyByYWlzZSB0aGUgYXdhcmVuZXNzDQpm cm9tIGJvdGggZ292ZXJubWVudCBhbmQgcHVibGljLg0KDQpUaGUgY2FsbCBvbiByZWdpc3RyYXRp b25zIGlzIG9uLWdvaW5nLiBOb3RpY2UgdGhhdCB0aGUgcmVnaXN0cmF0aW9uDQppcyBub3QgYmlu ZGluZyBhdCB0aGlzIHN0YWdlLiBUZWFtcyBjYW4gc2hvdyBpbnRlcmVzdCBhbmQgYXNrIGZvcg0K ZnVydGhlciBpbmZvcm1hdGlvbiBhbmQgaWYgcG9zc2libGUsIHRoZSBvcmdhbml6ZXJzIG1heSBo ZWxwIHRvDQphc3Npc3QgdG8gZmluZCBwYXJ0bmVycy4gVGVhbXMgYXJlIGFsc28gdmVyeSB3ZWxj b21lIHRvIGNvbnRyaWJ1dGUgdG8NCnRoZSBpbXBsZW1lbnRhdGlvbiBvZiBjb21tdW5pY2F0aW9u IHByb3RvY29scyB0b2dldGhlciB3aXRoIHVzLiBKdXN0DQpkcm9wIHVzIGVtYWlscyA6LSkNCg0K Rm9yIHRob3NlIHdobyBhcmUgaW50ZXJlc3RlZCwgc29tZSBnZW5lcmFsIHJlcXVpcmVtZW50cyBh cmUgYXMNCmZvbGxvd3MsIOKAokEgdmVoaWNsZSB0aGF0IHdpbGwgYmUgZml0dGVkIHdpdGggdGhl IHJlcXVpcmVtZW50cw0K4oCiTWluaW11bSBsb25naXR1ZGluYWwgYXV0b21hdGlvbiDigKJJbnRl cm9wZXJhYmxlIFYyWCBjb21tdW5pY2F0aW9uIGFuZA0KaW50ZXJhY3Rpb24g4oCTIHdpbGwgYmUg dGVzdGVkIGJvdGggcmVtb3RlbHkgb25saW5lIGFuZCBwaHlzaWNhbGx5IGF0DQp0aGUgY2hhbGxl bmdlIHNpdGUg4oCiRHJpdmVycyBhcmUgaW4gdGhlIHZlaGljbGVzLCBzYWZldHkgaXMgY3JpdGlj YWwNCuKAokRyaXZlcnMgYW5kIHN1cHBvcnQgY3JldyDigKJCdWRnZXQgZm9yIHRyYXZlbCwgdHJh bnNwb3J0IGFuZA0Kc3Vic2lzdGVuY2Ug4oCiVGFraW5nIHBhcnQgaW4gcHJlcGFyYXRpdmUgd29y a3Nob3BzIGFuZCB0aGUgcmlnb3JvdXMNCmZ1bmN0aW9uYWwgdGVzdGluZyBiZWZvcmUgdGhlIGNo YWxsZW5nZSDigKJCZSByZWFkeSBieSBTcHJpbmcgMjAxNiENCg0KSW4gcmV0dXJuLCB0aGUgdGVh bXMgd2lsbCBnZXQg4oCiT25jZSBpbiBhIGxpZmV0aW1lIG9wcG9ydHVuaXR5IHRvIHdvcmsNCndp dGggdW5pdmVyc2l0aWVzLCBPRU1zIGFuZCBhdXRob3JpdGllcyB0byBmb3J3YXJkIHRoZSBzdGF0 ZSBvZg0KY29vcGVyYXRpdmUgYXV0b25vbW91cyBkcml2aW5nIOKAokdldCBpbiBjb250YWN0IHdp dGggd29ybGQgY2xhc3MNCmNvbXBhbmllcyBhbmQgcGVvcGxlIGluIHRoaXMgZmllbGQg4oCiQ29s bGFib3JhdGUgYXQgdGhlIGZvcmVmcm9udCBvZg0Kc3RhbmRhcmRpemF0aW9uIGVmZm9ydHMg4oCi SGVscCB5b3VyIGluc3RpdHV0aW9uIGxlYXJuIGFuZCBidWlsZCBpdHMNCnJlcHV0YXRpb24g4oCi V2luIHRoZSBjaGFsbGVuZ2UgYW5kIGV0ZXJuYWwgZmFtZSENCg0KSnVzdCBhIHZpZGVvIGludHJv ZHVjdGlvbiBvZiBsYXN0IHRpbWXigJlzIGNoYWxsZW5nZQ0KKGh0dHBzOi8vd3d3LnlvdXR1YmUu Y29tL3dhdGNoP3Y9bG1SaWZMenc4aUEpIGZvciB0aG9zZSB3aG8gYXJlDQppbnRlcmVzdGVkLiBU ZWFtcyBub3cgY2FuIHJlZ2lzdGVyIGF0IHd3dy5nY2RjLm5ldDxodHRwOi8vd3d3LmdjZGMubmV0 PiBvciBjb250YWN0IHRoZQ0KZm9sbG93aW5nIHBlb3BsZS4NCg0KRm9yIHJlZ2lzdHJhdGlvbiBh bmQgdGVhbSBpbmZvcm1hdGlvbjogIGwuci5yLnNjaHJpam5lbWFrZXJzQHR1ZS5ubDxtYWlsdG86 bC5yLnIuc2NocmlqbmVtYWtlcnNAdHVlLm5sPg0KKExhdXJlbnMgU2NocmlqbmVtYWtlcnMpDQoN CkZvciBwcm9qZWN0IGluZm9ybWF0aW9uIGFuZCBjb2xsYWJvcmF0aW9uOiBzYW5kZXIubWFhc0B0 bm8ubmw8bWFpbHRvOnNhbmRlci5tYWFzQHRuby5ubD4gKFNhbmRlcg0KTWFhcykNCg0KV2Ugc2lu Y2VyZWx5IGxvb2sgZm9yd2FyZCBmb3IgdGVhbXMgZnJvbSBhbGwgb3ZlciB0aGUgd29ybGQgdG8N CnBhcnRpY2lwYXRlIDopDQoNCg0KQWxleA0KDQoNCkJlc3QgcmVnYXJkcywgTGVpDQoNCg0KKkxl aSBDaGVuLCBQaEQqIFNlbmlvciBSZXNlYXJjaGVyIENvb3BlcmF0aXZlIFN5c3RlbXMNCg0KDQoN CipWaWt0b3JpYSBTd2VkaXNoIElDVCBBQiogTGluZGhvbG1zcGlyZW4gM0EgU0UtNDE3IDU2IEfD tnRlYm9yZywNClN3ZWRlbiBUZWw6ICs0NiA3NiA3NzcgMTQ0OSBFLW1haWw6IGxlaS5jaGVuQHZp a3RvcmlhLnNlPG1haWx0bzpsZWkuY2hlbkB2aWt0b3JpYS5zZT4NCjxtYWlsdG86PiB3d3cudmlr dG9yaWEuc2U8aHR0cDovL3d3dy52aWt0b3JpYS5zZT4gPGh0dHA6Ly93d3cudmlrdG9yaWEuc2U+ DQoNClBhcnQgb2YgUklTRQ0KDQpPbiAyNyBPY3QgMjAxNCwgYXQgMTI6MjIsIFZhcmFkaSAsIEFu ZHJhcyAobGVzc3dpcmUgQUcgVW5nYXJuKQ0KPFZhcmFkaUBsZXNzd2lyZS5jb208bWFpbHRvOlZh cmFkaUBsZXNzd2lyZS5jb20+IDxtYWlsdG86VmFyYWRpQGxlc3N3aXJlLmNvbT4+IHdyb3RlOg0K DQpEZWFyIEFsZXgsIEpvaG4gSSBhZ3JlZSB3aXRoIEpvaG4sIGJ1dCB3b3VsZCBsaWtlIHRvIHBv aW50IG91dA0KdGhhdCBJIHRoaW5rIGl0cyBsaWtlbHkgdGhhdCB3ZSB3aWxsIG5lZWQgdG8gZXh0 ZW5kIEVVDQpHZW9uZXR3b3JraW5nIChFTiAzMDIgNjM2KSB0byB3b3JrIG92ZXIgSVAgKGUuZy4g TFRFKSBsaW5rcw0KYWxzby4gSSB0aGluayB3ZSB3aWxsIGhhdmUgc3VjaCByZXF1aXJlbWVudHMg Zm9yIEVVIERheTIgb3IgMw0KKDJebmQgLCBUaGlyZCBnZW5lcmF0aW9uIEMtSVRTKSAoZXhhbXBs ZTogdXBkYXRlIG91ciBMb2NhbA0KRHluYW1pYyBNYXAgd2l0aCBhIG5ldyBXYXJuaW5nIG1lc3Nh Z2UgcmVjZWl2ZWQgb3ZlciBjZWxsdWxhcg0KY29ubmVjdGlvbiAobm90IEc1LzExcCkpIMOcZHbD tnpsZXR0ZWwgLyBCZXN0IHJlZ2FyZHMsIEFuZHLDoXMNClbDoXJhZGkgUHJvamVjdCBNYW5hZ2Vy IOKAkyBDMlgvSVRTIFN5c3RlbXMNCg0KQXV0b21vdGl2ZSAmIFdMQU4gR3JvdXAgbGVzc3dpcmUg SHVuZ2FyeSoqKnwqKipPZmZpY2U6ICszNg0KMjM1MjEgNjY3KioqfCoqKkVtYWlsOlZhcmFkaUBs ZXNzd2lyZS5jb208aHR0cDovL2xlc3N3aXJlLmNvbT4NCjxtYWlsdG86VmFyYWRpQGxlc3N3aXJl LmNvbT4gKkZyb206Kml0cw0KW21haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZ10qT24gQmVoYWxm IE9mKkpvaG4gS2VubmV5DQoqU2VudDoqU2F0dXJkYXksIE9jdG9iZXIgMjUsIDIwMTQgMTo0NSBB TSAqVG86KkFsZXhhbmRydQ0KUGV0cmVzY3UgKkNjOippdHNAaWV0Zi5vcmc8bWFpbHRvOml0c0Bp ZXRmLm9yZz4gPG1haWx0bzppdHNAaWV0Zi5vcmc+ICpTdWJqZWN0OipSZToNCltnZW9uZXQvaXRz XSBGWUkgLSBFVFNJIElUUyAtIHdvcmsgb24gY29vcGVyYXRpdmUgY3J1aXNlDQpjb250cm9sLCBw bGF0b29uaW5nIEhpIEFsZXgsIFRoYW5rcyBmb3Igc2hhcmluZyB0aGlzLiBJIHRoaW5rDQptYW55 IG9mIHVzIGluIHRoZSBEU1JDL0Nvb3BlcmF0aXZlIElUUyBjb21tdW5pdHkgY29uc2lkZXIgdGhl c2UNCnR3byBhcHBsaWNhdGlvbnMgdG8gYmUgYSB2ZXJ5IG5hdHVyYWwgZml0IGZvciB0aGUgdGVj aG5vbG9neS4NCkZ1cnRoZXJtb3JlLCBteSBleHBlY3RhdGlvbiBpcyB0aGF0IHRoZSBhcHBsaWNh dGlvbnMgY2FuIHdvcmsNCndlbGwgd2l0aCBvbmUtaG9wIFYyViBjb21tdW5pY2F0aW9uIG9mIHRo ZSB0eXBlIHRoYXQgZG9lcyBub3QNCnR5cGljYWxseSB1c2UgSVAuICBTbywgSSBkb24ndCBzZWUg YSBiZW5lZml0IG9mIGluY2x1ZGluZyBJUC4NClRoYXQgZG9lc24ndCBtZWFuIGl0IHdvdWxkbid0 IHdvcmssIGJ1dCBhcyB5b3Uga25vdyB0aGUgRFNSQw0KY29tbXVuaXR5IGdlbmVyYWxseSBwbGFu cyB0byB1c2UgYSBsaWdodGVyIHdlaWdodCBwcm90b2NvbCwNCldTTVAsIGZvciBhcHBsaWNhdGlv bnMgdGhhdCBkbyBub3QgbmVlZCBJUC4gIEkgZXhwZWN0IEVUU0kgd2lsbA0KdGhpbmsgYWxvbmcg c2ltaWxhciBsaW5lcy4gQmVzdCBSZWdhcmRzLCBKb2huIC0tIEpvaG4gS2VubmV5DQpQcmluY2lw YWwgUmVzZWFyY2hlciBUb3lvdGEgSW5mb1RlY2hub2xvZ3kgQ2VudGVyLCBVU0EgNDY1DQpCZXJu YXJkbyBBdmVudWUgTW91bnRhaW4gVmlldywgQ0EgOTQwNDMgVGVsOiA2NTAtNjk0LTQxNjAuDQpN b2JpbGU6IDY1MC0yMjQtNjY0NCBPbiBGcmksIE9jdCAyNCwgMjAxNCBhdCA4OjE2IEFNLCBBbGV4 YW5kcnUNClBldHJlc2N1IDxhbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPG1haWx0bzphbGV4 YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPg0KPG1haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21h aWwuY29tPj4gd3JvdGU6IEhlbGxvDQpnZW9uZXQvaXRzZXJzLA0KDQpFVFNJIElUUyBncm91cCBp cyBhbiBTRE8gaW4gRXVyb3BlLiAgVGhleSBwcm9kdWNlZCBtYW55DQpzdGFuZGFyZHMgaW4gdGhl IHBhc3QgZm9yIHZlaGljdWxhciBjb21tdW5pY2F0aW9ucywgZS5nLiBFVFNJDQpJVFMgZ2VvLW5l dHdvcmtpbmcgYW1vbmcgb3RoZXJzLg0KDQpFVFNJIElUUyByZWNlbnRseSBhZ3JlZWQgdG8gc3Rh cnQgd29ya2luZyBvbg0KcHJlLXN0YW5kYXJkaXphdGlvbiBpdGVtcyBjYWxsZWQgIkNvb3BlcmF0 aXZlIENydWlzZSBDb250cm9sIg0KYW5kICJQbGF0b29uaW5nIi4gIFRoZXNlIHR3byBhcHBsaWNh dGlvbnMgbWFrZSBhdXRvbW9iaWxlcyAoYW5kDQp0cnVja3MpIHRhbGsgdG8gZWFjaCBvdGhlciBj b250aW51b3VzbHkgdG8ga2VlcCBzcGVlZCBjb25zdGFudC4NCkl0IGhlbHBzIHJlbGlldmUgYXV0 b21vYmlsZSBkcml2ZXIgc3RyZXNzIGluIGphbSBzaXR1YXRpb24gb3INCnJlZHVjZSBnYXMgY29u c3VtcHRpb24gYnkgJ3BsYXRvb25pbmcnLg0KDQpDdXJyZW50bHkgdGhlIGZvY3VzIGlzIG9uIHJl cXVpcmVtZW50cyBpbmNsdWRpbmcgY29tbXVuaWNhdGlvbg0KcmVxdWlyZW1lbnRzLg0KDQpJbiBt eSBvcHBpbmlvbiwgYW5kIHRoaXMgaXMgd2h5IEkgZm9yd2FyZCBpdCB0byB0aGlzIGdyb3VwLA0K ZXN0YWJsaXNoaW5nIGRpcmVjdCBJUCBjb25uZWN0aW9ucyBiZXR3ZWVuIHZlaGljbGVzIG1heSBv cGVuDQpwYXRocyBmb3IgZXhjaGFuZ2luZyBJUCBkYXRhIGNvbnRhaW5pbmcgc3BlZWQvbG9jYXRp b24gYW5kDQp0cmlnZ2VyIGEgY29udHJvbCBwcm9jZXNzIG9mIGFkYXB0aW5nIHRoZSBzcGVlZC4g IE9uZSBhbHJlYWR5DQpjb250cm9scyB2ZWhpY2xlcyBieSBzZW5kaW5nIElQIGRhdGEgdG8gdGhl bSwgZnJvbSB0aGUNCmluZnJhc3RydWN0dXJlLiAgSXQgd291bGQgYmUgYSBzaW1wbGUgbWF0dGVy IGZvciBJUCBleHBlcnRzIHRvDQpzZW5kIHRoYXQgc2FtZSBkYXRhIGZyb20gb3RoZXIgdmVoaWNs ZSwgd2l0aG91dCBnb2luZyB0byB0aGUNCmluZnJhc3RydWN0dXJlLg0KDQpUaG91Z2h0cz8NCg0K WW91cnMsDQoNCkFsZXgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gaXRzIG1haWxpbmcNCmxpc3QgaXRzQGlldGYub3JnPG1haWx0bzppdHNAaWV0Zi5v cmc+IDxtYWlsdG86aXRzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pdHMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBpdHMgbWFpbGluZw0KbGlzdCBpdHNAaWV0Zi5vcmcgPG1haWx0bzppdHNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gaXRzIG1haWxpbmcg bGlzdA0KaXRzQGlldGYub3JnPG1haWx0bzppdHNAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQoNCg0KW2NpZDo4QUM0OUIxMi05ODA4LTQ4N0UtQTdE Qi1CQzlGNDFBNjk4NTNAdmlrdG9yaWEubG9jYWxdDQo= --_000_7DA761D0F7E34438AB58F989B430E321viktoriase_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhhbmtzIEFsZXgsIGl0IGlzIGdv aW5nIHdlbGwgd2l0aCBHQ0RDMjAxNi4gV2UgaGF2ZSBzdWNjZXNzZnVsbHkgY29uZHVjdGVkIHNh ZmV0eSBhbmQgY29tbXVuaWNhdGlvbiB0ZXN0IGF0IHRoZSB0aGUgdGVzdCBzaXRlIGluIElESUFE QS4gJm5ic3A7V2UgYXJlIG5vdyBhdCB0aGUgZmluYWwgc3RhZ2Ugb2YgcGxhbm5pbmcgYW5kIHRo ZSBDaGFsbGVuZ2Ugd2lsbCBiZSBvbiAyOCAtIDI5IE1heS4gVGhlcmUgd2lsbCBhbHNvIGJlIG9u ZSB3ZWVrIHByZXBhcmF0aW9uDQogd29ya3Nob3AgYXQgSGVsbW9uZCwgYW5kIG9uZSBkYXkgY29u Z3Jlc3MgZm9sbG93aW5nIHRoZSBjaGFsbGVuZ2UuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIDgwMi4x MXAgZHJpdmVycyBpcyB0aGUgb25lIG1vZGlmaWVkIGJ5IENUVS1JSUcgKDxhIGhyZWY9Imh0dHBz Oi8vZ2l0aHViLmNvbS9DVFUtSUlHIiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5jb20vQ1RVLUlJ RzwvYT4pLiBBcyBkZXNjcmliZWQgaGVyZSAoPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2Fs ZXh2b3Jvbm92L2dlb25ldHdvcmtpbmcvYmxvYi9tYXN0ZXIvSEFSRFdBUkUubWQiIGNsYXNzPSIi Pmh0dHBzOi8vZ2l0aHViLmNvbS9hbGV4dm9yb25vdi9nZW9uZXR3b3JraW5nL2Jsb2IvbWFzdGVy L0hBUkRXQVJFLm1kPC9hPikNCiB3aXRoIG15IGNvbGxlYWd1ZSBBbGV4LCBpdCBzZWVtcyA4MDIu MTFwIGlzIG5vdCB5ZXQgdmVyeSB3ZWxsIGludGVncmF0ZWQuIEFuZCBHQ0RDIHByb3ZpZGVzIHdp dGggYSBzdGVwIGJ5IHN0ZXAgaW5zdGFsbGF0aW9uIGd1aWRlIGZvciA4MDIuMTFwIG9uIEFMSVgg QVBVMUQgcnVubmluZyBWb3lhZ2UuIEFsbCBpbmZvcm1hdGlvbiBjYW4gYmUgZm91bmQgYXQgR0NE QyBzaXRlICg8YSBocmVmPSJodHRwOi8vZ2NkYy5uZXQvZW4vIiBjbGFzcz0iIj5odHRwOi8vZ2Nk Yy5uZXQvZW4vPC9hPikuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BZ2Fpbiwgd2UgdGFrZSB0aGUgb3Bwb3J0dW5pdHkgdG8g aW52aXRlIGFsbCBJVFMgZXhwZXJ0cyB0byBjb21lIGFuZCBqb2luIHRoZSBjaGFsbGVuZ2UuIFBy b21pc2UgaXQgd2lsbCBiZSBleGNpdGluZy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJSPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkxlaTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDI2IEFwciAyMDE2LCBh dCAxMToyNywgQWxleGFuZHJ1IFBldHJlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86YWxleGFuZHJ1 LnBldHJlc2N1QGdtYWlsLmNvbSIgY2xhc3M9IiI+YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXds aW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkhpIExlaSw8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpJIGhvcGUgdGhlIEdDREMgMjAxNiBwbGFuIGlzIGFkdmFuY2luZyB3 ZWxsLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFueSBpZGVhIHdoYXQgYXJlIHRoZSA4 MDIuMTFwIGRyaXZlcnMgcGVvcGxlIHdpbGwgdXNlIGF0IHRoaXMgZXZlbnQ/ICZuYnNwO0lzIG5v dyA4MDIuMTFwIGludGVncmF0ZWQgaW4gdGhlIG1haW5saW5lIGtlcm5lbD88YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpZb3Vycyw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBbGV4 PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KTGUgMjcvMTAvMjAxNCAxODoyNCwgTGVpIENoZW4gYSDDqWNyaXQgOjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkRlYXIgQWxleCw8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MgdmVyeSBtdWNoIGZvciB0aGUgZGV0YWlsZWQgZXhwbGFu YXRpb24gYW5kIGFsc28gdGhlPGJyIGNsYXNzPSIiPg0Kb3Bwb3J0dW5pdHkgdG8gc2hhcmUgd2l0 aCBvdXIgY29tbXVuaXR5IGFib3V0IEdDREMgMjAxNi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpQbGVhc2Ugc2VlIHRoZSBmb2xsb3dpbmcgZm9yIGRldGFpbHMuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KQmVzdCByZWdhcmRzLCBMZWk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiAyNyBPY3QgMjAxNCwgYXQg MTY6MDgsIEFsZXhhbmRydSBQZXRyZXNjdTxiciBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWls dG86YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbSIgY2xhc3M9IiI+YWxleGFuZHJ1LnBldHJl c2N1QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkRlYXIgTGVpIENoZW4sPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmsgeW91IGZv ciB0aGUgcmVwbHkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTGUgMjcvMTAvMjAxNCAx NDowMywgTGVpIENoZW4gYSDDqWNyaXQgOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPkRlYXIgYWxsLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkp1 c3QgYSBiaXQgc2VsZiBpbnRyb2R1Y3Rpb24sIHdlIGFyZSB3b3JraW5nIG9uIHRoZSBzZWNvbmQ8 YnIgY2xhc3M9IiI+DQplZGl0aW9uIG9mIGNvb3BlcmF0aXZlIGRyaXZpbmcgY2hhbGxlbmdlICg8 YSBocmVmPSJodHRwOi8vd3d3LmdjZGMubmV0IiBjbGFzcz0iIj53d3cuZ2NkYy5uZXQ8L2E+PGJy IGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cuZ2NkYy5uZXQiIGNsYXNzPSIiPmh0 dHA6Ly93d3cuZ2NkYy5uZXQ8L2E+Jmd0OykgYW5kIHNvbWVob3cgd2UgY2FtZSBhY3Jvc3MgdGhl IHNhbWUgdG9waWNzPGJyIGNsYXNzPSIiPg0KaGVyZS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQo8YnIgY2xhc3M9IiI+DQpHQ0RDIGlzIHRoZSBzYW1lIG9yZ2FuaXphdGlvbiB0aGF0IGlz c3VlZCB0aGUgZmlyc3QgZnJlZWx5PGJyIGNsYXNzPSIiPg0KYXZhaWxhYmxlIDgwMi4xMXAgZHJp dmVyPzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkxhc3QgdGlt ZSwgR0NEQyBpbXBsZW1lbnRlZCA4MDIuMTFwIHRoYW5rcyB0byB0aGUgd29yayB3aXRoIEVyaWM8 YnIgY2xhc3M9IiI+DQpLb2VuZGVycy4gSXQgaXMgb3Blbi1zb3VyY2UsIEkgaG9wZSB0aGF0IGlz IHRoZSBzYW1lIG9uZSB5b3UgYXJlPGJyIGNsYXNzPSIiPg0KdGFsa2luZyBhYm91dC48YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5UaGFua3MgdG8gQWxleCB0byBicmluZyB0 aGlzIHRvcGljIHVwLCBpdCBpcyB2ZXJ5IHJlbGV2YW50IGZvcjxiciBjbGFzcz0iIj4NCnRoZSBw bGF0b29uIGFwcGxpY2F0aW9ucy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCYXNpY2Fs bHksIGxpa2UgQW5kcmFzIGFuZCBKb2huIHNhaWQsIFYyViB0aHJvdWdoIERTUkMgd2lsbCBiZTxi ciBjbGFzcz0iIj4NCnRoZSBmaXJzdCBpbXBsZW1lbnRhdGlvbiBmb3IgaW5pdGlhbCBhcHBsaWNh dGlvbiBvZiBwbGF0b29uaW5nLjxiciBjbGFzcz0iIj4NCklQIHdpbGwgbW9zdCBwcm9iYWJseSBi ZSB1c2VkIGZvciBEYXkyIGFwcGxpY2F0aW9ucyB0aGF0IHJlcXVpcmU8YnIgY2xhc3M9IiI+DQpt b3JlIGRhdGEgY29tbXVuaWNhdGlvbnMsIGZvciBleGFtcGxlLCB2aWRlbyBzdHJlYW1pbmcgYmV0 d2VlbjxiciBjbGFzcz0iIj4NCnBsYXRvb24gdmVoaWNsZXMgb3IgTERNLjxiciBjbGFzcz0iIj4N CjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCltMRE0/ICZuYnNwOyhsaWdodC1iYXNlZCBj b21tdW5pY2F0aW9ucywgTGlGaT8pXTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBj bGFzcz0iIj4NClNvcnJ5IGZvciB0aGF0LCAmbmJzcDtMRE0gPSBsb2NhbCBkeW5hbWljIG1hcC4g VXNpbmcgRFNSQyBhbmQgYmFzZWQgb24gQ0FNPGJyIGNsYXNzPSIiPg0KbWVzc2FnZXMsIExETSBp cyBhYmxlIHRvIGJlIGNvbnN0cnVjdGVkLCBidXQgaWYgd2UgY29uc2lkZXIgbW9yZTxiciBjbGFz cz0iIj4NCmFjY3VyYXRlIGFuZCBjb21wbGV4IExETSBmb3IgZW52aXJvbm1lbnRhbCBwZXJjZXB0 aW9uLCBJIHdvdWxkIHNheSBJUDxiciBjbGFzcz0iIj4NCndpbGwgYmUgbmVlZGVkLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCkkgYW0gaGFwcHkgdG8gc2VlIElQIGNvbW11bmljYXRpb25zIGFyZSBjb25z aWRlcmVkLCBldmVuIHRoYXQgaXMgaW48YnIgY2xhc3M9IiI+DQp0aGUgc2Vjb25kIGRheS4gJm5i c3A7SSBwZXJzb25hbGx5IGRvIG5vdCB3b3JyeSB2ZXJ5IG11Y2ggb2YgYmVpbmcgbWF5YmU8YnIg Y2xhc3M9IiI+DQpsYXRlciwgYmVjYXVzZSBJIHRoaW5rIElQIHdpbGwgc3VwcG9ydCBtb3JlIGFw cGxpY2F0aW9ucywgY3VycmVudGx5PGJyIGNsYXNzPSIiPg0KdW5zcG9rZW4gb2YuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SXQg c2VlbXMgRVRTSSBkb2VzIHRoaXMgd2l0aCBhbiBhZGFwdGlvbiBsYXllciAoRU4zMDIgNjM2LTYt MSw8YnIgY2xhc3M9IiI+DQpUUzEwMiA2MzYtNi0xKSBmb3IgSVB2NiB0byB3b3JrIHdpdGggR2Vv TmV0LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClllcywgdGhl cmUgaXMgYW4gYWRhcHRhdGlvbiBsYXllciBmb3IgSVB2NiBhbmQgZ2VvbmV0LiAmbmJzcDtJdCBt YXkgYmU8YnIgY2xhc3M9IiI+DQpoaWdobHkgbmVjZXNzYXJ5IGluIHRoZSBpbml0aWFsIHN0ZXBz IG9mIGJyaW5naW5nIElQdjYgYXMgY2xvc2UgYXM8YnIgY2xhc3M9IiI+DQpwb3NzaWJsZSB0byB0 aGUgZGVwbG95bWVudC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJUHY2LXN0cmFpZ2h0 LW92ZXItODAyMTFwIGFsc28gdXNlcyBhbiBBZGFwdGF0aW9uIExheWVyICh0aGU8YnIgY2xhc3M9 IiI+DQpFdGhlcm5ldCBBZGFwdGF0aW9uIExheWVyIHVzZWQgYnkgODAyLjExYikuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+QW55 d2F5LCBHZW9OZXQgc2VlbXMgdG8gYmUgaW4gdGhlIHByb3RvY29sIHN0YWNrIGZvciBDLUlUUyBu bzxiciBjbGFzcz0iIj4NCm1hdHRlciB3aGF0LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4N CjxiciBjbGFzcz0iIj4NClRoYW5rcyBmb3IgdGhlIHJlbWFyay4gJm5ic3A7SXQgaXMgdHJ1ZSB0 aGF0IEdlb05ldCBvZiBFVFNJIElUUyBpczxiciBjbGFzcz0iIj4NCnByZXNlbnQgdGhlcmUgYnV0 IG9uZSBzaG91bGQgZGlzdGluZ3Vpc2ggdGhlIGNhc2VzIHdoZXJlIGl0IGlzPGJyIGNsYXNzPSIi Pg0KYWJzb2x1dGVseSBuZWNlc3NhcnkgLSBzb21ldGhpbmcgZWxzZSBjYW4gbm90IGRvIGl0cyBy b2xlLiAmbmJzcDtUaGVzZTxiciBjbGFzcz0iIj4NCmNhc2VzIGFyZSB0aGUgY29tbXVuaWNhdGlv bnMgZGVwZW5kaW5nIGV4dGVuc2l2ZWx5IG9uIGxvY2F0aW9uOjxiciBjbGFzcz0iIj4NCmdlby1k aXNzZW1pbmF0aW9uLCBldGMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1 b3RlPg0KPGJyIGNsYXNzPSIiPg0KQWJzb2x1dGVseSBhZ3JlZSEgSW4gZ2VuZXJhbCwgZm9yIGlu Zm90YWlubWVudCBhcHBsaWNhdGlvbiBvciBsZXNzPGJyIGNsYXNzPSIiPg0KdGltZSBjcml0aWNh bCBhcHBsaWNhdGlvbnMsIElQIG5ldHdvcmsgKExURSBmb3IgZXhhbXBsZSkgd2lsbCBiZSB0aGU8 YnIgY2xhc3M9IiI+DQpiZXN0IGNob2ljZS4gSG93ZXZlciwgZm9yIHRpbWUgY3JpdGljYWwgYXBw bGljYXRpb25zIG9yIGFzIHlvdSBzYWlkLDxiciBjbGFzcz0iIj4NCmdlby1kZXBlbmRlbnQgYXBw bGljYXRpb25zLCBHZW9OZXQgb3ZlciA4MDIuMTFwIG1heSBiZSBuZWNlc3NhcnksIGF0PGJyIGNs YXNzPSIiPg0KbGVhc3QgZm9yIHRoZSBuZWFyIGZ1dHVyZSBhcHBsaWNhdGlvbnMuIElmIHdlIGNv bnNpZGVyIGZ1cnRoZXIgd2l0aDxiciBjbGFzcz0iIj4NCjVHLCB3aGVyZSB0aGUgbGF0ZW5jeSBp cyBleHBlY3RlZCB0byBiZSBzaWduaWZpY2FudGx5IHJlZHVjZWQsIEk8YnIgY2xhc3M9IiI+DQpn dWVzcyBldmVyeXRoaW5nIGNhbiBiZSBkb25lIHRocm91Z2ggSVAuIEJ1dCBpdCBpcyBoYXJkIHRv IGRyYXc8YnIgY2xhc3M9IiI+DQpjb25jbHVzaW9ucyBhYm91dCBpdCBhdCB0aGUgY3VycmVudCBz dGFnZS4gQW55d2F5LEkgZ3Vlc3MgdGhlPGJyIGNsYXNzPSIiPg0KY3Jvc3MtbGF5ZXIgRGVjZW50 cmFsaXplZCBDb25nZXN0aW9uIENvbnRyb2wgKERDQykgaW4gQy1JVFMgc2hvdWxkIGJlPGJyIGNs YXNzPSIiPg0KYWJsZSB0byB0YWtlIGNhcmUgb2YgdGhpcyBiYXNlZCBvbiB0aGUgUW9TIHJlcXVp cmVtZW50IGF0IHRoZTxiciBjbGFzcz0iIj4NCmFwcGxpY2F0aW9uIGxheWVyIGFuZCBkaXJlY3Qg dGhlIHRyYWZmaWMgdG8gYXBwcm9wcmlhdGUgdHJhbnNwb3J0IGFuZDxiciBjbGFzcz0iIj4NCmFj Y2VzcyBtZXRob2RzLCBhdCBsZWFzdCBpdCBpcyBzdXBwb3NlZCB0byBkbyB0aGlzLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SWYgSVB2NiBpcyBjb25zaWRlcmVkLCB0 aGVuIHRoZSB0cmFuc3BvcnQgbGF5ZXIgd2lsbCBiZSBUQ1AvVURQPGJyIGNsYXNzPSIiPg0Kb3Zl ciBJUHY2IG92ZXIgR2VvTmV0LCB0aG91Z2ggSSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgcHJvdG9j b2w8YnIgY2xhc3M9IiI+DQpvdmVyaGVhZC4gSXQgaXMgYW4gaW50ZXJlc3RpbmcgaXNzdWUgdG8g aW52ZXN0aWdhdGUuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0K WWVzLCBpdCBpcyBhbiBpc3N1ZSB0byBpbnZlc3RpZ2F0ZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpBdCBJRVRGIHRoZXJlIGlzIGEgZG9jdW1lbnQgY2FsbGVkIElQdjYtb3Zlci04MDIx MXAgdGhhdCBJIGF1dGhvci48YnIgY2xhc3M9IiI+DQpUaGUgaWRlYXMgZXhwcmVzc2VkIGluIHRo aXMgZG9jdW1lbnQgY291bGQgYmUgdXNlZCBpbiB0aGlzPGJyIGNsYXNzPSIiPg0KaW52ZXN0aWdh dGlvbi4gVGhlIGRvY3VtZW50IGl0c2VsZiBsYWNrcyBjZXJ0YWluIGFzcGVjdHMgdGhhdDxiciBj bGFzcz0iIj4NCmFueW9uZSBpbnRlcmVzdGVkIGNvdWxkIGNvbnRyaWJ1dGUuPGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmtzLCBJIGFtIGNoZWNraW5nIHdp dGggdGhlIGRvY3VtZW50LCBJIHdvdWxkIHNheSBJUHY2IG92ZXI8YnIgY2xhc3M9IiI+DQo4MDIu MTFwIGlzIGFic29sdXRlbHkgYW4gb3B0aW9uIGFuZCB3ZSBhcmUgaW52ZXN0aWdhdGluZyB0aGU8 YnIgY2xhc3M9IiI+DQpwb3NzaWJpbGl0aWVzLiBJIGhvcGUgd2UgY2FuIGFsc28gY29udHJpYnV0 ZSB0byB0aGlzIHRvcGljLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPkZvciBwbGF0b29uaW5nIGluIERheTEgYXBwbGljYXRpb25zLCBHZW9OZXQg KEJUUCBhbmQgR2VvTmV0IGZvcjxiciBjbGFzcz0iIj4NCnRyYW5zcG9ydCkgb3ZlciBHNSBtYXli ZSB0aGUgbW9zdCBhcHByb3ByaWF0ZSBjaG9pY2UgYXQgdGhlPGJyIGNsYXNzPSIiPg0KY3VycmVu dCBzdGFnZSBiZWNhdXNlIG9mIHRoZSBhZHZhbnRhZ2VzIG9mIHRpbWUgZGVsYXkuPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KTm90IHN1cmUgd2hhdCB5b3UgbWVh biBieSAndGltZSBkZWxheSc/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSWYgeW91IG1l YW4gbGF0ZW5jeSBiZXR3ZWVuIHZlaGljbGVzLCB0aGVuIEkgdGhpbmsgODAyLjExcCBnaXZlczxi ciBjbGFzcz0iIj4NCmJldHRlciBsYXRlbmN5LCBpbiB0aGUgb3JkZXIgb2YgdGVucyBvZiBtaWxs c2Vjb25kcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPciB5b3UgbWVhbiB0aGF0IHBy b2R1Y3RzIGltcGxlbWVudGluZyBFVFNJIElUUyBHZW9OZXQgaGF2ZSBhIHRpbWU8YnIgY2xhc3M9 IiI+DQphZHZhbnRhZ2UgYmVpbmcgYWxyZWFkeSB0aGVyZT8gJm5ic3A7SWYgc28gdGhlbiBJIGFn cmVlIHdpdGggeW91LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4N ClllcywgaXQgaXMgbGF0ZW5jeS4gODAyLjExcCBiYXNlZCBhY2Nlc3MgZ2VuZXJhbGx5IGhhdmUg YmV0dGVyPGJyIGNsYXNzPSIiPg0KbGF0ZW5jeSwgYW5kIGEgbGlnaHQgd2VpZ2h0IEJUUCZhbXA7 R2VvTmV0IGFsc28gY29udHJpYnV0ZXMgdG8gdGhlPGJyIGNsYXNzPSIiPg0KbGF0ZW5jeSBpc3N1 ZS4gSSBndWVzcyBJUCBvdmVyIDgwMi4xMXAgbWF5IGFjaGlldmUgc2ltaWxhciBsYXRlbmN5PGJy IGNsYXNzPSIiPg0KcGVyZm9ybWFuY2UsIHRob3VnaCBJIG5lZWQgdG8gY2hlY2sgYSBiaXQgbW9y ZSBvdmVyIHRoYXQuIEFzIGZvciBJUHY2PGJyIGNsYXNzPSIiPg0Kb3ZlciBHZW9OZXQgb3ZlciA4 MDIuMTFwLCBhcyB3ZSBhbHJlYWR5IG1lbnRpb25lZCwgdGhlIG92ZXJoZWFkIGlzPGJyIGNsYXNz PSIiPg0Kd29ydGggaW52ZXN0aWdhdGluZyBmdXJ0aGVyLiBJdCBpcyBhbHNvIG9uZSB0b3BpYyB3 ZSB3aWxsIGxvb2sgYXQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+V2UgYXJlIGxvb2tpbmcgYXQgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBv ZiBHZW9OZXQgZm9yPGJyIGNsYXNzPSIiPg0KcG90ZW50aWFsIGRlcGxveW1lbnQgaW4gR0NEQy4g QXMgd2Ugd29yayB0b3dhcmRzIERheTI8YnIgY2xhc3M9IiI+DQphcHBsaWNhdGlvbnMsIElQdjYg aXMgcG90ZW50aWFsbHkgY29uc2lkZXJlZC4gSU5SSUEgaGFzIGJlZW48YnIgY2xhc3M9IiI+DQp3 b3JraW5nIG9uIHRoZSBpbXBsZW1lbnRhdGlvbiB0aHJvdWdoIENhckdlbzYuIElmIHlvdSBndXlz IGhhdmU8YnIgY2xhc3M9IiI+DQptb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBpbXBsZW1lbnRh dGlvbiBub3csIGl0IGlzIHZlcnk8YnIgY2xhc3M9IiI+DQphcHByZWNpYXRlZCB0aGF0IHlvdSBz aGFyZSB3aXRoIHVzLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4N ClN1cmUsIGNlcnRhaW5seS4gJm5ic3A7SSBkb3dubG9hZGVkIENhckdlbzYgYW5kIGxvb2tlZCBh dCB0aGUgY29kZS4gJm5ic3A7STxiciBjbGFzcz0iIj4NCmhhdmUgdGhlIGZlZWxpbmcgdGhhdCB3 aXRoIGl0IGEgY2FyIHNlbmRzIGl0cyBwb3NpdGlvbiB0byBhbm90aGVyPGJyIGNsYXNzPSIiPg0K Y2FyLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkF0IG15IHBsYWNlIHdlIGhhdmUgYW5v dGhlciBpbXBsZW1lbnRhdGlvbiBvZiBleGNoYW5naW5nIElQdjY8YnIgY2xhc3M9IiI+DQpyb3V0 aW5nIGluZm9ybWF0aW9uIG92ZXIgODAyLjExcC4gJm5ic3A7V2UgYWxzbyBoYXZlIGFuIHVwZGF0 ZSB2ZXJzaW9uPGJyIGNsYXNzPSIiPg0Kb2YgdGhlIG9yaWdpbmFsIDgwMi4xMXAgR0NEQyBkcml2 ZXIgZm9yIG1vc3QgcmVjZW50IGxpbnV4IGtlcm5lbHM8YnIgY2xhc3M9IiI+DQphcyB3ZWxsIGFz IG90aGVyIHJlbGlhYmlsaXR5IGltcHJvdmVtZW50cy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQpXZSBhcmUgaW52ZXN0aWdhdGluZyBDYXJHZW82IG5vdy4gQnV0 IGl0IGlzIHZlcnkgaW50ZXJlc3RpbmcgeW91IGhhdmU8YnIgY2xhc3M9IiI+DQphbiB1cGRhdGUg dmVyc2lvbiBvZiB0aGUgODAyLjExcCBwcm90b2NvbC4gSSBhbSBub3Qgc3VyZSBpZiB5b3U8YnIg Y2xhc3M9IiI+DQphbHJlYWR5IG1ha2UgaXQgb3BlbiBzb3VyY2Ugb3Igbm90LiBJZiBzbywgaXQg d2lsbCBiZSBhYnNvbHV0ZWx5IGE8YnIgY2xhc3M9IiI+DQpncmVhdCBoZWxwIGZvciB1cyB0byBj aGVjayB0aGUgcG9zc2liaWxpdGllcyBvZiBhcHBseWluZyBJUHY2IG92ZXI8YnIgY2xhc3M9IiI+ DQo4MDIuMTFwLiBDb3VsZCB5b3UgaW5kaWNhdGUgbWUgaG93IGFuZCB3aGVyZSBJIGNhbiBjaGVj ayBhbmQgdGhlbiBJPGJyIGNsYXNzPSIiPg0KY2FuIHRhbGsgd2l0aCBteSBjb2xsZWFndWVzIGJv dGggYXQgVmlrdG9yaWEgYW5kIFROTyBmb3IgZnVydGhlcjxiciBjbGFzcz0iIj4NCmRpc2N1c3Np b25zPyBJZiB3ZSBwcm92ZSB0aGUgcGVyZm9ybWFuY2Ugd2l0aCBJUCBvdmVyIDgwMi4xMXAgZHVy aW5nPGJyIGNsYXNzPSIiPg0KdGhlIGNoYWxsZW5nZSwgSSB3b3VsZCBzYXkgdGhhdCB3aWxsIGJl IGEgZ3JlYXQgY29udHJpYnV0aW9uIHRvPGJyIGNsYXNzPSIiPg0KQy1JVFMsIGF0IGxlYXN0IGZv ciBzb21lIHBhcnQuIFRoYW5rcyB2ZXJ5IG11Y2ggYmVmb3JlaGFuZDotKTxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+QWxzbywgaWYgeW91IGtub3cgdGVhbXMgdGhhdCB3 YW50IHRvIHNob3cgdGhlaXIgaW1wbGVtZW50YXRpb25zPGJyIGNsYXNzPSIiPg0Kb2YgY29vcGVy YXRpdmUgZHJpdmluZyB0byB0aGUgd29ybGQsIEdDREMgMjAxNiBpcyB0aGUgcGxhY2UgdG88YnIg Y2xhc3M9IiI+DQpnby4gVGhleSBhcmUgZnJlZSB0byBjb250YWN0IHVzIGZvciByZWdpc3RyYXRp b24gb3IgY2hlY2s8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmdjZGMubmV0IiBj bGFzcz0iIj53d3cuZ2NkYy5uZXQ8L2E+ICZsdDs8YSBocmVmPSJodHRwOi8vd3d3LmdjZGMubmV0 IiBjbGFzcz0iIj5odHRwOi8vd3d3LmdjZGMubmV0PC9hPiZndDsgZm9yIGRldGFpbHMuPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KWUVzLCB0aGlzIGlzIGEgZ29v ZCBhbm5vdW5jZW1lbnQuICZuYnNwO1BsZWFzZSBzdGF0ZSBoZXJlIHdoYXQgYXJlIHRoZTxiciBj bGFzcz0iIj4NCnBhcnRpY2lwYXRpbmcgY29uZGl0aW9ucyAtIGlzIGl0IGZyZWUgdG8gam9pbiwg d2hhdCBhcmUgdGhlIGZlZXM8YnIgY2xhc3M9IiI+DQppbnZvbHZlZCwgaW4gd2hpY2ggY291bnRy eSBpcyBpdCBoYXBwZW5pbmcuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNz PSIiPg0KVGhhbmtzIEFsZXgsIGl0IGlzIG15IHBsZWFzdXJlIHRvIHNoYXJlIHdpdGggb3VyIGNv bW11bml0eSB0aGU8YnIgY2xhc3M9IiI+DQphbm5vdW5jZW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KR0NEQzIwMTYsIG9yIGktR0FNRSAoPGEgaHJlZj0iaHR0cDovL3d3dy5nY2Rj Lm5ldCIgY2xhc3M9IiI+d3d3LmdjZGMubmV0PC9hPikgaXMgdGhlIHNlY29uZCBlZGl0aW9uIG9m IEdDREM8YnIgY2xhc3M9IiI+DQpiYXNlZCBvbiBpdHMgc3VjY2VzcyBpbiAyMDExIGFuZCB3aXRo IHRoZSBwdXJwb3NlIHRvIGFjY2VsZXJhdGU8YnIgY2xhc3M9IiI+DQpjb29wZXJhdGl2ZSBkcml2 aW5nIHRocm91Z2ggcHVibGljIGNoYWxsZW5nZS4gR0NEQzIwMTYgd2lsbCBtYWlubHk8YnIgY2xh c3M9IiI+DQpmb2N1cyBvbiB0aGUgaW50ZXJvcGVyYWJpbGl0eSBvZiBjb21tdW5pY2F0aW9ucywg ZS5nLiBjb21tdW5pY2F0aW9uczxiciBjbGFzcz0iIj4NCmFyZSB2ZW5kb3IgaW5kZXBlbmRlbnQg YW5kIHRlYW1zIGFyZSB2ZXJ5IHdlbGNvbWUgdG8gaW1wbGVtZW50IGJhc2VkPGJyIGNsYXNzPSIi Pg0Kb24gZGlmZmVyZW50IGVxdWlwbWVudHMgZnJvbSBkaWZmZXJlbnQgdmVuZG9ycyAuIEhvd2V2 ZXIsIHRoZTxiciBjbGFzcz0iIj4NCmNvbW11bmljYXRpb25zIHByb3RvY29sIHdpbGwgYWxpZ24g dG8gdGhlIGxhdGVzdCBDLUlUUyBzdGFuZGFyZHM8YnIgY2xhc3M9IiI+DQooUmVsZWFzZSAxKSBh bmQgcG90ZW50aWFsbHkgd2lsbCBjb250cmlidXRlIHRvIFJlbGVhc2UgMi48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpJdCBpcyB0b3RhbGx5IGZyZWUgdG8gam9pbiB0aGUgY2hhbGxlbmdl IGFuZCBpbiBhZGRpdGlvbiB0byB0aGF0LDxiciBjbGFzcz0iIj4NCnRlYW1zIHdpbGwgZ2V0IHN1 cHBvcnQgZnJvbSBvcmdhbml6ZXJzIChUTk8gYW5kIFRVL2UgZnJvbSBob2xsYW5kLDxiciBjbGFz cz0iIj4NClZpa3RvcmlhIFN3ZWRpc2ggSUNUIGZyb20gU3dlZGVuIGFuZCBJRElBREEgZnJvbSBT cGFpbikuIFRoZSBmaW5hbDxiciBjbGFzcz0iIj4NCmNoYWxsZW5nZSB3aWxsIGJlIFEyIDIwMTYg YXQgdGhlIHRlc3Qgc2l0ZSBpbiBIZWxtb25kIGluIEhvbGxhbmQsPGJyIGNsYXNzPSIiPg0KZXhh Y3RseSB0aGUgc2FtZSB0ZXN0IHNpdGUgYXMgR0NEQyAyMDExLiBHQ0RDMjAxNiBoYXZlIHR3byBj aGFsbGVuZ2U8YnIgY2xhc3M9IiI+DQpzY2VuYXJpb3MgYW5kIG9uZSBkZW1vIHNjZW5hcmlvLiBD aGFsbGVuZ2Ugc2NlbmFyaW9zIGluY2x1ZGUgYm90aDxiciBjbGFzcz0iIj4NCnVyYmFuIChpbnRl cnNlY3Rpb24gcGFzc2luZykgYW5kIGhpZ2h3YXkgKHBsYXRvb24gbWVyZ2UgZHVlIHRvPGJyIGNs YXNzPSIiPg0Kcm9hZHdvcmspLiBEZW1vIHNjZW5hcmlvIGlzIGFib3V0IGVtZXJnZW5jeSB2ZWhp Y2xlIHBhc3NpbmcuIEFsbDxiciBjbGFzcz0iIj4NCnNjZW5hcmlvcyBhcmUgZGVmaW5lZCB0byBi ZSBjbG9zZSB0byByZWFsaXR5IGFuZCB0aGUgaW1wbGVtZW50YXRpb25zPGJyIGNsYXNzPSIiPg0K YXJlIGFsc28gZXhwZWN0ZWQgdG8gYmUgYXMgY2xvc2UtdG8gbWFya2V0IGFzIHBvc3NpYmxlLiBX ZSB3YW50IHRvPGJyIGNsYXNzPSIiPg0Kc2hvdyB0aGUgYmVuZWZpdHMgb2YgY29vcGVyYXRpdmUg ZHJpdmluZyBhbmQgYWxzbyByYWlzZSB0aGUgYXdhcmVuZXNzPGJyIGNsYXNzPSIiPg0KZnJvbSBi b3RoIGdvdmVybm1lbnQgYW5kIHB1YmxpYy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpU aGUgY2FsbCBvbiByZWdpc3RyYXRpb25zIGlzIG9uLWdvaW5nLiBOb3RpY2UgdGhhdCB0aGUgcmVn aXN0cmF0aW9uPGJyIGNsYXNzPSIiPg0KaXMgbm90IGJpbmRpbmcgYXQgdGhpcyBzdGFnZS4gVGVh bXMgY2FuIHNob3cgaW50ZXJlc3QgYW5kIGFzayBmb3I8YnIgY2xhc3M9IiI+DQpmdXJ0aGVyIGlu Zm9ybWF0aW9uIGFuZCBpZiBwb3NzaWJsZSwgdGhlIG9yZ2FuaXplcnMgbWF5IGhlbHAgdG88YnIg Y2xhc3M9IiI+DQphc3Npc3QgdG8gZmluZCBwYXJ0bmVycy4gVGVhbXMgYXJlIGFsc28gdmVyeSB3 ZWxjb21lIHRvIGNvbnRyaWJ1dGUgdG88YnIgY2xhc3M9IiI+DQp0aGUgaW1wbGVtZW50YXRpb24g b2YgY29tbXVuaWNhdGlvbiBwcm90b2NvbHMgdG9nZXRoZXIgd2l0aCB1cy4gSnVzdDxiciBjbGFz cz0iIj4NCmRyb3AgdXMgZW1haWxzIDotKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkZv ciB0aG9zZSB3aG8gYXJlIGludGVyZXN0ZWQsIHNvbWUgZ2VuZXJhbCByZXF1aXJlbWVudHMgYXJl IGFzPGJyIGNsYXNzPSIiPg0KZm9sbG93cywg4oCiQSB2ZWhpY2xlIHRoYXQgd2lsbCBiZSBmaXR0 ZWQgd2l0aCB0aGUgcmVxdWlyZW1lbnRzPGJyIGNsYXNzPSIiPg0K4oCiTWluaW11bSBsb25naXR1 ZGluYWwgYXV0b21hdGlvbiDigKJJbnRlcm9wZXJhYmxlIFYyWCBjb21tdW5pY2F0aW9uIGFuZDxi ciBjbGFzcz0iIj4NCmludGVyYWN0aW9uIOKAkyB3aWxsIGJlIHRlc3RlZCBib3RoIHJlbW90ZWx5 IG9ubGluZSBhbmQgcGh5c2ljYWxseSBhdDxiciBjbGFzcz0iIj4NCnRoZSBjaGFsbGVuZ2Ugc2l0 ZSDigKJEcml2ZXJzIGFyZSBpbiB0aGUgdmVoaWNsZXMsIHNhZmV0eSBpcyBjcml0aWNhbDxiciBj bGFzcz0iIj4NCuKAokRyaXZlcnMgYW5kIHN1cHBvcnQgY3JldyDigKJCdWRnZXQgZm9yIHRyYXZl bCwgdHJhbnNwb3J0IGFuZDxiciBjbGFzcz0iIj4NCnN1YnNpc3RlbmNlIOKAolRha2luZyBwYXJ0 IGluIHByZXBhcmF0aXZlIHdvcmtzaG9wcyBhbmQgdGhlIHJpZ29yb3VzPGJyIGNsYXNzPSIiPg0K ZnVuY3Rpb25hbCB0ZXN0aW5nIGJlZm9yZSB0aGUgY2hhbGxlbmdlIOKAokJlIHJlYWR5IGJ5IFNw cmluZyAyMDE2ITxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkluIHJldHVybiwgdGhlIHRl YW1zIHdpbGwgZ2V0IOKAok9uY2UgaW4gYSBsaWZldGltZSBvcHBvcnR1bml0eSB0byB3b3JrPGJy IGNsYXNzPSIiPg0Kd2l0aCB1bml2ZXJzaXRpZXMsIE9FTXMgYW5kIGF1dGhvcml0aWVzIHRvIGZv cndhcmQgdGhlIHN0YXRlIG9mPGJyIGNsYXNzPSIiPg0KY29vcGVyYXRpdmUgYXV0b25vbW91cyBk cml2aW5nIOKAokdldCBpbiBjb250YWN0IHdpdGggd29ybGQgY2xhc3M8YnIgY2xhc3M9IiI+DQpj b21wYW5pZXMgYW5kIHBlb3BsZSBpbiB0aGlzIGZpZWxkIOKAokNvbGxhYm9yYXRlIGF0IHRoZSBm b3JlZnJvbnQgb2Y8YnIgY2xhc3M9IiI+DQpzdGFuZGFyZGl6YXRpb24gZWZmb3J0cyDigKJIZWxw IHlvdXIgaW5zdGl0dXRpb24gbGVhcm4gYW5kIGJ1aWxkIGl0czxiciBjbGFzcz0iIj4NCnJlcHV0 YXRpb24g4oCiV2luIHRoZSBjaGFsbGVuZ2UgYW5kIGV0ZXJuYWwgZmFtZSE8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpKdXN0IGEgdmlkZW8gaW50cm9kdWN0aW9uIG9mIGxhc3QgdGltZeKA mXMgY2hhbGxlbmdlPGJyIGNsYXNzPSIiPg0KKDxhIGhyZWY9Imh0dHBzOi8vd3d3LnlvdXR1YmUu Y29tL3dhdGNoP3Y9bG1SaWZMenc4aUEiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LnlvdXR1YmUuY29t L3dhdGNoP3Y9bG1SaWZMenc4aUE8L2E+KSBmb3IgdGhvc2Ugd2hvIGFyZTxiciBjbGFzcz0iIj4N CmludGVyZXN0ZWQuIFRlYW1zIG5vdyBjYW4gcmVnaXN0ZXIgYXQgPGEgaHJlZj0iaHR0cDovL3d3 dy5nY2RjLm5ldCIgY2xhc3M9IiI+d3d3LmdjZGMubmV0PC9hPiBvciBjb250YWN0IHRoZTxiciBj bGFzcz0iIj4NCmZvbGxvd2luZyBwZW9wbGUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K Rm9yIHJlZ2lzdHJhdGlvbiBhbmQgdGVhbSBpbmZvcm1hdGlvbjogJm5ic3A7PGEgaHJlZj0ibWFp bHRvOmwuci5yLnNjaHJpam5lbWFrZXJzQHR1ZS5ubCIgY2xhc3M9IiI+bC5yLnIuc2NocmlqbmVt YWtlcnNAdHVlLm5sPC9hPjxiciBjbGFzcz0iIj4NCihMYXVyZW5zIFNjaHJpam5lbWFrZXJzKTxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkZvciBwcm9qZWN0IGluZm9ybWF0aW9uIGFuZCBj b2xsYWJvcmF0aW9uOiA8YSBocmVmPSJtYWlsdG86c2FuZGVyLm1hYXNAdG5vLm5sIiBjbGFzcz0i Ij4NCnNhbmRlci5tYWFzQHRuby5ubDwvYT4gKFNhbmRlcjxiciBjbGFzcz0iIj4NCk1hYXMpPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2Ugc2luY2VyZWx5IGxvb2sgZm9yd2FyZCBmb3Ig dGVhbXMgZnJvbSBhbGwgb3ZlciB0aGUgd29ybGQgdG88YnIgY2xhc3M9IiI+DQpwYXJ0aWNpcGF0 ZSA6KTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkFsZXg8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpCZXN0IHJl Z2FyZHMsIExlaTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCipM ZWkgQ2hlbiwgUGhEKiBTZW5pb3IgUmVzZWFyY2hlciBDb29wZXJhdGl2ZSBTeXN0ZW1zPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKlZp a3RvcmlhIFN3ZWRpc2ggSUNUIEFCKiBMaW5kaG9sbXNwaXJlbiAzQSBTRS00MTcgNTYgR8O2dGVi b3JnLDxiciBjbGFzcz0iIj4NClN3ZWRlbiBUZWw6ICYjNDM7NDYgNzYgNzc3IDE0NDkgRS1tYWls OiA8YSBocmVmPSJtYWlsdG86bGVpLmNoZW5AdmlrdG9yaWEuc2UiIGNsYXNzPSIiPg0KbGVpLmNo ZW5AdmlrdG9yaWEuc2U8L2E+PGJyIGNsYXNzPSIiPg0KJmx0O21haWx0bzomZ3Q7IDxhIGhyZWY9 Imh0dHA6Ly93d3cudmlrdG9yaWEuc2UiIGNsYXNzPSIiPnd3dy52aWt0b3JpYS5zZTwvYT4gJmx0 OzxhIGhyZWY9Imh0dHA6Ly93d3cudmlrdG9yaWEuc2UiIGNsYXNzPSIiPmh0dHA6Ly93d3cudmlr dG9yaWEuc2U8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClBhcnQgb2YgUklT RTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPk9uIDI3IE9jdCAyMDE0LCBhdCAxMjoyMiwgVmFyYWRpICwgQW5kcmFzIChsZXNzd2ly ZSBBRyBVbmdhcm4pPGJyIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpWYXJhZGlAbGVz c3dpcmUuY29tIiBjbGFzcz0iIj5WYXJhZGlAbGVzc3dpcmUuY29tPC9hPiAmbHQ7PGEgaHJlZj0i bWFpbHRvOlZhcmFkaUBsZXNzd2lyZS5jb20iIGNsYXNzPSIiPm1haWx0bzpWYXJhZGlAbGVzc3dp cmUuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkRl YXIgQWxleCwgSm9obiBJIGFncmVlIHdpdGggSm9obiwgYnV0IHdvdWxkIGxpa2UgdG8gcG9pbnQg b3V0PGJyIGNsYXNzPSIiPg0KdGhhdCBJIHRoaW5rIGl0cyBsaWtlbHkgdGhhdCB3ZSB3aWxsIG5l ZWQgdG8gZXh0ZW5kIEVVPGJyIGNsYXNzPSIiPg0KR2VvbmV0d29ya2luZyAoRU4gMzAyIDYzNikg dG8gd29yayBvdmVyIElQIChlLmcuIExURSkgbGlua3M8YnIgY2xhc3M9IiI+DQphbHNvLiBJIHRo aW5rIHdlIHdpbGwgaGF2ZSBzdWNoIHJlcXVpcmVtZW50cyBmb3IgRVUgRGF5MiBvciAzPGJyIGNs YXNzPSIiPg0KKDJebmQgLCBUaGlyZCBnZW5lcmF0aW9uIEMtSVRTKSAoZXhhbXBsZTogdXBkYXRl IG91ciBMb2NhbDxiciBjbGFzcz0iIj4NCkR5bmFtaWMgTWFwIHdpdGggYSBuZXcgV2FybmluZyBt ZXNzYWdlIHJlY2VpdmVkIG92ZXIgY2VsbHVsYXI8YnIgY2xhc3M9IiI+DQpjb25uZWN0aW9uIChu b3QgRzUvMTFwKSkgw5xkdsO2emxldHRlbCAvIEJlc3QgcmVnYXJkcywgQW5kcsOhczxiciBjbGFz cz0iIj4NClbDoXJhZGkgUHJvamVjdCBNYW5hZ2VyIOKAkyBDMlgvSVRTIFN5c3RlbXM8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBdXRvbW90aXZlICZhbXA7IFdMQU4gR3JvdXAgbGVzc3dp cmUgSHVuZ2FyeSoqKnwqKipPZmZpY2U6ICYjNDM7MzY8YnIgY2xhc3M9IiI+DQoyMzUyMSA2Njcq Kip8KioqRW1haWw6VmFyYWRpQDxhIGhyZWY9Imh0dHA6Ly9sZXNzd2lyZS5jb20iIGNsYXNzPSIi Pmxlc3N3aXJlLmNvbTwvYT48YnIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOlZhcmFk aUBsZXNzd2lyZS5jb20iIGNsYXNzPSIiPm1haWx0bzpWYXJhZGlAbGVzc3dpcmUuY29tPC9hPiZn dDsgKkZyb206Kml0czxiciBjbGFzcz0iIj4NCls8YSBocmVmPSJtYWlsdG86aXRzLWJvdW5jZXNA aWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dKk9uIEJl aGFsZiBPZipKb2huIEtlbm5leTxiciBjbGFzcz0iIj4NCipTZW50OipTYXR1cmRheSwgT2N0b2Jl ciAyNSwgMjAxNCAxOjQ1IEFNICpUbzoqQWxleGFuZHJ1PGJyIGNsYXNzPSIiPg0KUGV0cmVzY3Ug KkNjOio8YSBocmVmPSJtYWlsdG86aXRzQGlldGYub3JnIiBjbGFzcz0iIj5pdHNAaWV0Zi5vcmc8 L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86aXRzQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86aXRz QGlldGYub3JnPC9hPiZndDsgKlN1YmplY3Q6KlJlOjxiciBjbGFzcz0iIj4NCltnZW9uZXQvaXRz XSBGWUkgLSBFVFNJIElUUyAtIHdvcmsgb24gY29vcGVyYXRpdmUgY3J1aXNlPGJyIGNsYXNzPSIi Pg0KY29udHJvbCwgcGxhdG9vbmluZyBIaSBBbGV4LCBUaGFua3MgZm9yIHNoYXJpbmcgdGhpcy4g SSB0aGluazxiciBjbGFzcz0iIj4NCm1hbnkgb2YgdXMgaW4gdGhlIERTUkMvQ29vcGVyYXRpdmUg SVRTIGNvbW11bml0eSBjb25zaWRlciB0aGVzZTxiciBjbGFzcz0iIj4NCnR3byBhcHBsaWNhdGlv bnMgdG8gYmUgYSB2ZXJ5IG5hdHVyYWwgZml0IGZvciB0aGUgdGVjaG5vbG9neS48YnIgY2xhc3M9 IiI+DQpGdXJ0aGVybW9yZSwgbXkgZXhwZWN0YXRpb24gaXMgdGhhdCB0aGUgYXBwbGljYXRpb25z IGNhbiB3b3JrPGJyIGNsYXNzPSIiPg0Kd2VsbCB3aXRoIG9uZS1ob3AgVjJWIGNvbW11bmljYXRp b24gb2YgdGhlIHR5cGUgdGhhdCBkb2VzIG5vdDxiciBjbGFzcz0iIj4NCnR5cGljYWxseSB1c2Ug SVAuICZuYnNwO1NvLCBJIGRvbid0IHNlZSBhIGJlbmVmaXQgb2YgaW5jbHVkaW5nIElQLjxiciBj bGFzcz0iIj4NClRoYXQgZG9lc24ndCBtZWFuIGl0IHdvdWxkbid0IHdvcmssIGJ1dCBhcyB5b3Ug a25vdyB0aGUgRFNSQzxiciBjbGFzcz0iIj4NCmNvbW11bml0eSBnZW5lcmFsbHkgcGxhbnMgdG8g dXNlIGEgbGlnaHRlciB3ZWlnaHQgcHJvdG9jb2wsPGJyIGNsYXNzPSIiPg0KV1NNUCwgZm9yIGFw cGxpY2F0aW9ucyB0aGF0IGRvIG5vdCBuZWVkIElQLiAmbmJzcDtJIGV4cGVjdCBFVFNJIHdpbGw8 YnIgY2xhc3M9IiI+DQp0aGluayBhbG9uZyBzaW1pbGFyIGxpbmVzLiBCZXN0IFJlZ2FyZHMsIEpv aG4gLS0gSm9obiBLZW5uZXk8YnIgY2xhc3M9IiI+DQpQcmluY2lwYWwgUmVzZWFyY2hlciBUb3lv dGEgSW5mb1RlY2hub2xvZ3kgQ2VudGVyLCBVU0EgNDY1PGJyIGNsYXNzPSIiPg0KQmVybmFyZG8g QXZlbnVlIE1vdW50YWluIFZpZXcsIENBIDk0MDQzIFRlbDogNjUwLTY5NC00MTYwLjxiciBjbGFz cz0iIj4NCk1vYmlsZTogNjUwLTIyNC02NjQ0IE9uIEZyaSwgT2N0IDI0LCAyMDE0IGF0IDg6MTYg QU0sIEFsZXhhbmRydTxiciBjbGFzcz0iIj4NClBldHJlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86 YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbSIgY2xhc3M9IiI+YWxleGFuZHJ1LnBldHJlc2N1 QGdtYWlsLmNvbTwvYT48YnIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRy dS5wZXRyZXNjdUBnbWFpbC5jb20iIGNsYXNzPSIiPm1haWx0bzphbGV4YW5kcnUucGV0cmVzY3VA Z21haWwuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOiBIZWxsbzxiciBjbGFzcz0iIj4NCmdlb25ldC9p dHNlcnMsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRVRTSSBJVFMgZ3JvdXAgaXMgYW4g U0RPIGluIEV1cm9wZS4gJm5ic3A7VGhleSBwcm9kdWNlZCBtYW55PGJyIGNsYXNzPSIiPg0Kc3Rh bmRhcmRzIGluIHRoZSBwYXN0IGZvciB2ZWhpY3VsYXIgY29tbXVuaWNhdGlvbnMsIGUuZy4gRVRT STxiciBjbGFzcz0iIj4NCklUUyBnZW8tbmV0d29ya2luZyBhbW9uZyBvdGhlcnMuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KRVRTSSBJVFMgcmVjZW50bHkgYWdyZWVkIHRvIHN0YXJ0IHdv cmtpbmcgb248YnIgY2xhc3M9IiI+DQpwcmUtc3RhbmRhcmRpemF0aW9uIGl0ZW1zIGNhbGxlZCAm cXVvdDtDb29wZXJhdGl2ZSBDcnVpc2UgQ29udHJvbCZxdW90OzxiciBjbGFzcz0iIj4NCmFuZCAm cXVvdDtQbGF0b29uaW5nJnF1b3Q7LiAmbmJzcDtUaGVzZSB0d28gYXBwbGljYXRpb25zIG1ha2Ug YXV0b21vYmlsZXMgKGFuZDxiciBjbGFzcz0iIj4NCnRydWNrcykgdGFsayB0byBlYWNoIG90aGVy IGNvbnRpbnVvdXNseSB0byBrZWVwIHNwZWVkIGNvbnN0YW50LjxiciBjbGFzcz0iIj4NCkl0IGhl bHBzIHJlbGlldmUgYXV0b21vYmlsZSBkcml2ZXIgc3RyZXNzIGluIGphbSBzaXR1YXRpb24gb3I8 YnIgY2xhc3M9IiI+DQpyZWR1Y2UgZ2FzIGNvbnN1bXB0aW9uIGJ5ICdwbGF0b29uaW5nJy48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpDdXJyZW50bHkgdGhlIGZvY3VzIGlzIG9uIHJlcXVp cmVtZW50cyBpbmNsdWRpbmcgY29tbXVuaWNhdGlvbjxiciBjbGFzcz0iIj4NCnJlcXVpcmVtZW50 cy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJbiBteSBvcHBpbmlvbiwgYW5kIHRoaXMg aXMgd2h5IEkgZm9yd2FyZCBpdCB0byB0aGlzIGdyb3VwLDxiciBjbGFzcz0iIj4NCmVzdGFibGlz aGluZyBkaXJlY3QgSVAgY29ubmVjdGlvbnMgYmV0d2VlbiB2ZWhpY2xlcyBtYXkgb3BlbjxiciBj bGFzcz0iIj4NCnBhdGhzIGZvciBleGNoYW5naW5nIElQIGRhdGEgY29udGFpbmluZyBzcGVlZC9s b2NhdGlvbiBhbmQ8YnIgY2xhc3M9IiI+DQp0cmlnZ2VyIGEgY29udHJvbCBwcm9jZXNzIG9mIGFk YXB0aW5nIHRoZSBzcGVlZC4gJm5ic3A7T25lIGFscmVhZHk8YnIgY2xhc3M9IiI+DQpjb250cm9s cyB2ZWhpY2xlcyBieSBzZW5kaW5nIElQIGRhdGEgdG8gdGhlbSwgZnJvbSB0aGU8YnIgY2xhc3M9 IiI+DQppbmZyYXN0cnVjdHVyZS4gJm5ic3A7SXQgd291bGQgYmUgYSBzaW1wbGUgbWF0dGVyIGZv ciBJUCBleHBlcnRzIHRvPGJyIGNsYXNzPSIiPg0Kc2VuZCB0aGF0IHNhbWUgZGF0YSBmcm9tIG90 aGVyIHZlaGljbGUsIHdpdGhvdXQgZ29pbmcgdG8gdGhlPGJyIGNsYXNzPSIiPg0KaW5mcmFzdHJ1 Y3R1cmUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhvdWdodHM/PGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KWW91cnMsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWxl eDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIGl0cyBtYWlsaW5nPGJyIGNsYXNzPSIiPg0KbGlzdCA8YSBo cmVmPSJtYWlsdG86aXRzQGlldGYub3JnIiBjbGFzcz0iIj5pdHNAaWV0Zi5vcmc8L2E+ICZsdDs8 YSBocmVmPSJtYWlsdG86aXRzQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86aXRzQGlldGYub3Jn PC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2l0cyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pdHM8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gaXRzIG1h aWxpbmc8YnIgY2xhc3M9IiI+DQpsaXN0IGl0c0BpZXRmLm9yZyAmbHQ7bWFpbHRvOml0c0BpZXRm Lm9yZyZndDs8YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2l0czxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjwvYmxv Y2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIGl0cyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9 IiI+DQo8YSBocmVmPSJtYWlsdG86aXRzQGlldGYub3JnIiBjbGFzcz0iIj5pdHNAaWV0Zi5vcmc8 L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzIiBj bGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzPC9hPjxi ciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxp bWcgYXBwbGUtaW5saW5lPSJ5ZXMiIGlkPSI4REQ1MDc1Mi04NTczLTQxMzAtQTg3Ni02QUVBNTky MERFNTIiIGhlaWdodD0iNzgiIHdpZHRoPSIzMjAiIGFwcGxlLXdpZHRoPSJ5ZXMiIGFwcGxlLWhl aWdodD0ieWVzIiBzcmM9ImNpZDo4QUM0OUIxMi05ODA4LTQ4N0UtQTdEQi1CQzlGNDFBNjk4NTNA dmlrdG9yaWEubG9jYWwiIGNsYXNzPSIiPjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_7DA761D0F7E34438AB58F989B430E321viktoriase_-- --_004_7DA761D0F7E34438AB58F989B430E321viktoriase_ Content-Type: image/png; name="GCDC mailbanner1-72dpi[41].png" Content-Description: GCDC mailbanner1-72dpi[41].png Content-Disposition: inline; filename="GCDC mailbanner1-72dpi[41].png"; size=40492; creation-date="Tue, 26 Apr 2016 11:10:56 GMT"; modification-date="Tue, 26 Apr 2016 11:10:56 GMT" Content-ID: <8AC49B12-9808-487E-A7DB-BC9F41A69853@viktoria.local> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAUAAAABOCAYAAABR7c9uAAAAAXNSR0IArs4c6QAAQABJREFUeAHs nQecVsXV/89TtrJLRzrsUgUEARUQUQFRscXeuzHGGDXWWGKMmm5v2CtR7MbeFQRFsSJI70V632XL U//f39xndh+WBUvyfv558zLw7L137pQz7TfnnDkzNzRp0qT0I488YpFIxOTS6bSFQiF3v+WfkKVS acvNMRsxZLC1bNHMNm7caKtWr7OyzZutvLrKYvGEVVVXW0VVtcW4JhIxs5RZknhEtgT3qXTIQmGe ceFwxHKiYcPDIuGwyzccDpko0XM4FNCicEonxLuQEV5heCf/NLRGiK83+q+U08qHYFHC8Z8wEYvo BWFDyodfNBy1cDTi8lR5U+kkWUQsStgUkURyOpVQJOKLFj1z77JXutyTD76kp8TDxEm5eGHRE0pZ iLKmSZUQlk7yTqGpX5KBQNJOQz+3yjmVVCi9d2RaMhF3+Ts6SFfvYvEkdZgMAlGfqVCScikv1XGC NMiLBPTPJay8MukRnSYgHQXG5eXlWTQadc+Ks8PtqIH/9hrIxjaNhS5dulh0zpw5dv/99/+osn89 YYLt262rNS0utPziImsFGHbMiVh+AwCkYUOLF+QDhDFLFxQ6UKyIx628qtLWbq60FWs3WsXmctu8 ucLKyjfZ+nUbbOOGjba5rAzQrLRqgDMJkKYSCQa1wzqL5ORYXiTX8vJzLSc3F7COul84EnYA6JBP EAFQJIVKAI9ARtga4apBr38RASHAlwOtOaQZjuQEwM97wVM6hB/v+WNxgMaBD8Am4AWiAZckABiA SEhIiAs5kBbehKA3iOMAm7ByAnQBZwqQEUgRnHuek4QlA4XSBJHkmcQIG9ynk5Q/QV1wTRFP6VRV xa06FmNiibuykowrl/JJKTzvBLgORfFTmR34CtyhLRvodmCeam2H+79cA0OHDgUjGOzeCSiyB4n3 D66MNgaURvCEyVPdD2bQchmYhfkFlp8TtSK4yMYAVH5BnjUGBHdu1dzaNyi0Zs2KbZeGja1BoyJr tEuJRZq3dOAYys2zSH4hgAB3CNdUCcxUAwTVcJObKiptDcC4YtUqW7N2rZVvAiDj1Y6TCjHYQwkG NMCQqE7iDzBUx60SYIjBZsJMARwOChj4AtGI4+CIDJhGVWjHAaahPUS+4sGASwLCEeGXgnvLFfcW IAwgkgPnGyW/GPAijgseC6CiugDRAFwFZppVyI5kSMPhsMJEHD0hcWjQltYL8tQlIXADieLcCwDB c/c+zgSQTsUtEQNU8Q+4PvjTKBNAPNdiMXGHSke8HnmJKsqbzlV6AruAY3QcsoA3SVpw4wLBABxD bmLKbuvttz2F2uF21MB/WQ1I6mXUB86LRv657lXwx+hx/9zI18DFJ87A31xR4d5u9Wf67BqvfO70 K2KQ5zLS8xC/ihBBmxTmW1MAs0XjxtasxU7WpGlja9Wo2AoLC6xdy+Y2qG17a9GjC9xfvqXzcgHO AosXFlmVuMtwDlxRFeBXaZWI4WWbNtnmjWVWVVlhleV63mib8Ksor8AvZnFESARnC1HwkMRngDIO kFYDDnG4tDjveOm4SPnHANSkA5MwojplT+c5wAlYaYFMIH460BQA6Z+rKDhTJQ5AiaOUEJxMkl9U XB00CIcMro4UkrC5IcJK5AcS8cchUqeF4i4tx7sCloAYYJiCTgRyJ6bD9zlAExgqPwE6mQD2wCL3 EsUFoAJfx5UKLLl3kF1nsssGQ5Gww+2ogf8LNVADgH4AbIsTSGtQUSPSawUDk7EmFoiB58DTjVxV mUBE4CA40Hv9D1sVflW83QBgMgpBHvSDcmWVwdVWcJ3p7sVZijDpAlty0x5usnVBrnUsLrCuTYqs e4um1rFNC2teWmo5JV0svFMHSzVpbqGde5o1aOiAMpQHZ4monORfrHyjla1bY5vWwUnCVcYBTLFl ccCgErCsgtuUSL65ssrKK+AkYcnSUeA6mmcVsTTivMKh2+QXhzOTfg4WLPjxLEQLQacDOpWXOgkD YiF5UgdJ3kcB3VSK5xygj/jpalWYakkwKG4OsNIdeUkLGg4Ddlwlwqcj4nh5R30n0uLy0B86dpHY tAeQ5ypLnJ+cuFognvg8U07pPMMZkT3N1be1C7zjz44a+D9cA9G6g6Huc03dOCDTU82NRrp7vWUc x94oVBDWXQM/d/sD/jjOMhOunLE+rwzo1G/VJob6KmuVt9A6ww3u0XCiDWyab12Lc6xpoXSEzSyv ZQuzps3NdmpjkSZNLdqqreW172SFTVtZa8TvECJ3jZPODs4qJU4PQK6qgnPcuN42rF9jG9atA/Qq ASsBmMApYhvQYa7ZUGYby6qtKi6uThxWGr1ctdNdVlRXsChBeoBjKJTgHkh0gI/4LG5QGcsP/ahA K6RVoQTAGAGqCCdRXbrFtERgN7lwLz5bCk3NCoj6SichPSRvVMdKMwQnLbFeCy+pJGFJS9rAEPHc P8cZasFH6fFaKgSl/wOcD7dlG2874vbCb+tdXX89/5j8fNj64mX7bS8fH85fs0vo/erGzw6jex+u rv8Pfc6On32fHX9b/tlhfuj9T0mrvjh1/eo+/0/Q81PzqEtLVAnJ+QRz0eE1bdq0brj/jGeJedAb 4zqD6xwA6NV1IWu9MWSlBTHrlbvWBsDJdVqz0vIWzLFqFjVCLJxEGhTAGTaySOu2ltOxg0XalFq0 TReLtGhlYcTpUE6+RQmS17CZNdqpvbWitGmAsboCcXrzJtu0EdGaRZpqFnKkR5MovX4D/mWI/nB5 cZachc8bKlO2esU6OM5yQKaKNFgJT1XBh2kBQqIud8wFCUAuDm1x/cNPqjmHkwJHIEv60BQ/XeO6 Am5J8qjmXVz3iLluIgL9eKROYACpD/GCaYAyAYDG4Tqr1LSoCaRnhAUFEMVTCoMDTpHb73UeXL43 YCbA9sLX9873u+z0f2g4xfFhfT+Wn7/XO/++vrD1vcv282ll+2XfZ9Oefa949Tmtuuejyimnf9R1 24qfXRbF8flvK3zddOt79nHrS8u/8/HqPvs4/r2u3s+H1bO/zw6XfZ/9XvdyPp3scPXdZ8et7322 3/eF1Uhyzmfep08fe/TRRxlY/2GiEmM4EKqpLHVscTXiZ1R5AgxARVJhA/ya5qJjRHZ0+jLp+xRS IAAUpSMImjKryQH4FFdg4NJwqfEHIFGSrBDnFzd1v8ZCRFycRZgYCzRaSVZcLWIEFj1wgyS/vqLc vvn5udb581nkFwXoBErQKnSDOxPdjnbS0gKL6yiOLj0H9En81X2whMNVUUSi0pG/nvkX8H6CS4og 9YTSo3yiXWWIEPCqxmGbmBOyvCT8pmhwnKBAE8TdhmvdurUddNBB9uGHH9q8efNs2LBh1hj97Guv vUb5xZsHTv1kt912s5dfftnWr19vRx99tK1YscI++ugjF6Br167WsmVL99ykSRNT+I8//hiOWqZF tS4od+3zrrvuavq98MILjqs+4ogj7LvvvrNPPvmExbRmtvfee9u4ceNsw4YN1r17d9tpp51sAlYJ Sse1J0n5NDWR77HHHq4se+21l82cOdOl5d+3bdvWOnfubOPHj68lIOuu7uDx8XwQPXfo0MGKiops +vTp3nubV+V18MEH2x133EG3q52EPN11IwowfX1l3yucp8WPU//s08p+1r0vi78qjez7us9aIBCN Pp26+StfXwbdKy1nyaCEcD6e7vVO6emn8ii8wmaH8fcKm+3kX5dOH9an7Z+zw/l0/LvsNLPvtxKB CwsLbZdddskO87/2XjCxZXXSMJnS1Pp78FDYgAML4vHX3WSAigg5OXnu5yskz99krgnMa/KwjWy6 ehU+BZm8JK6CzFs4gdXWrpYm/84JsAEZNTF8qLogFqQYpCxe0KyYSUE2jU5B6LhLwjBZaEHEdxDl 5DuOOua1115rHTt2tN13393ee+89+81vfuM6anFxsY0ePVrBrYCFqN/+9rfWvHlz6927t3322Wd2 +umnW0NMoK644goHevvss49dfvnlDiQFjkcddZQdc8wx1q5dOwdsa1nZF0CtXLnSAaWeW7RoYX/+ 85/dAGnUqJGtQw1x7rnnOo7p17/+tV144YUuHQG0bFBFg8BPP7m6nV3luOaaaxx9F110kY0aNcqW LVtmJSUltmDBAkf7mWeeaV988YU1aNDAcWfKU3QtXbrUpdemTRu30CZ/0afxsQrLBKlHBL4/+9nP nElVNgD6+nREZf1Rvan82XVfH92ahG688UZTHag+le8f/vAH+/zzz91VpmJyO++8s/3tb39zE4/q WhOCyqs4s2bNcvX4+9//3j799FN7++237S9/+YvNnj3bHnvsMRff11fda//+/e2Pf/yjrV692n73 u9+5djvyyCPtnnvusTfeeMMB+PLly11empREw/XXX+/qzCXMH19GpX3BBRfYCSec4OpMJneqB5XF 15nPX3GPO+44V/8yU1MbvPjii1u1q89D1+y427rPDl/3voYD9C+UiNBZaO2dT9gXyvv/J1xFm5s0 GNvcUfMCAg16ARt/5eWeA2r1Ro5oxBMvFXB8gYcWJAL+yqXiAmfSD6IpJv/kiOcCuQf3RyYoaeot DvzI/EXQp3R9ntkDQ3Rt5RyxQerZ70SrwzEBqcuTP5lg2VFq0oQwZjbyF59IQMeBKoqAWHGVeSYB 3SkDnOi7/fbb3fXKK690nI04LYls6rRSj/h+cdVVV9mQIUPskEMOsW7dutnYsWNt8ODBVlpa6gBQ fUj+p512mp166qkmgGvVqlXNgNZgOvnkk+3WW281pSWA04q9Bos4QHGX4q5uuukmE5jKaFUArMEp p7T3228/e+6559yz/mjQeE5F3KpoEHho8CqtCqwVfvWrX9mxxx5rb775pn377beOI+nVq5ejQ8Ci eALy2267zRYuXGh33nmnLVq0yA1wDXSBnrjhl156yQGCnh944IEaGrLbuMYzc6N69hxd3XfZz+Kc xZUKwH/5y1+6iUYcscrRs2dP+/rrr11wlemVV15x4DJ8+HAHHCqvOHbvBIqazMT9nn/++a4cqkPV wbvvvuvoEZir3pSvyqU2FEiK+9ako/hPPPGEnXPOOU4qEIjLkF7u0EMPdXHFpWc736fkJ5oFyPfd d58tXrzYRowY4fI95ZRTTHUvOsTVK30BpaQI9TX1LU28jz/+uOtroufBBx+smZzV36ZMmWIHHHCA C68NHZqQevToYTNmzLAxY8a4vr29NtlKB5hNuC+QEvj/7jRGs8gQnaLLFU7EMehlTuKAjIBujOs9 r9SxP/v0E9tUXsawZ1A028n2GDCIuAK8wAVFJH4mjsMJvcoECDgrQUqQpsuKQHqt+6COJIoH/J7e CHxEtk/DPfkMg5h6S7gM7ylE1X8XRil4fk7eLifnF6C6S9kFFu1KO0iaOAI8xXVlERDyTvUFIGiB xu0acWFc9jV/BBjibm6++WZ79tlnXZnE5YkT2YyZkTqoBsNf//pX1+GOP/54xzGKU9DMXlJS4oBF CWpASYy++OKLHZe3Zs0aN2jEjUgMFOcgLu6GG25wQCOgVZt26tTJTjzxRLvsssvs0ksvdQNFopZo ++qrr7CBZAGJtDWA1fkVrgz9rMRrpSv/V1991Z555hkXR+LpgQce6MBBIC4uVGE18MQNqm9IRBct GkACCQGt4kik18DXgN9zzz3dhCAQ1CA77LDDHGcpEBVweFff+PHvfuh18uTJ9s033zigfeedd0xc KDu2bMCAASaxXcCnSUnv1D7nnXeeiSMTMPfr18/Vj/ISR6+6EeDdcsstLo7KK263tLTUcXlPPfWU AwzpJr36QmCrdFR34o4lEU6cONEEWHPnzjXFEehoMtx3331NHKs4N9W5OGQBnCYjSRCqV7XZoEGD HLgJwASaqtszzjjDqSQuueQSB3QnnXSSm4BUh/qpzc866ywHmmpnTUS/+MUv3ESmOhBdAlfRojKp vOoD4u4lJagO1T7ba5Ma2Wx7gbbdcCK0Vk8QhAsG5g9N7/vC1bwPRncNKR6U9V6vHCwJCQA1eQQw FQQvK9vEQPu93XL2Ofans8+Fy7kVU5YtdVEukkspk4XLT2hUCyyCKh/OZaU/yslduSO4VmIFR/ov cxW3HptmTdZ5BeFdDj5cTZ6iWJAZd+kI5KTXc2S4Py4W3tS5fkEuLlMBnHsOMuFNwMlqpwyW2ryD G+WdFj+SMtuR4jJDc5Bq8FfA8vDDDzvuS/fS44kr0+BSJ1fHlygmwBNYiKOSXkvgJm7p3nvvdfdK TTP4tGnTHKBInBPnI45RM7yASINCIKvBIpBRO7Zv397da2CJ+5EIpAGgji4aRJN+qm8NWImlCqtB JyfAlQgoYJBTGKWhQTN16lQXT3FUlrfeesulKc5Sg0nAr3casD5dxRV9qgdxsOKUJLJrYKrMAhYN 5n+3E/crAJbYKhWDnEBWnKm/Fzhp4Ou9QKlv376OLgGP748CBNX7P/7xD9ceaj+J91JJSBRWGgI2 gYg4RQGfnNLUhCbuV5OMJkBx76p7AajqXD9NHErjoYcechy82lx5C5TFGSu8nLhFAan6jCYdvw1T 4Cx9qOqzpKTEtCtNkoTe6yd6FtKvVP8qi/IR/eJSpZoRVymOXe0ljlVlUr9SPxTAapL9PreVCPx9 EbZ8Xzv4HRBReO98I/jnbV19uLrxfXi939Y777/FVZBRS4ZLRjASzcu3tgDDBtKL5OVaEhDJ8ZnU c/VpZr/yfrrKedprwmSAyam3MYMJN21ieSOGWnrtGqsaP9HSMZaKJR4LsJg4wpYLd1btRFULcZ9G FNm5uyUWIE7QkIHIqsIE+dXks60b1X9WUAefwmzJz5jzCCYDLeeWOkCfnDqZOqDEJQGDOpwGkMQq dTCBgH4CHIGXOroGhjqr9IACFe/0rBnbcykaMNL7KC1xdBpYAjZxHQInOfkrXQ0qcT3iFiQCaYBL pBF9AmgNIonG4hwkKn7wwQcuvrhI/bxTOA1kDTCJQ0pDOjFxMiqHOEGBr8BMorQGm0BCXIMGltIV 8EhsUz7iMgSK4rTEkan8qgufv/L1/dXT8GOuPq7yln5TYKbJQ/UhnZwGvPSdAmk5gaT8xZ2rHhVf AC2gllM/FTiIXtWXOHi1p2iWmCixVcAvkVrApslOTqCvPMW9C0zEtSu+9HHaeKBwqlulLW5LtKp+ RbcASECX7VSv4swFdhKDBVTiYFWvahtNbqpfcW9aLFNfU7srjOhTu2lCVH9QfHHIKq/iKK4mVnHH ak/RozIuWbLE1Us2HfXdhyA8LdbTOyU2DnlcHbY+lw0CWwFAfRH+A/zWrFltp5x2orWePMfWYkPX aL+h9vBDD7O9Lbce6oQgAp0f79ZvLrPPD/qZ9ZwwVQycNTjrdEtsXIGZDbtXPp1q4WI4lSpxYJi+ RFjhW7DY8np1txQG1snZcy3ae2fLP3C4bb77EUtvqqBDY9aS+fdDqQGDiREC3NN2XqsCe4ci5rB1 LhXHHIddKO7gBoBGO2fcYRU/NOF/czj1HQ0qdWLpsfzg/1ez+Xel82PpyB4LfoKsm4Z0mxprV199 tRv4dd9n066JQoAr8JArLS11nLdAweelfMTNCngE4vKX/k+cuQDNPwsgBUziIDXJCCAk1osD0wQm PawWOwR0ckpD3J04OAGd4opLFrgovugSd61JRNy8JitZDGzLiYMUN6YJTHFEl2hUOqJB+QnoVGZN pgJ44Y/KpXxEv/KVhKD6EGgqTaWhMJqklJYmXNEtgFZZlbZo31Z7SIf8ozlAX/n+Wl+hxSBp365z 3Kswnh2uL/xP9fNgvHX8LUFMcJbAdo8lCif+SQ/oEGrriPj8NPBzSSmqjx6mahvAaU6YZ3n7DLFQ zx4W6drBqt5+33K67WzRTh0t9sXXltt/FwyjAcBOpRZqUeROqMkwmI5eAVpNmi6TH/ZHZKh+ZG7j yBI90Yy2EdF8W07t6jtM9r3C133+MX5181MeAgJ1UJ9u3eu20vdpKbzctvuBDxnQ7sN63+z8/Dvv 58Ns75od1tfZ9sJ/3ztfDl2lZtDPO4GPdz6cnsUBeSd/mSR5l/0sWj2Hp/fiquXkr0Uocef+uS4n Lf9sgBMg6ae44jaz3/k6yb4K0DzX6jLJ/BE3KSfwU/js8maCbMHF+XwUNjs9cb3eaSKQ81fvv63r jwBAjUQ5Oh23M2dNt/c+eM9mws5WUpCGRcXWuaTURmA31rG0FEX6jTYZuT8KGz98/wPsl+f+Oohe 5++GDWttIqzrZ198bsspiLp061atbff+u9ve++xbo/eoE809Ug/OSbE/Czb53ffftVlzZrsTU/IQ c9u1bmMD9xiAwru3devR3cqnzNZoCUTCQPDcKlntH54wYbx9+eWX9t2K5W5wtdyphaNn6NDh1pCZ xznydPrGrVIINHk6wCDEAQ0RZmjp4awoz2JffWGJNSssf+T+llq73sLsZ67+fDJA2cBymN0SK7+z SFN2sVAwidH663dvbJXN93koDZWVhLR3mOkXzGeRhtnfQaKvvO2kowEk5zuzf96WnwvMn+xw3q++ q8BPzofX1eflw/t3/jn7mv0u+z47jL/f3vvsd9n3Pu62rj8m7LbSkH92mX9omnXDKQ3v/Dvvp2fv 58P4q3Rl+v0UVzdNn5/Sqvvu+9KvL3x2vdSNX/edz7u+dOrGzX6uBwBVkUHHzw6oASn+YcWKZXbP 3Xfay2+8asn1ZdYC1rQQe7P5xHmfcX7fQ/fZvkP2ZtVnT0twGMKzb75hJSjKA6d0axvqvXffsptu u9nmMxsVxxPWkAMDZJoyifE6evTj6AN2sUsvusyG7DM0K36mcklGULOImXHUvXfaO+++Yym2qbWA uZNuTzzOJyj7H33kYevM0V1HHHm0tWvWzu59/FFOkNHMI52YnATGgKYP3n8P84ebbAYgWgjH2Fhb 0AC6z6DnqafGWC+4uPPOPd/2P/Ag6JRyzUWvLZIAQ50N1IlwcELFP9+ygsMOtOTCRRYD6EKNG1lo PaeyLEbHh8lMbObsIHcmifR8xOE9d7fkkmWWrtC5OKRPcr5fa0FE5IhS7SgR1cEqb2Bn6BrevQy4 PNGh+nFPYWojhUZRJKek2tCu46D0PGzhlI6U65phpeeSy+5U0h1JdyMO4Mc4SQFStGsWlzGzOBCJ M3Wd8vKdWzo22QEqL+l/JP79O112uZSuz1finvRrXpelRQMtFNx9993OXyvh0n9JH6nVUi2GyBQm mxP5MXTWpUP6N4mD4vq06ivOTeKcdxLvJHZKV+td3TTkX5+fyqZ6FP31ufriSB8srlDiq9pQOkRJ dAJO9QU5X3c+TYmrojubU/Pv6l5LS0sdF1i3T9VHi+LW51+fX9186nuO0LjX+dUfBVAFnXHGmU5e 17MSVuH0b+Gi+Xb+BefZJGyoBlaGbFA8ak0BnAb82vPbLck2Og4S+HbWDJs4c7oNRsZu0aGd5RcW 2fD9RpAYCZJWMpmw++8ZZTf8+Tpr/N0a2ycesV5VYWvEdorWibTtys6FUraKLYK9f+aDtywHDqpv v/4BTQ4URA0K+/fesfMvvcjmTPjY+nG4wKAYaZB/UTJlLUHsXQHUTmwhK1+5xt6cON7ibVraXocc jHI513GXOVFWzPinMj7+2EN27R9+bzlLV9iQRI71ByObAYI7gR27JlgRBTgWrlphT7//jsU4WUY7 DJyeVKCTcVWcKrPsyaet+aKVrDtwcszm9VY9+StLzptjoSoEcLbPSfSOT59msRl03o2IERvLLb1+ HZMJYVkYSHw7A4DLI0UHcc6Q2e3ycMo9bYbDIVpDNOEUxt1Sr7rhT0ZmFsy9VRS1xYi9UQEm6An/ RzCFYYtdjMUX2qGuk/JZA1urbVrUEOBJdyNdkXQ12iWkTi9xRcpy9Q11cimhZZirwSldl0Qx6W2G Dx/u9DVS6D/99NNO4a761iBSXur0fqVTdl3S72iwqW7/9Kc/Of2O8pa/OEaZU0i/Jac8tUIoWpWG BqT0QQMHDnQLFBrkMneRzkuDWHmp3UpKStyAk399TkbbAjvpJlV2rVxrVVN5KR3pnhRGiyVajZQ+ SvUksw/Vx7acyiE633///a0GcXY8mdxoNVsLQlp1F51asFB9yUl/JzMcLR5JB6a6lJO+TGEklupe baF6V92JfrWHbCqV19lnn+3qWO2oNKRDU1kVVldNPhJRBfCPsSihBQbpA2WnKWN1TRB6FkgrL98m fuVV9Ku/aGXX0yh6VBbRITpFt+JpoUUTotLz+aqPKIx0jKJHeaj95af4+v2rTiZX9XCAtcl68JOP OuVll19ia778xn5enW+fFqXt2bykFTZpbA3hbCoqqqxs9RrrwPl8IzmzbsnilXb3w/fazw49Eu7r KI1nB35a/bxn1N12y5232lAAqzX7eceTTmWjQvbhIv5R8DWIwsUsDIyozrGFG+L217//jS1oMTvv /N9kpM6QvfvOm3bplb+1DhyQsE8yzz4BMz5rGLbGLdtZEY1ZyYkvG1etsTDHYg0AmPeAeXjjtddt SuepdvUlV1GhbP6FKEHImCf+YTf85Y82pBqgA/zezau2suYF1qRlW/d+AwCaR6cayfvV5Skbdc8d 7kSZy6+82s2Evp50DVKU2Qlb5gYMtCaXnQtXt9Q23nAzgLeR4okNE18mPjEAJKYE/OQrkxUxaxmg kyeitHP45Q7ai7S+s5xB/S0+6WuLL13i4khUDvIWx8ehrnp2UBeIvRFWgQMQhcMm+xDcYPaACzII /mqAiNtQx5NCWQbRr7/+ujNylimDOBNNkgI/dSB14uuuu86tVmqFVANcwCBw0uDSQFWn1yBSeuJc BBbS0ciGTEawylP0C/TE8ci+UJ1dQKoVRuWrd7K/k9mJDKu1WiuA1MqoVggFuDKOFvckA1oNGtkr ypBYA+yMM85w2/YEWFr59cbEAjT9tCqtASjA8CYhskdU+bVAoDRUPuWptLTK7Tkc0SKa5VQOOdWv v3ce3/MnO6zMSTyQCDRUdhmoC4BlWqRJSO0gukSHr8eRI0c6fwGUjIb3339/t0KtuhAH681IRJvs 9kpLUVnRjk8++aSzp9RiiHZnaPVXZRcAC6DUZh7gtOqsdtEWSFkMyL5QQKd60uSklXnVkZx2p2gr pe8fWrBRe2uCVX0K1NQeajNxlMpTeas+xZRpBV/vdK82ueuuu1x7ClyzOeLvqdrtvtZo/EHuySce t+mffW5HxXLs1UZh+xLu4rQzz7Knn3zOnnriWXvmyWfs77feZpG+PeyRfGYRVjmPLgvZC/983p5/ 8VmOlJLYafb5Z5/YAw/dZ3sl8qwDnN/zxWnrd8hB9vDjowGip/k9gzjxiHUasqc9l5+wDlUJ68nJ K/c+eK9NnYK+jIE96dOJdsU1V1m3tWW2D6epPFmQtlUlrewPN/wJep6xJ/4xxp5+4jl76OHRtv9x x9uHzXLs7cKQHVqNfdH8pfa7639nE8Z94NKaMX2q3Xb3bdYrmWMdAOMnipO2C8vx9z/8uD1JGk9B z0OPjrY+cLNPFCasIJawgTAgTz43xubOmaUibQEm4cwAEAQV//oMqx43Ft3fN5aLeUvTB263ol+e galLJ2s2+j4rOGKkFZ54hDV/+jErOvs0y9l7kDV7bJTlDRlghT8/0Ro/cKsVHHKANR71dys89QQr vvw8K77gbIvCcRQctr/lAzJF555hBccdaY0fusNyd8NmLM0OCCBQ4A4KuANbtfWNMQT4ScWAnzjF bTgZCmuW1cyvDi3w8jOwQEuAI0DSoFBH18AQ8IhD0GDQjC/gEScmEFQnlgGzOAuJbIorjknirzg0 AZwAVml4jkLvxTUob3EmJXBsGnQSNZWfQEE0agB6swiJqwIyAZgAQgAnMBV46KfBJtqUv8ol0JST OKtdKBpgchqk4m40IKUKUF4CUSnqtSNBnIf8xR0qXeWntOu6bECr+25bz9mTkupLTnWgfESvdqeI Q9K97C+1P1ocmQBIdKt+JN5qdVN1JnoFeiqvuHQxMZq05MRxyZ5O5RKgaCKbP3++m6TE3WpLpMBR TvpwhZcTPfoJgDQhiQ7F1a4ebYfUwpY4XLWb8lY9qC+JboGewmt3kLhX5a/JTxy1yijzJJn9iH6t lqs/aHFG/UG0C/Dl9+8CP5VnuwDoG2Q95+g9//I/bdcUxq0FiIK5Ebvyoivsiquvtc7MSjvt1NI6 dCxh5v2ZPf7wP9wM/W5RxJajgzs0jujz3DN2791sAEc0HQO6h8oqbFdEwteQnU896VS77ZY7rV// 3WnENtaagbXnXkPsrttH2YA9B9q4Npzv13In48Qo+/LzSbZ2zWr7/fW/t7w166w3APpEUcJ6DNrN HrvvUTvmuBOsbbv2zJ4trBUdYjcG4N/+frPdd9u9lsehqq8UxO3gihxrvGajXXnt1baIQfjiC8/b plWrbTCmU+Ny43boYYdDz+02YOAg16laQdNuiE033XiTDdp9oH3UuqFVtm5pOYjWH380XnVY40Lg ing6gY8OI43ARQn8yp57GhMX7PsWL7W8fQcDjOcg8mJPd/jBlr/vXlY9Yyrc3R7W8JJfWahJQys8 iK09u/axzcx8yQ3rMRHMs3w286eWLreqL7+2SPeuFmraxIp/d75Fdu1hBcceajmoGgoPPoCcdWAB 4AcxOVGMUDkMIcpkJBBzdtGIyDpeX1xiXadB1Kd3H2eAK7AYNmyoA62f//znTnSUaCUxUiKaBovf tyu9noBAnIvy0b2AQjZr2lmhASjg1DuZWYm7U1oygVEfk8Gv8hPXI+t9iVUSv7RdTSKgwE0AKWNf mUkIHDzA6FmDR3lrYAo4BWgCNoGgBot2EQikFEYAoQEl0JDT7oXDDz/cxmH6JSdbNHF2AkrRoIGt 7XMSX8V9SrelcqhsKrcGusooMJLzY8ZfnecP+JMdXqAksV5cnABLz6pPTSACC+Uv0BHQiBsX9yq1 hOpBNnKyS1RZBVriWqU/Vb0I6NQ2qn/9NImp3Npip8lEaSsf1a+ASjTJz7eXL4YmB+WlNpSTraf2 CKtNxKV6ExqJ7apLtZHqUn1GaWkSk0iuCcqL6xLr5V8KVyonfare61k0yQZRdGqi/Xe6begAz3CV rAKpEj4cP85eAriGVaN3y4nb4UcdYxdfenlNY2cTVEDD7MUiSLNGje2VaZOtNedE7QKX9syMyYBC yL6dMc1azllia/hKUapnF7vxb7dYUXFRdhLuvoAV0uHDR9jIw4+0g48/Afb4ZOvUtZv9/tqrbd7n X9iRiMdvcwR8L8Soc885z/phPS+hEmEvk5ZEkeC+Y0mptW/d1uauXWUfLVtghyDKLti0wb5YNMfa dOhoiUkYgrIIs27nUrv95tutUeMmtWk4vZr0KwU2dOhwO+SIo2zkicfbCcefZLv02ZUBUEt7Vaza 6QB3WqzDEAAaVo+LfnGGFSK6xqfMtbyDhlqKb6DEJn5h+QftZ7FvZ3LqDCfXuMWP5SyWLLWcnt2s 8pU3OcUqzyrfet3yh+9D2OEWnz3fkguWWLSkvePkqt790PKH7W0Vo5+0cG6+5XTpbJufftHi8xYB bgAedT2WsxK/y4taHrtOdECrxGPVCuOHE7KrAIxgFTZTWLieiH088WMngkj/992ylfb+B+8zuBbZ 66gPvvp6sgMtcYLi2jQwtctA4CYAkx2WuAUBw4zpM9zOjOWspL/x+tvM+N/YpM8m2eq1a+yzSRhJ szA0e/Yc9Iyvo99ahiXARDdIJD6vWM6qJPR/+cWXDODFThcpesRJKs+X/vmyfTtlqn0z5RubN3ee G/QS3b7AkmDIkL04z3GjXXfdHxwtEhFleCtDZ4GB+rSA1du86dn3c9WDAF66SuUnUJBeUbo9DV6V S2K9uBI/uLVQJNCRmKaBqrS25batAwz6KUV2Y0p5LFmy1E1AAhbRITd16rcARjkWGLMdI/AFdb1w wUIHxuKoBC5SXYgmAb/aRYAvTlyg9uQTY2zBogUujsILZGcSZui+Qx3nJTWCQEhgqglEqgKVTdyX 2sU7AbDAWGCk8gpUtQtHE45O3VE9axLz9aW+oTIpDdGj+he4ycmAWvmJbhlsK1+J5BKVNbmIQxTA i15NntpDrjT+HU6Ty3YNoT2E3DXqThvz95tsOLq0F9iNc/89D9m+yPYB4GzNRG7cuM4effgRjpqP I9o+bMeuS9rCHNju9s3tzNPPtFW3PWBvb1xlfY841O4adZ/jlrILlN0hs/0feOBeTp74k51WlW9T o3wrY0BfO3CfYdYSjuzoY08gaECx74S1s2rarrzsUmvWsrm9/9F4q5g6zQ6ryLMxhXEbedrJttea KvvzU4/ZnmecZrfC/dV126Knbrh1FYEhdK/x7GzQIggGz9EB/TB0WmOJeQstd2A/SyxZZqnlqy13 9z4WnznDGv/xWkusXmnlDzzO6ItZDmJsYtocvu/BQsdaFk2YPaN9uljqu5WWXrPBQu1aWRr9aGrV Wos0a2xp9K4pWL3orjtbcipiSplWZxH7+Ht5SRP7tJAv+XEuoY7I15a4ahaJUAHamlXLrbxskxtw vr58eTQcVZP/XrftVDXwt8ANPFzoLTy3Rc2W6WrArF+/gQEzZVsRtumv/lK3LrYZ+Ce8kBhfnyF0 zaStouC2T0MmEC2keNI5/ytO4mhpSaldf8P1JFOb9r+S5r8jrkRm6RvFTUqsFicuLlLG8/8u972G 0O5wATqFZgXxDhX8chDHmiB+BW5r8JN/NJoLe/629WzV3o4beQji84t21uZcW7t0lY1D7Dnvl2fZ i7f+HU6r0Vbgp/i1wKWnwE1B/3f/Iw/YfiywrIOOmU0K7GwONHjmqX/YdX/+axAowD93v2UaGIHC ri8Z84xdce75diVi5aSFq2w4+swXnn/eOp11jpXuM9iaFAWrbJksf/RFC7DB/l04AeqNDcdW/ckE YEd7fBu4hQsJnxQQ+7+v6W5sVr/tQcRcQIzVYAQ5i0/4lLDsqeQvZ7pYKI4V/8RJhGQGwSVnsaJM SMVNfLecv4Rh5k9M/Jy32osZLLCoK+eRlQxeJPvqE6HiASW6CN7W8SyXPdicD/GdH1duFJtfMMyc 2Q2FDD4Iha/eq5yZdOreB+lAKfUigVs0Ky3FEK+uVBUnSB1fOFW3WOOAT2H1LhDVXbgMPW4lR2EU N0ND0PQhx6GKnsBMSRyZnmqdT6fWJ7jblr/ebuud9697rZv29z07lawnFHrFYaXcQhU1k6Ff1eyN 2gOvoN5dZWaV0dPi6fZ519RTnbDPPvuCswgIQJj6pH3VBkrXtZ9PIOuanUeW9zZvfXh/9QH9s67Z TvlKypDILtATV64FGl3/3a5+BKuTSyHiqE4n1rppgtXY9eiv5LZVQdUQXc3gX/bme9aH4+h32X0A +reE7RuL2vSJn9iLS+fbISD6Zk5alt5mW86nv2L5Mrvuhj9Yw+XrrXM8ZO8Vpuzwg1jpmznXlsBu b5J5CS5o29pB6dONw4mWV26y2KKl9u3rb9lxx5xg04vgsFhh7b8xZg+88LTtOXS4NUEHVR89dRvI p1v36jqya0xAJBWz/AOGW+Orf2f5J59koQboxYAjNiJZ3uABFm3R0kWPLZrFokg3i7Zux9vNNWXg +FXuK+mH2BSGCrlnCgoBdh7kBHTuma6re1onFBIwEkMVoR/+jRHR85mQdBZ0GPDTd5gl6kpHme1c ZyRuUOfq/QIeLeUEfL4GBi8D76zBofD6+c7s28xfHT2EdwPYpeWtEANIVJpuohXB+q+wosPlHYCf 6PR5OJqhjVjOT5HcO0deJjyZiW68tnKeruwXnnb56V6/+lz2u+w4Pk1/3Vb8+tKUn3IL2tDdUMcq h8rFxTmVVTcqlxx/XaTMbR16ff6ix/8CepWP2op4/JRmVZW2maFTdZ4+9SCecvLOpxmkE7R39jv5 +zDyz3729eKv/r1/9jT6q09Xdoce9Pw1Ow8f7l+5bjkKMikF1eCq2fn0ZAVzE0fLI01ZXixec+RR honYKv+vv/7KlqPw74eO9NGHH0SXN8wKunexD/JSdjTntL/zanCK8H6stukD6t75CvHPKqx0QOdd +Gubj/5naCJszwGkg9H7NWB1bv4b71hLjrN/7a3XnE2bBo5r2UwCPr1Z2NxNQYfQL1JsX6G3WLxk sZ2PovxN1HfST5Zgi/j4M0+yANMacGDlYDsuCbD7X12wVO4eIbQYUXD0ocwYnKW3N0cpnXSsNf7L 763h5RdaTq8eVnjkSMvr19uKzjrT8gHEvEF9rckdcMV//r1F2rW2Rn+91pre/EdDBuC0afFxrAqq YVwmus20kjgy9WSxWfgJGnyYGBxVFWNJK/IN0c3m5QpE+RYy4nUErjDbKQ157drabFDHsA3sgJ1n +4jt2SFsg7gvZr7o0ixsu+OnT6HWdYpff+fE35EaxClgUWZgu5CN6BK1to2CUhDCOjYmv458YpVP isr5tPxVfsrDJaUHXOem0Ak9SlP+PXcKWb82+j6KqkCpbk2ni1jnj6s//JSXy0P1mXnW1b/3Vx8u O4zu5bLfBT7f/9dlp/rjn2QFka22qP0FbRNx4MXiFvXveGlmC5XQ06WcPP3Z9eb9lXDAYSsgJ+pE mRZJSzkH+Qbp+bhUR43LzqM2veC1zzM7jPerSSA7MTyzw/r8asJu58bH+zFxtpMc8lN9rk4H2LVv P2vRsZ3Nnr7AesGJvILievCeg+1nLAjUdUuXLrGb7rrVum3mYEnAZCXL7yuXrbBb/nqTncGCwNyV ZXZiGaYrGBSXb0ZBu8eeVoiyU65uoWajaL3sikts4fRpdsrmHBvLokejrp2xFbrMrv7D1Rx7n7K9 WWX+JydDPI7pw5ln/2ILcpTeBoyMtS0vza6V1hgDf5sTttUYNN94w1+czdPTKF5PxTymbNk6u/XO 21AMN7Nhw0dskY4exEXefstNLOJMtyIMqTdXVdvBrAoed/yJdcJq8GR6DnGqMbNJo3cTlxduXGwb H3nUis47jwWPJVb8xyssPg1TmhgAx6pYqGEDDk7Iw7TldLO2zS3chA3kzZtaijKkxd1lBolEWUGB cnE8D+UUyLjOgafDQgCzAYCXk8uhC5QP4xfLzwtZUSFHGkEPC/LOqY58p8pHOn742Fzr3xbRnK/h SQzLB1xyAaWh98TspP4RO6Bb2PYalbQVbmMC+apjQ5f7p6LXuGAwBXXBW9514Ij++46O2n5dEMWJ tmRTjl31Rtyenpy2swaG7by9QjbkTrY1rkEqILyjTTdbOA1YuZT9es88O6G/2d6jYjZvXdr+enCO lTSJ2LD7Y7bOfalVIK/QSkzpcdV/efk2ctcAfFSGWv+AZoUMInNxcX0Yld29DKK4NJV25ibz6odc XE2hL5axuijRxHPtAbQxIFVNG8i0Sm03bWXa7p6QsL8eErWXpoaoN5nKeDpEjGgO8vd9QUCnVF0J Kb/Oq2yBpufSIVEbVGK2qdrskUlJe2ma4mXTrn6hSiOm0sz0k5riucLjr1e1OSg7VYJrO11dvrzX vULKx8VwXhm/4EI+/j1BFCdzCdKnw/I+091ITpH+dacespVznTrLtwkD8RC2f30dilt/OlYzlPV/ +Mv12Mg9ZutY1UuwxK5VxRms8F7424utbMp024MV40+KOSIeihN8/axP3/525aVX2cfI0Yv4LseJ m6M2FXH4jF+eYc8+PcaWY98jQNQKz4pl37Fq95Sd85tf2VI4txPLovZNbtKWNi+2a6/6nfXapbcd AEh9k8uApg/0rEzaTaPusDFPjnaAlwB4qviA0Uz2B198+cU2ET3coVURW0Z46Z4idLQcFhcuvuhS a9Gpkz2fX237VYes0ZIVdsHlF3Fsz60Yci92uk+ZD6xaucJG3Xm73fvog7YJsX7VS2/aBx+OxTQi EGOzqoo2UiNmVqNBmcITTmG1dig7P+Zagl0mybmz+Tg7H0SaM9Oi7dpa1QQdk8VqLHqf5Lylllz8 nSVZNInmFfDRpuZOHFIH0D/XCZVZpu1ru4C6VdC19DL4F7ZmjRtao+IG1gATkDCTUSKEKEyLF/KJ 0VyxSUrKdXJ1Ng22kP32zbgd8XjMJi5IGR+/s3NeiNvRo+M2ZWXKTTigoiixxvnqjBokUKFeia++ w9K0UPpG6RnVX4O6cBGok8v2DdvI7mG74d2kHTWa76tQP3ccHrFW2IIG3zZWeE76wKyO6ghocyOK 4/0BgKYFMunJKjUcrp8AXIb6w4DVoAtcmu9Pp61JvhIDUCi8ypsPoOunKmiCWCPylaqrY/4WU7YC Jkq9L2ICcSfoZAZwQxSrbOvGkY8iib5akvTixzuRm8YI3tWjDMJTxgK+tURCObhrjg1oF7Fm0NRE /Z0J6dAeUevSXJk6fj9Dh+gJSlFDALQFkwgFwem1OPl7jsixS/dRXaStRzMsNE7NsyN6q80cIQpZ ++PW8YfyynY+CH7BK7Udd5lwysu3g/zlHbzytOhJ+QU/n3Pw7GnBV+m4xBQic+/ueA683NNP/VM/ B1hPaj8/8xcYMX9ur37yqR1anm8zqzlk9I/X28NP/MPat20LR1RlCxjcPZeusz7YC77DTNwsSRW4 SSoo+lEY2VbyHd4bb7/JVm2oskPY/rbw65l2w/RrrCHb1FpjPKuyLl+53MpWrLJBiNAcw2hj8xK2 olmx3fynv9jQYQF3dvJJp9mHE8bbi5hUHJLIt04rN9uN0PP4mH9YG2z3KgHAuSzxN1+1zk5B9ziN zhSlk0U2BxWXBNg6d+lq97EK/bvrrrGnPvmSBZaodVux2R6540574pmnrFuXLgBF1OYtWMACznd2 ZCW6s9wG9ma40k7Can3goMGOXrVSMGkE5VTHlK6u/MEnLW+3XlYxd4HFv5ltOR3b08kbW9lDT1oS kF975gWYtizkt5TwGqCqLFJDLZA7aHcLbeZILNkB8s8dbMAAcW0uFs9nldVW+jJcrXcSI97GVtKW BSuO6Vq6jsUUOL9Egq/awW2k0B/KBVxR0EETcBsfzAkSHLlz2Eqbh+yNGUlbWxF0Wn14qhgQuv84 DppomLbPF/HhpbeScFtpO2TnqF20D18j5cv3C9aG7Pr34vb1d8FEoIGQzxrO0M4Rm7gwbTeN59w4 zidcwC6fPdpCM0Trq3d56CVvPjTH2jQN2ewVKbvm7ZTNJ61Lh4btuN3gYCFt2cak3TEhbW/NClaz VSPZ40BphZz+0uyU3SJ21u5hQC5sXyxO2g3vJ23JBrNf7QUQw8nGQM8OiNETZiXt6reTcEMcITY4 YqcSpxp1y3p2/QhifvlCiAX6tF23P9xlV45pYhJ45duU3T6B0xwTwTCvrfeg/n7c3wAiAl1oyCYu Qg0BV9uuUcg+Pd/suSlpu/hVmSyFrIS6KYfOtsUh+91wDLyp11ETPUdu1qNFyM7cg91ATATPT03a p4vdFBEAIYA4uCRkh/UM2Y1jU/a7dxJwzAm786ioDW6ftlfgKouZLE7tH0KdELHpTHqjv1K9IGmV hm1Ypwhtlrbd20Xtq6UJG8O+hDjmNe0xqTyjf9SKAOk5a1L0gbQ9OIm2pz3PHhC2eWtT1o92rmLn 1z2fJpjMwnYmddyQBn0GLvbjRdQyfUuT0S8HsA2WLruYLz2++G3SZqwK8R3wtJ3aL2xNi0I2dXna XpiSslWsh6i+/rV6BxO211BCXs8NNsFm6Ibrb7Czz/25PTN/kR2QKrBTNpot5Iy9jZNnWiMGz0EM +k20yCsYOFchJrbGtk5DkrZwLhrNsdPP/DmcU2u7Hg7yVfSEw1L5dhIDaOXs72z9zMVuQh3A0U2c J2tLc1L2zzDnfXUptTuvvNaGjtifdJRY2hqjG7v84svtfLjEFzGK3pftcMduTNjiL6bZRptuOVT+ fuTeIJxv4/PjtgAD7n02q8ICLtAp9Umpe4+edtetd9rV115jL4/9wPYCBE+sDNuKBStt6YJlbhmi O+JnCeA5D53JuGjMDoAbvuoqjLE5ZDVwmSGoGZfBF2hUMDidOpnfpzwDnFaE3d8Ut6AR/0YHgPLR 9tXreMfg3zCdq2hTODoD3+jcfO/jlsAeLr5uPb5wIYAbATKu5sZ7uGvaDXxSIijNYcOHDbO15ett 1aIF1qV1gS1bzab6CsAVrijYsUJYBRYRckpW9/hpAKmmAkYxGERKszFFnreaDlgesnMAi48Bwafo xNcfELH5DI6bxiXshgOi9scD2QkEl1ft1rjEUcF5wnUt4MPzvkNMXYZt2zJlqn4WcVucV9Oxv16R sGuHYciLKHztO0lbzAB6clLaFgNeNx0ahXtJAYCoDYiq2PpgPDwj1MrxnWa+jdyDQXPzIRF7c2ba Rn0St3uPhAOmAL/6J6cPNwnZ/l1D9lcAccWmkAO9l6albMaatAMVlePV6Qm7ZG/tjUUXR/on94va rwaH7dLX6I/FYcCQBb2VCcJpAcFl63L/qX+CakezRxuq5tUQUltoDLrJz/mplKiV2Rl1ZG9UOZvD 1n0ntpM2TNgvno8zKYVt9EmoPQikaeGEXcN24lNJm7CAmtHMQMqNC4IV5klLgsl24fqQHQ+HL70i Q8auHha18/eOMGGanT5Q3LnZNQCl9MDXH5RD20stwkQxMMeqkLReADRvPChqx/WL2MxVKWvWIGJF SAIvTZVUwwQJSG/C7rYSmheuTds/EbXvPzbHmsBFr2M94Ge92AEyBoljkTH5RW0oIDuX/jW0O31l PeOwjLanTGhubBkT0h4dIzaJPicAVIn+VRdM7XVScSwnfh78/OvuO7Of8L5HrP/+B9gLRSl7CWBZ A5qHUKqv4sPkbzVI2RvMTLvtvY9TuicRcVTvDYoCHV/AyqbtwIMOtidGj7HDTj7V3m6cY2PyYjad 2aO8MMfKGSnTqZwxpD2xeZEdd+aZ6PeeyICf2lGNSQch3T3YrXE/9PTuvau9E6my58h/GeJeCvG2 EiD+BG7l0fxKa8Pui8G9+9r08g02XWYlnLbiZEEKJvpat21nd98xyi665FL7Zie+fpYfsxmUKy+K Po4V1DVU/rO5MfumZaFd9JuL0SliLI2ht68nXz/qo1pkUMNoESTSqp0Vn/sbKzj8OAthqxgpKaUz aylfhzAIKJOW03sXi7btaDkc24UCEF/Yf7i0KrjbxFxOQSYxrRzDFhKPwcYvlaZzObDL5OxGIPf0 YA0dObacW98+ve3KSy7AEHagralIWstmhVbSmuO8IloMUciAUlcJVIRAWL/AX6Mo8AmGHVRDzFIm vevfTdjNY+O2EXVI24YhOBVzs/bKjSnr1iIMlxayAR0Q4RqoewX5OKZViKU0me0Dp7zkEEfx3wRL 9uf3E3bb2BRgl2ZA613KxjOAN7OTsgMc0Wq2VxYiDsvpVG+1gb53LJqVvK50O+vbloGIuLduc8pa wTmsYSCNgAMtRoRMIup/+V2EgZ20P7xdbes42KMl5WjRgAmTtJ+fnLJbxiXtn1OVPoBBugd0QzLZ xPZG+oJ0dcpreJdM+XwxlP1PcOqDmv5UVtVPMDnxLLMg/fPtqxB45yIKvwLwDr67ykZ9FLcD4UrZ nGWnAELN4b4OeyRmIx/mEFzSOm8QfYLqCpKgjlRngF3AACh1bA3iYacLbMnYPbpP2B75DKC5C+sI OMsTSLMBdRajzAkq9uKX47b/gwlbQ50Npz7ZqGV7lsL0fJu2Pe+O2VNfSQGUVo+FVno5Rbr9w7gN vLPKjn4i7sT5nekjx3E/4v5qx83+ejDG+oDqQV2j9uLUlJ3yTMKG3xe3MV8n0Eenbbd2YXvgs6Sd /GTSDn4wbl9lJk31m3/V1csB1gW+7Ey679yDPbaP2fhxH9g/X3mJ8/fmWLmzQM+3gR1L7MRjj7c5 szm6+5OPrRmtNZfKbsd2HedoCa8f62P3mCcAAEAASURBVFTa2W5ApNVRQ9KnfYWdn2x/ktRYM3SO +zF4Dzv4cOsFQKigHmzEKQSdJUiyLws0Dz02msMR3nLnEy5El7gOemT426lla/vl0GF25NHH2PRv p9lkOCKx5W3Y8hXBFEROHULpC6R12MIBBxzEtp5X7TOs2letWunCFDcqtmN67WrHIsLv3KOX84MI 4gZ01dSXBmM6OG9PQFVw+MEWQ9cXKSy2nF168kH2llYFXUmMmqOdulp8/TKL7tLNkuxPzunbExu/ uYAk5wJ+t5TV6EILl7bnpGiMogH0SGlH7he4vb0RdpjE5y90x2aFpDvin+sK5O86OrQJCpeiRmhR 0MDO+fmprHC3tCefft7CrGJ3btXQZtHhAscgyPQjDUQNRTn3bRMBlXtHL3Y3pM+tdplQjKCTE16c XQixugersK0YRDF0vi8BHlqBDhw2pIyIargA6Q4DMw/ah1Xl3i1DcCj0CtoBjYnDWprYkaFBJ0B6 8qRca8le7plwaM2RLlYCgqInUAcyMDNFCVQA1C+r5vn0bBkF9W4VsQ5NUm7QrN7MBAKdoj+OuiEX TkWAkiBj/VOa0vepbO5eZVblQFsuVVHMn8El4sjgcBCBZ6zU6rzn2DJEKOqPdS4LjQ0BVUCJS4K8 1V9TOs7MOQFYAGjz4NDK0FvPhiNTW8nOszWcbSPq6+FjmOBILEY0hCneMR2zz10A6zh+3qkO5JQb 86IrZyMYj7z8FJNDyom94hJPBgCbUPeKV43aYs4aNjSsTyFZKE/0wogIWoycswZRmUlq0QaZbeVR ZXzbhiw0WUxdkUaNovxSiPCOr7WbDua0c7xyWerOYVNDjEZ8bir65745dkQvTo5mwr5xbNomLEzZ u3NY8IIrPW/PiM1aDUf6dty+qQFBleKnu60A0A9mmXhUsrBRXFxkSxcvYVvMY85ERE0hzBiJCctt iI7VGBjroIPCQrZj5XIEO1uI7hg1ytpTWc2q4pbbaScbtu8wRAkqhsJqQSRNB9X2GeXVb7c93K+i YjPbd8qdvzagZ5ujuFk+02AqKt1iixI3hBvTThD9yso2un2P4XDEcWm+PLvDLeq3tdsyrS7dutmF 3S5l5qITsIKtjiRw1N7KLVwmmk/fvYNGHTrqRi89L4y2PDllhlWvBuB6D7QwwFNw0FCrfu8Ty+nf y/Ja72fJpYBsnDrBvjLvEDbhd2htSUT6NLtF1PHzuh2oArNlDq4PHWIYExlQ0CKcClL12pu8KiQc nEIGrDSgVVXiuBqzr1ggHqHRDuEQ1p47d7bHRz9lk6fOpHzBBOAak7CO5ux6JREtRKg03glU5efo 0T23GniLEE03oc+dit7uj+9XW5/WHEEGw7oKrisYBZwcDPh9tCiN7idiF7ICqY78l5FRa80CSN/b ZfMoYNJJNmpdBjWJCz+bw5UN7hCyc1+K28vohF46nT29GfDWoQ8NAdQecBSL1rMziMZqhojXvZnZ HMTmJMDwCYP4ro9TiLwc4LE05eiSeUmYdyo2GOgAT34St9Yj2p/UP2wt0GUesYvKEfS2qexuHNJZ 4nTS5q9L2D6lEXRUSiPTEUjrJzvodk2gBGpudK+HQNR3la6X8qKRg3ODgolISCJv1TmqdbsOLhqV L+DEM1y6OF6mBcKEbD3Cj9psUPuQvTyNY8Kah+2pU6L2yWKzO+F6k5iFqU2UX0c47hi60HK6niYG /QujPhGgqo8JwKoZz1I59IdL0+TXg/SSKo+A3JHLRKPO6FzIcdsJZtEb0QMv4fDqgpyErYdm6YDF kT+A7lCLYNIF/3Gk2eB7AOEnYrYTageGj40+gQWcIRE77VmHRKTq085k8SMvtR9GVzuKYKiOMMBm w9m9++57bAT/pTXFFOMTPiv5zRefYYuXa1PzQeuXnrNzzzjbRqAP0569tUvWsgn7PbvrvlEo3ats JPq4N6MJO+aEk9i3uN4uOP8iTqd41Fnq6/BInVRxz6h7rA0LKAK/1xnMXbp24RSK328BfirPFiDz PQUsLs6c2Pw94b7vtazxpWf0zoOw50TlX5cuNUXQFRm6cIKpdeUWHdIP8BxCT+SbszPncxx+ieUO 4GzDFk0sxKThxBGOwg9hshIuYPscRt3xr6ZZGJOY+JLvLGdEB05xpgdG6RUhONsclPBzFlocblGi tEAiTOeha0KPOqbA0M31tnrlBuvIgtBydowsYJ9x55LOdjki8UuvvslWsa+JSZIimsHvxFLd1zjX 3TPdS52DH//FqQUDkwvPRGWApOyhz5N20dCIHbdrnuUCSvd9lLAvlkIPwTX8ROffPohbl6ZmN6Af FJCuhyu4+DUM5hEtoyCeBo3EPweB3MNcIPKm7d15KbvzZ3l21dAUYqphJiNxnPMO4QxkmnPf0TmI XymU42kb0sXsgeNybMSDMXscmqTPOmeg2KCQXfNGwmbDqWhgqiwBVQIRlqxIbwV5XYe+S4suUvhL Z7UTYKDDIx76FNGva569eDq7dRjwqytTbpHnW0xT1OZbVB3J/xCn/pPdn7aMA4dLJeXS3nmMo2A6 oGaolzy4vBzKQwuwKi4uWZxU2l4D0H7BIsIFe0cdZzgS0L8aM6NFqCYkEakRPmUx6N1ZEcqYa7tg 7iT7y14tw3YjbbNgPQtbvL9kn6h1bh6xo3qG7a3ZCdtQiRk+6Rcgegv45PJy9RyGG0/a2zPIF/3o l7/R2X2Y86P7V/1KrVGoOJplMjX0IW155XBAbF9UVIv5sBO62KvfTMBxpu3pk/Js8aaULUX90YlJ bOJCsz6t+Fb1z3Js3MIUVgMs0lDW+esyRPykWhf1ta6GA3SdjgQjmnpJv7y8jM3ti91m8Aq4vMsu /S32dxfaqtUb7URMXMav2mg33vJ3e+DRhzmzqxhuaYNt3LTeuqSiNoKZdDxfOMvp38/OASRvv+tu Tk752N5+6x04vKi7XvybSzgF5B27+pqrXB6xqhgboXdzYFpL3o+/ywYq38HqAtWPSdWn5+P4tOrr uK5Z3EgAjNK5VvGSDjPYm72/mAp9y+nPdOaU9vdy0GpO756AYpklqONIq+YWWzzJkvGY5XbvxsnW HJC6FHMYVhAq3xvnwLHghMMt9gmHNkz6whlSGwsaXo8XtF3A0ehefV1mFdVw5h9xEnWfLp2tYXEh J10vsCYNC9mPfaq9/MrLcPYsOvEvACmVUANSKZjdNT5pT3yZhoNwibmOf9P4hD38RciZx8ThDI4f zR5v7O/08m8fMLBmp7D1AxzK0/bZEkYbUZW2B82FzPhHjk6gH6Qj0/OmIb5JpFL80eQ1dj6mToi3 khJOfyphq+FeKlkz+cVzCdurhINS4V42w+XINlH8zNg5CTvwgTScAYeywoGO+Vqrhik3MKtYtb3k NQ4A+DplrTm+bQEc4TesIMrdOzGFropDYREL17IAdywcxhxEStExZnLC3pkTsQqsBO4/CtEbroOu aStQ2B/xaAx9FLtpYJ6nLBcnqLrR0A7qyD18zx/ff1w8h8TbioDagDIIgKYCst6Jk36bBaDZcNDK eQHi6BuzAiCduChtZz+TtHP3Cew1J1Cf8wE11xCagXASU89+PmbSuw3rwsIV5b72zZi9PJP+Q9Ar mSSuHm7Wqw26UDjcG8dqsYR81oTstRmOt3F95APm37nQIFC6DAB7azZSCZOvVpl/weJJGC5vU3XS Xp/JyS6AmpzK/sV3STvzadp0cI4d3CNtH89Lwr1Lb5u29+ZylmgPABnQe4aV3lvHcRQbcbSIM6CD JJZAR3z/pwA6/vWNQZfRj/hTcxhCASu0WtXRZvJxH35oYz8Yy/ljd9mxnDX3OadyXHjBhbZk4Ty7 CgNkw1ZtMKu3aSfSJtkjjL0bfSA3Ajyjf5uMuNaIs+2uY6W0cdMW6PIOcwcbtmvfljPEDrdb+PB2 p06dOCqn3A792SHBZ/HGTbCTTz3RzjjzdOzUpJSodXVBqPbN9u9+arztpbq9NNdv5hilkXyZ/qNp tHY+g59dI2jKAkhRA+pOHUq8R+CP+p/uFXTwoKtqaMMhOT8JOuzDRu8Y6dzB4p9NtjhG3ExROK0M kyaR3KCi9waroTyjYlC+rd562pb32tkmc4htSUlH696Vo5XWrrYo+i+dI/fPV19TZAdS4r7E0kmw FYAmpeyTc+9FmacyyN1l7AIQhH8SYQMXgILupa/S0f/mTG64QmMAFpmgAfGO/iC7IB+SI2wmH0eX /LOdctySAr2t9eM9D8EAEV16I5ftDyUECjBI6Qdhbj0sFwNhFmQAxkEdQ3YtNot3YnwcpC2aatNT qWspq71TTvU5Heelw1yvuOIKQF5c3bada1Ne5yE+qsfEnRgrjpsegxiaRG8p0VbcaYQwrJs5WjSB SfRV/6nMZKG60FtJCS5UhtQCuEiJqzE1kWK7+nCyBJNM2KktXFCATWKz+kUCwNNUK47Z6U+pjoMw mdJq9EyA+urhmCsxQY24P85EGXCo0uv73qFslJtWnWXTKUD3da83ss+UBYKMBYIS6Spzn6CAVajW 5K/RBCm1Qbj9sW6//faDS3UEIcvTUXWrCpGT+NerV087+aSTXKPJr0uXTvZY67Z293132tvjx1s+ G/ibUwhgj/gpNtinLLdbW74BepydceqZnLnWxB0TNGzYUM7ZO9Tee/99bNFigN5hiLrX2Ftvvm2b OLanoCCf45NmYkg9C06yrAYAPdj4ziAavs/5OAoXdPCgo39fvOz32Wlk++ve01JvGDoQ0ijdTF2E RgcAwhxvHzRxABPSEQoEImnEV4mr/HMB5Kuems6YvCgzFzHf4jNm85vBI7Ms1nCuC6qzBgRxVVx1 I3wcyEjRzDMgUtKuDVxfA453ettmzZ5rhx60Hx0XWM30SNf+riPpj5x2LKucSkrpBWQEe4eJRDuL fr0XYCrvAPzwCCIpEW4VQGG5J0XHWTow09vgffCOB+XDOxdHdCldFxY/7oPM5O9eZcrJEgf1p6jK R8AdOHmIpkwexHekZAZ/QCthSda1oW5EKk5pPf4FnzXYyMonnfrGD7GLnCtuI0hR9e4SVljdKCqR lNcPcTobT9+4lX5ZTuV1dVxPZOdP+lVulAeqBnH8ru3YDx/El+5MPz0LuEQTbetAQiFUJ5m6z5Tf lSVDd6VbPdIDdURUlUMpiboKpJRMrq4NBLD+rcLE3KKK/NLOrOjXe0ad7u6b5Sm74OUY3F+QrtQF Cq+4rn+KSjKTLWUA6oJ0P31iK5gBOBdDY0VF4j3LCRkXUKlx5hDYe//Eaw0H6OMPGbK3jRs31jWO zhDTYkVdl8J/2rSp9uFHH9nceXPcoYZNOBq/e/edbeSIA1lxbJuJgtzO3mHZ/0mnpllPDasi5CIK p7T65gYUAMoR9ppRGhTq2wRUmQYBYdVg1AD3ulFMuaAya5/kFYR3jZkJR2xeEMqlo2oMKlP+ftuN ax4aJKhohSYUFR+EDmIo1vZcQCcK5opNfBeYlevxU0gFnZ06nXoWztGfudez2k8d2ufrOqp8lb3P z4X3ZeCqZ5cc9wqqyFs4vSc2r2Uqs/nem6zz2Sc7Y+5YvNJeffk1ztpbB1d/lF1w4QUcef7MFrF3 PPzP1oAAT+NA4+q/ywW7Z7CEQ2UiAFbp6vbN/7wSOw6wLllCZ/3TQogayzk/0DSycDpVpHefvu7n PLb6o5k54HRyOT4rcLDD7KrwYKE8yILZRlyN2PqiTDDy0DjWHwEhzt3zV0/iKTx41FayKls/ARvz l4CF+yAv/PVc4y9wU1D8a9FHUd2jW35UWsF/hcyEd7c1f4IqIRAu4HbcHX80m5GY4/QCWh1/4ojW a8VhJnd1GcQPSqYAAXhxo+xxgsIgPDfuTjoRJeHALwikYM4hCbk4qiM0VfYZp0dPadPC9t97sDVl gjrqqKNt/IQP7Yknn7T5HJzqQrv0fELOa8ef/6EaUJv9t4Gf1BzqPWVVaX6qOJ7UH/9Du1Rdrjtr ESQzwKBeR6hv4dxg3cLnex4AGSpBw7fWBfceLIJ32SEyYWsutXFdqMxjBr4ydezjBy8DMjP3ZBzk lYkofdkWjrhZ5XKhMkFdC3LvU98iWuYhOy//PoxOVDUnIdWDtgMrQSIdQn1C2jkH4jxEEHelHdGz oB3BmPgslPAvCK2pIXir9Hyaeuc5WAK6oKLVh5Hoy1ICOwZi9uXkb2zpnLl2yMEHYcPYlQ/oDHPf zniG029cVMdZZxJxPjv+7KiBH14DbiKm57kx46Pp8X+JE0vmSPU0b2L1d/KXfNAcEIxJ8AcI/Lu6 6OnL6P39VQy+VLcdIvlWAFKs5146p2Kx/7xpyQBdysDWu+boL3JBh3UwQPNZeZNs1xYF7DrE40aE bQS3qSN78gi3CT0li48mfWgC9lGf0dQhhcnW6A4Wau9FylhYdDsEGjGwm5KfYE96GumwpNhHL2s5 7BDJQ49STnxMNq2C9ysADOlToihwxZHFsc0Lyq6nABlDjiPmmbTknN4pA5Q62r6sqsLmsmzpRHi0 xMpThxDkYHQtvjCPY/V10m0Y+44yTi3ewHmIjTl9pgHmMLlsuq/CHOi7VRugQV+Vk+KZ+BG+s0H9 hDElEDfdsBHfSOFdkpVSx6FvAdRqKRTI5RVWkJ9nTbEZjFA2ndDz2OOPwgEey66QfhxH3p5vW5Tw RbEvCC+w3eF21MBPrQH1OTl/DZ7+U/8GgB1Qp4NOYFiCwS0v3c2a+q3tt/c+zrq+SroKBp8AINiP yCOBMpjpOCh/H0irsspnRZiHQwoa2rD8BjYjGbc5rIa2xK8Nhq4dAaaVANlS5LWTWClNwTYvxpL8 mniZLWT721GtG9hyNlSXV6TsiHChNQUMegHGaZaqPsYwGPMgWw09vQHJ9oBO5Ky0zWcJf/2baXud z1m+n6hm0GMfFi6yERwtVQhQRFEuRgGk1egmluSyRawL6S3E1hH9JIdU2bPEGR3bADhCI1vh1mHH uI5lqCSrpWmANgBAienSh3IFiAJLenG6AJN2agB0sRjf2ZCJS7ti1jKiVsBe4YaNmliLZtgTUo/N mjRl//KlHLnVyMoXz+NzAPdbz9672cnHHmEJdK1FGPHe/fdb2Z9aZfnsbSouKMIQvYEVY4idzwku snEcMWyYtW3TynTorMsbA201qp98II/Piq6wlZjJDGzZzDa8/YZN4ZsOmzAyf+bppzgGfwPfbNnL jjnmWCstLalXx0shd7gdNfDDakCg4bBPf/Twn+80VgR++tBWVBKQyM6H08oFaKoBq/XY/bniEFCB /apVULSaErtHtzWHOy0oicspYe/ssfmNrRVcz/vVZbYRMOoWZvMzXF8TuKwP+T5FIbskzuIElzZw WeNDVXYtx2A1YPP6ud2K7bOFnCaNNf7hkSJMa/g6FfFiGH99C2jqIM75gGUPaG0Lsxg9NmEVC9gF wAb3JWyRmoKiv5KtXsM5BqoHdmH5aGM3s/DSgvzXAkyrYf/y2UjRhG08X7M3Kx8Q3ggNn3JoaTkm QGGJ/qxOrUOZoU1OOq5JHxNKMBFoZ4l2s+jq6gTTDu141L30fflwa6oZAaGMm8Vtxsi7gtNvNvH9 keIGhaYPBE2bO8sG7rabdezaxdqz62PKjKm2z5p9rFWzRta2tKsdfMA+dtfol0i7iHRkAI1JDECe QoSPJdfa+Ikf2/4cCtG8eRN3XFcC+qKRYKFK+cu1aNeefboz+fjNfBvJvuuCvEL7+NPPMTmodKvy C7E9PPnkE/jg93FBhB1/d9TA/9EaCMugnMPU3UAuR2dUBcfEQyBeUSke/PxAD3YbKDyDHbEMPAD2 0F8hFQ7IL7KLGzV31utvAnTVDOO+7GDoAKfWmAAfpDiCCpHu8lSRlTK238Fe8FLAp0fXHPtVr2J7 ZUalbcCW6HAWRBoBIr05jCCfZfHFSp/4iziNpR2cUW8ALXogXM/6iH34QsJmcSjgN6GELQe8OoSx 48LEhC/CAkKsKsPhxTnYgCMDOWwBC/Mm3K/Bgh0TCo4nsKkA6zR+QBtAkeuAq4p03GIQZZSAKCt6 vzXPn6QsYHTY5/7AZVIXeXBjOj4rF4CGQcUwFK0cIKgthQLRNCuzn3J8V0gcLcz34IF7WAKAfOfd sW5FeNHipTZk+P4YLnOcF+JwVSWfj+RYr0q4PV1jAPqSxUv4Uts4t/Ku7Xk6UVtfdxMXKLE5WFVP WZduO1uHti1tOl9yGzp8mO2790DoobHgqD/j86IzZ86u6fLZYoG+1Tt//nz3LYaaADtudtTAf2kN MIyxseFXwUCVDSDQ5sBGgyJ7YLh75wcqMOjd1iXYRxguBlbIDmQ3yHGcPzcxFbP34TSaACg90AG2 5lqOLdATsXIbyP7T4xKFlos4+xCnm1wdZ1dJnzwbwemPf/2kzPI4d+5EDg4QHT0k3gJEq2IJi8Fd zWY7UD757B6LWFWDmIWXh+yt12I2ns90VgBmcxG1pXvc3XKsmKX4BtBWBgIWwIluBAg5FMSSbGtq VsH3itnGJNwqQqE4ARm8HFFXHF8hO+grnf2TuF4ARSIwNOh7xhKHA6d64ZmCB4BD+aUbpCadwafC C0DZiaFlDXHSSepWABiBU1swd44tXbbcfRS89659rUXTxjZt+hRbyGGpq+EQwzkFdtRhB3M0FMAN sFVDTwU7OuIYmFfxNTidyDF/4XxA7EvKgEEpx47JvixJuEQ1bDEThV8gaVfS2drwFbmJE8bxbd69 bMTwYeAftgpMIF6loTK5yS0onPsE5MKFC90nKCsq2OcN+Krt9ZnFaew/1i/G5z83beJYGJw+xRhn 4tTqpj6+rWd9S/a/bbUzUz07Lv9lNRBNsbjguBwGkwaCBqwG/racU/DzUoaMIJ91Ksq3AXkNrBP6 vc9SlbYKbqoPO0K6wOXoVI6pcH2zEC/PThfaYM7mC+P3YKjSRkcr7dgOBfpkhl0zZ4P1gvs6mJNL KqFnbwClCFpWsXKyFBb1WzjFdQDMOZxoHGe53TZGbQmHMb5C2qWEXch1BYDUA66qOyJ4V7iwJYBO EwauTNbL4GpXcK7gTpxVFoVrnAdv2hrWlbNnoA/uSYUl/SYcobVwgz4SE6y8avEkQbrapiNgAZN1 QpFbWOHOLUyIOxRAaPuWwEn1CeQ5gAlhJJ4A9MPQEgPII5job+KToV9hnjJ8+BBr1ryN9d+1l730 zvt85/ZbO/jA/WzRgsXWh88E7D1wso2dNA1dYK47bVvifz6HTYQjSSlu7Wu+kdK+XVt21JRy8CkL IwJp8qlgz3HDRkVMOzJPYCLhGDCB9Zeff2q7A4IFRQ05Oedd6HSldrS7dqcMuurA1JYcTCvA08e+ l7IlrxffMJk7dx5hkRYwWl8MF6oPV/fv3999e1bV15gv/CmOPm6+fPlyvmk7zNl9+u+/KswOt6MG /tNqwHGAIkrDllEr9OPBPcmnxrnN1AxCjQK3+okodVBhI/tFQVPLhdsam6i05QzA3dBXDYLTEQfw alzcg9nFLEj05ePdFeR2SWqTjeZE5ROaF7B1ptrumrmJdzl2Agp/TuKxEQzcpoiQG9lgP5fl3mnR uC0EUE4MFfBRJk7m5SSQAkTae9JsFEXEXA98f0M+Ms7eBXG7HRxfLuWIVCUBuaith0OVHnATq7s9 oW0Viyvl6Dm7QdencH/zAHuBgU4S2YRidEMF+j9AWtwcKx1AiM6DE8Dhh7/AMZGMuY8wucJpuxvp J9gALlE0BaBqAkmhFFW6Asc4cWPab6T6A0g///wz/LQ6u9SG77+fteBbIV9P/pIv13H4J/q5GNzc yJH7uTPS1sJpVVYl2I8a40w2cZJMPnBcZXw64K2337FlcJP6DKlWoaXPEECvWLEu4PAoo9B9l767 W2nnzvYBH/juvUsPO/OMk60xR3zJefBzD+4P2seiImvXrh2AxsEM1In2hPfs2YNfTw6zbeXqoEeP Hu7D1/oGb9u27fh6V6X7AHfXrl05GajQla3GjrQ28R13O2rgP6oGIsccc8x1+qq9QE8cgwaEG9iO zAAI5ac7jd8Uf4rZxfFrFjqOCjWwCZyZPB3dViMG9kB0drsigk5iNfTpZIXty/NpOUVWBJdWDhj8 KbbRPgE8urOaOm7tZpvCRyf257ONxxYUm05O2hvepjG/1YiYX7HYsQTgmwhIHQ/49QXMprNq2wEu 6j1A5mV2jvQg/TmAz2JASQsf/TmKvycgsICFjdaIyjoxYz6IsBzurLhV2HZRGhxlBB9q7eAA74uV 2Uy4R7J2J480wBRlxcZgAUjAEYi0AYipDgSyAjStADseUfXiQFJVFojJ4hZVV4HJjEJJnEZHCCda yGqxMivD1GiXnn0AihwrKS21Vcv4XOfMeXynpMD69N6Zz45utM7dulv52uU2deYiuEg0lABcVCAn QIajI2ur4Mh87afu3r0rJjJwioisWg+JU09VmOM0KMJGiEmCP9YS4BKN48Z+aN279bBOnUvwD95x E7Q71zxo1D7tgoICdz5jcXGxA7//1955ANZVXOt6qVnVkqtsy03uNu427gXbFNMxmGoIvV1IAklI hbyQnlxIcu9NAwKk0BIwvbriBja44F4lWe62ipskS7LKed+/trZ0JAyPlnvfy/PYOmefvWdPXfPP WmvWrBFnp78jOL3o3LmzteW8kk5woKks7qgsvVjU0SHWOkNaonDXrl1dT9kKT+JBUF4Kap3/ztBQ x39Ork3qxU/m6bpairI+b32D8vvYbJRWk3zrKxfEr/95wotPEid88URxT3QvjB9+R8eJvg6ff9Zv tYRaVe0a3b6fLY84HJIGABhdnroODDLRgggP+ajlbxju2u9LbImOL87+zDm2+1ip7cnCw5ncz0Lc +zvmLO/DFd3YLM0uRp8lW7gdANKPqw/bhtpKVmQxP0Ghf4hBPAJOYzrmMmVwVhPwItMGzu84ALOI 1c8CgGsNQDcaN/vTEZ1z2AwYn4iXDqr/K7acZcOBynvcCoAwE9H1ktTmlo0KDGchrLzWWCdGZRFm JcUA5A72KI9tl2BJGBuuhFPrTT2OkM8fj5cBzAFwpSeysEK9C0qlEQ2INuTg1DQ+MXgzqFUEagAh ddEfjeNUL3AM3lFzSTTWXkYBaKBSSEpBNIULrkZHmgr33B9uTL3ZqWMHW4FIu3tvgU2YMMGK8OEn Dzt9e2Xb+nVrbT+ThfpaLokk2GohRoeTC9wOHznk3KlEYZnjVFG/FkwGhQWFvmiShglNCHTi3uQh ZhH7uDt16oxZTWMuUHUUyOlbB6hnZ2dbjx7dHdjk8iwJ28KsLPYWA3TiEvW+RFxxiy1atHDwlDgu AM3IyMDcJwQ/SiD6JITtqGu1jULTe9G/PQIfHxW36fth/OBb6Wti12fj4RI8b/gM09edIP9goEWg kdrCjfhrPGIxyYF7ND3XZMJXXb3EOHDtuSiBQPur38pX1fQrjxPUWTf1TlAyfTcNGtwE0DRCeupu JVafnr8b1iwsB8/r0wyeBeVsKK+nwKOgrKqDv+BZhR+quf4Fpf/w86AUYeyP+o5+j2tXq0Xf+6j3 PuK+N6L6kjQov1JSDcVwSEJr9EfTifXQWAzu87sujqwzgjEZ9K/USR8OnkGgQ2KsudcFHaw1HW5u KsD2DhzfUjuOiBljp8clW5/aBIyYj9vDNeVuA/hd4kgcFeczr7rC/gwostOXhYk424lSXTzXCMSk C5PS7RBxTgc4W9ER1QzoeXFVbsy8Hc5M5xDf0CzF8hBnOUHR2gKmf4BrK6UsbeHmViAWFlOhqYBn hAPOW2FLtwXHon1r2E/BQTgHERlxhWat0vF7xq6LXHSKarh2DO7njh9j1VjOJsmEvzRA9CiipppW cVwPqGd1IRwgalR5ExbhaJFGor5HEwZSFjW0HBrUALpKSNAXw8bxRN6LEBdVqXNzm7fgMSZyAeLl LjdOHti/j739zmp7a+4iO2P8qbZxw0YbNGiAXTh1su18/Dkrp66pnHuSQPqxiKXaqhg4l4Xjfv99 B6BRrCqnwlGrTO07tEZvt4PMY9HphUAUsbFjx/og0el70eFEAyH6+ee9PlH6uhe2a5h+9L3od6Kv FVfvRccN34/+1mCpzV9steXFeNSZpmnqQ6Eck6/CwkLr0qVLk2cBHRzf8KxVbZ9nMYktLHnknfhx xI0ZQVYJ6njRijeovvxaH0FO/lv3uRAl6Xfg3AEVCSvyNYdK7eji9ZZ+xhCLl2/IujoRjRCkIWsE lSRwgBo8CdKDlplglaiDVV1mfh1m5rlqEm4AOh/2StPj6KX6yEHifHoZuX9s6ftWvikH1QoLZ3qB 8nklxOLqvfB1Lrycfl8JUGLRu5oIWmzWPtOSBvbhWnl9tiDrk1qsKeI7ZlmsjtEl7+WbCuzRNzZ5 +3p/kLRbb3i/gCcsvqIR82JrM4FgUS86G8HYTU+F6YkuTkhk6ogInIp+awD3pwHuTGhhFexgeDhy 1Mrp/N4MwFEsdmTVxNnTgNI78F4j+f3VhFRE3uAAmifgdF7hDA58J+LbDP0a3IkKPgHu5kLE3gM0 zkV0bQrFAH+MUzBsD51VTEPtpAwPJgKQKL1ycWncjTLMB0znHS+3MegT9/KuQHIQol9v8s1m0aWY wrZB9JXDyAJqJs5zN0B0fms8snAa3E64TnxAwmWyglzFiipNoZ0S4naaw10WHcXhHOUL20FtEw7Q 8Fu6QD2XfqsGcT4gLhZISEN7pNXJ0pE6gIoTgArkSki/ZReYqCMqIY79+/fatpw8a5/Z2g7hF3AC xslLln1gi99ZbKefNgHv2uVWVFhsw0eOtkmA4WsMFIGvnExKXym+U4VVutJBLlmyxDpw7ogGcsB9 RuDeunI0aK6oEBG4rcfXW2PGjHWQ1HV0kG6xkDyjB0z0c7WB6p3JGcaqr44w0CqxxOa2bZU+Rtjc 0wKJ7klU1rcCryKuH2bBJqNR+0a3tUfko+k91VGONJSXOEyFME747TebflSWMoj/AyPVYxbfa6rl bN9jhzllTxysxHS1pxZ8Nm7E0w4FFHe7Z89eytzMdu3aaektMy27tBhwame1CXjeLisCAFUXTW51 o58v1U14EICP7nOtvmecKGqc4mgAE8fNp+g9wduht1bYgd+/ZBlTBvs70XVReSpY1U9OivZEXpc2 7REjyUM/STN8z8sVEHDwgE8vZh2YeiZhfMoTQKvfbfxBugLBg39+ygoffYS3U4kL3QMgom1dC6AF JSRX9xls2xRY654CNgq8UWYtp19unZ98WFxF8OCzfFKm41tyMX07iqd1STVsaigosWcWbHNsVnuo ZAI5OYetBpf6ZR20HQdT0Ldj3yzvNdRJ4Kcyyp1YW84jagSA4SAXkTuY00jTAaEvNUu3hXB9r9dg qkKn9gFWR7KJrAXbyR6uLrF1cINnY/JyI+BXQ4uLw3sE8FsKYEHutkdmEwI/wghE1SvTWrBwccym 4F1aZwrEsqiRC5e3nhVO9jXYspoKuyspxbpQiHmklYm4uxuxejYLLW3RH6ZQ2W0sOGh72Dm4w0/F 7KUL5VoNIPXAT04sYLacMkHifqB0Z1aFj3AiHNYv6A3jbROc4VbEcVnjsWRhqSjOxLCVs5IqglE7 hG3hhW7yoWda6Ah8sqGfc393Qbfr7FkO3vDFiFoIIAYVgTb4NaP+NUwCEfwoantbFW2yYuVKu+nG ay1nW671P6W/dc7KtPV5e2wJR3ROHj8E8ZZtceglzzrrDFuxbisiKLuMKV8l3CCWLCx+4B2aBZNY uAmZwixcuMQuufgid+Ev8VuA0at3N7jJbf5uBostQQhAX/UIB4/u5+Xl4/rsWnSL5Q504Qp33Uve JjIJuuZLV9t3vvMtu/fe79vcOXOtE0D3d852XrBggf32t79nlXin6yTHjx9vP/jBfQBxD2+vpUvf cxdrWrjJzs72VeOCggIbPHiQm9dom6AAU2J4cXGxL74IRN98800bMGCAl7VNm9ZuZqP7MslROro+ UajZtxL0gcjTe1gVDmdXrSuznl3bOcdXVsbEzES6gclFHLNAsE2btv4tm0/9VdYUWOcOIyx+7xK8 dWdYXKa4v7DN6IgYFuUw0n/wD/M5f+WwpTZPYocOUgAmWd+4fbItWJpre/cftfu+doat3bjfHntm md1100TrzTERCkcXr7W08YMsTrraJkFHmK5Ys8cy26RYi/Rk27H7sLUg/UQ4BR1Bm4o6Ihm1Tf7u ImvbRkdI6GwNzLiOYZJEGSPovROwmW3GnybtquNYD3BdVlZtaanNOB2QRTXosV/39uwyagQDXhIf /6SH7EI1sW3N6mTx6H1rUa3EMZlWYy8a35yDwbDwwPDXqlDfxLeCvrCCiADc0lNX792PcQX0jm47 lvJ+3hCHn1BNLGFQndOgF00qQeDoBY7AnTpoO05YBZJxOLSNswl99toLq7pRXyRDmCkBv7A4hbZs cInPTSn3NSBqSLAdVb8huYV1Y+X0kdpSywE0ZIc3KiHJJtQk+Ha2h2rxGs39G+JT2bkh9+7Y2DHl PQO4CXxwDmybWFWtkPzP9SmYUJyHqctquLgzqxMwimb/K5xEKfq9N9nmJq7mTYDzUg4EupBtZJtw xZvN830MulVAlWz9xmIKIru9jRWVNpQtac3w+tiPsuZoMQPnipmAdyGNVADgJGBEfUpGnCXD2O1H /G0PS9yWxYinEX8lOtMS/OlQFwiZ+CI6MEE39fGxIOiThPP4SkLv4ccPTq+GMsZCPdJNRGgbzZRu J8iVbAG1sKLFDHXOmtUfWPGhaW7oHEc7nznlNNuy/e82a+4c69+vpx0vxV0ybZ4J4Z07Zaw98coC 64D36EpMaryvyE//quCOYuC683fssDnz5tp55wTHFMhhKlGsd59u7ofuFPw7pqfL6w43RQakHR20 eJKXu91Kjpaw/S7dJxiVtxy7PrlFE/eqhaAH/v1BGzxosJWx53jfvgPUPcZ+B/A9+qdH4Vq0Qo6P H2jhhZkvuFH1s88+A3fagVXjPOcO16xe6w4ZiuEWFd7HODwTTuxN/EMqaMVZYT0HWSlfAVSXLl1t 9erVft2hQ3t79dXXPc6yZe/ZN795j183+qB/j6+faXHQcG3RVqtZNxNuahoHdGVbAfaWLZg4pTNd t269g73aQws84oI7d+5oBQcKsMvcb5HBUy2x+ziShjqhLRejqK94H7WfOLs4lMc79x22pa/tsLHD s21An3bWplW6zV6w2XLyi+x7d50BgB2yvz233K68cJgDYBWHdRxbk2sdf3BNo2KHP2RY37JFsq1Y u9vac2SCXMcVc8RCc86ZqYb+D3B2dsuWqT6Qt+RuQ5xLtYH9O1j+zmJ85wF20NixsiporprFNsCS wV58qIxtmSm2bmOZJQJ6CcTJ7tzqhACocoi29Cl8SWiXCViPsioO9Mq49DwrfuI5S+zW1WoAwgQm rIp1iKKiLdFJV5z3Ygp16O/P00rSxn0xQZyn6DkMzqioJ3wix8QNZmNKv922ZldbPIQLV8AHnMe+ sqaz9etwEI/iSZZf2NwXPFUuBSQqdar6NmAgxU9OS2huF7GrYwWg8zv0d+pkrT52AIz6MeiXYDo9 B32fjIS/k9jct7aVwmJuhitb1IyFDji2bZx0sg0wk9mG5PchGDhfhH4qF4C4gLN3u6IMK4NwDkLc r8dUWhvyXwpXNJYZ59aubBtjP3AsALYXbioXgHmaGbsj3B9JcSh7JSvRcTYI5wKtST8dTuhduL/J 6BLjUFbOomxpcGIVVH5YeoKVc/ZrMQXhzGgrpswLMJupYoaMYZAI8JKYSQ6j/wuNnZt2mBN6gIz1 oCERUFvjFAKRkQOg4CmrmRHFHcYB7gruzEADh/9uLuP2gIjklOUI4tjcOfPg2s63/PwdLICcZq/O WmAbc9jt8fZi+9KVF9hB9FMHmHVHI7bOXbwM/4s7nENKA4y0EOKOE6hTpYygIdZ1azfg/j7dJk06 zQ+q0iyvxYqu2R1t8ZJ3bczY0daKRZLoEBCQsTWvs/3bHbe5XvKdJUvZN3yUQcaBU5deYtvhDtes WeOcncTRe793HxxGM18MkanMU08944NRCx/XXX+NbVi/0RYuWIzN42p78omn7Fvf/iZtIocOzWzE yBEONm3btfVFlO3b890wXOXU/sxly5axqtzLxVQBZ2ZmW54XUZ9kON0S53bT05ujIx3oIBlysv5N xdzPYgUnNSVlWNL4b8CNI4gt+oVVFu0E8BIQkdAPc+xAS2wXBw0eiPMIdt2wMLcRp7xt2mQ60Meh cskCaJtBG85uaxiLBjRe6LtwHKahu7vva2fbWws22bLb/2q3XD3Gpp8XiLTqmxT2cCuuwCaNawGb QsmSNX6/+fCe9t7qnfbU88uta5dWdttVY2hT9pYTL40jYoeckmUdMtPhjBPsIACmya8zh90fZ8LW HC4uKDamm+ueNVmkc2hGKoyG5rYaJnyJrVKJ6HcFO4ni2aIkfkTpSyQXhxi0GxH4H9KC3nSQ1ye0 fnxTnh0pKGbvfoUdW406hjY7vhHbUCb5CGMvBiYmgnVIDHHL31ttEeLFMinX8FxSkALZWQ22ohJX aw4eZuLgmwmzWlwlZlkRGJ4Y6qlmFuD6Qh/liw/VHhpEGjhhoFL+i/gCNJng7j2YBtDBkSKdJrJz TNhVVsGxvUdT2OWG+AtzJA4w6EF0hGFaUt6n0lB3prSyzjTsM1WllgfiVrP7IEJH9INwh7PYMD9S YStxHtASwJMpTAkdy7nMNg+x9VAmq7ZJcfa33GO2CS7PFxjIrg8NIW5yM+9NBvx6IwIeROxlvcNm c3ZIKxpuHfFbsEhyz+Rkq+XcgFrOKqhG7C6BXX+Z83yPAZTpcHxFfJcDcue3Tbc2xRj68s56GrkN bSzvL7kA5maIuSdA2hzwa4EuYB8mgzCAmNhgg8fKci6zYtBkagYZGGN3iPmLo1TdzBC2i75FFNFB P4PFD3EBalTmJrH8EgeorwBBcQSSHtRpegeKFUclExkNCJVpxcrldvHF09z0ZcCA/jZ+1FDbun2X vbd8pV0+/QKTdx7pvQoPl9llF51pv/jtkwATi020X7JAkH863lFgjGRMvrX2HhyVVmZ798Y8hkFR ViYD5bY2oH8vW7x4iU2ZfJo7WAjrFHKCGXia+fGPf4Qer9jOPecCDrMqsu5tM+3Xv36AUwGfwXvM ++jDMHuh/LuwYdSkKVFR9T3uf5yZcepQu//+H2DruMIBVyvWObm5ntVVV11FWcocNNWm+tOg1feu XbscqAV4Q4YM8rNhxo/HjyHecsSVKQ/p7g4fPuJgJZ2j8h88eDDtH7RvMGjJShMbqpvk0+5jJMk5 GVg4+X5LB5CHDx0I17ofnWgmpkDdERvJnz5RUB0kRgpAO3fu5LpAqRfUeU4D9LN0YA3wp7eCoAUp CsKEH6Tld6mXYnsB+FJfheO3dMl6S+7X1Spp8+/e/rSNG5Ftb8zd6KqTr9822cXW1+dtoh0QV+nv li1SbGsuJwVSt749MVTnqLYUxmUJIrikjcF9O9ikcb2sTUupOVQGz9lz5YMAIAAuKkV9gXTbf+sN 6ff4p8biW2WFsoPYAFzylEmWMqi/FfzHf1mXP/0KUGputQKvwoO2565vWDrWC63vvt3PCK+FkSl+ 7Bk78syz9SkpVYXq/QVw5tuCc2+OllnSII6DZTvo8W2YgeEspIwJM45+jm/fziJHS63ZKb0sfvSw 4OUTfHq/gFs1MD+9Mossg11i2+DyBH5eT9pL36VwhGf232kvf9Db66aaqarwVkGH9WVL1f2pIioW LG691uJO6QOEmF1/91dtSut21q3kuL1YdtBmHyuxTnhLuQvTl/2ASSvO4lvFvt82/Y7bzReNtVkJ XWwTRE6JHMGnn3uu/ftXv2qrjh60dpzZNwg+6QjLD/F06hy2x1VC3HuxZ9txpMzuPDfB2rbHnfbK MqtCD3Wga5a9TyGyzp5q44YOsSpmj+2lRy0TvVhGUYV1wmTlOIi+C1DsyQEyMXB281F8d+nSzQ4h gvTlWTWGz4UQdiL9rtlAdoiHASs1nJTgAiItUlQg/obEwMUJQ8gJikgEOHrfFyEQT3StNDUoFYL7 zH5cC5QktgS7SoLZUC6+JDIXYvKyZt1G19tpAWLq1DOtPdvjDh0ustdnL8BEprPr5I5DbEOHj6Ud eiB6HqLd2IpHmuVwfuUOvORJOyhf6f4WLVoMqHIKEQVIwcu2bASzsjpZn55d4MwWuB7NC1r/oYER BIGaB25J1PYFHspKRRxsWsPlqZ7iclVv1UP1FJjlbMuxV15+lb9XMAaXnrSm3hzmjTfeZKvdfE9D uj6Z1uj5YbzVSG8o4J01azb6xH94ugJDcaBadJG5jQyss7I6uJmNuEW9L1BUcGBRIeoGfxx6qxjA T781mOO4Hj9hkh/10LNXb9Lo5uCnN7z81EeLHzr+USqLZKQLgV/QW0pY9VffeiZ67f8YBCk6ECqe iVCcX8AQ8D59V/r+ZmsxYYDlbi/G/OmQFR08xuRw3N5dkQ/IyflGrPXqkWmZrdOse5c2lpGexO82 NmEkB1yx+yoTr0Xt+RN32LlDS0sGKBVUV/1vCHVlb7hxgiuVTXDXEJdiezLhokc8Ho0SsrNZgU22 OLwZ7f3O9233zXfavm9/3yJgQ9m8d23XbXdYZX4+z+6zktfeoP2CMinVoEhM1l06uW4wvmtni4MD l+OQeETm+E4d2RXGKYpw+zFtW8NVMr4YqzUlZeBI0AtNC6401SUquY7q3HO4uW0vbEG/aizyDM5T ddIKsI6BXbKtk0t9YT1FM/FJpHAJK1xnpWVg3lJpi8pL7ZlpF1on9DBPP/qo3XHLrXb/S6/awcmj DVti67d6g90z5UzbAWFlbcixowP6Ws+ixba7sMDuf/eI6RCq0yZOtJbodPZymNIPv/ltW/vuYusw cIBd13OA7VuyyNqPGG3b01taee56m9i9py3Elu3rdOKYnjl2eCYrpdePtk3LFln/66+yLdoJsQn9 AuXsOm6MZbViBe+dd2zQhMnWAz3V8sULAcMj1qZrD4sdd6odmPeGzbjjdisvPmjdf/9frD5jQkNF JfSVsDq0AjCshmPkUoyCpSASVAFgge9D3WzazA2/QwBsuEN0WjoEPjV6oFLQPYkeAhKuxRUAFPrT AoY4jURARh1XwfW8+fM5s/cW28YsOHbsSBs5fJDt2DfX5qPPO2vyONcxaf/tltxdduVl0zGO/rUd LD6CSI1tJLrDNAzS4zl+UEEKb5HEdkRq7RS5dPolDkzJqUlWwnkrvXGSUIb4ou1qWpxQ2QMOMHhf aajsCsE5IA11lK5PnNitt93C4fFvwOWtZHElGSBKsZ7de8B5vmf7UHzfduu/ORBLVJZIfP7553l6 et63bz/7wx8egttLg+s+6pzWSERi7TbRBLBlyxZ3HvHAAw8iniXY17/+NTfxUQINZfXkon5TB3+u 9g+4lppDOVa9bRYK+8FwHM9ZTHPE2ZQ2Ful+hsXkzbWE4bdY1cYXrXrXUkue+ku/rtoxnxXGzhxX 2tKaDbmegb3XKubfb4kTv2XxbfqRX5DvR32qfNFBixT7i0ps2ap8gG27e0xKxm98zfb9VgNHnzZ+ gHPvmph7dWtjp8PBpdJP6j9qa4P7dQQrMQdjj3olO6MSxMGRB0Ks+AsHyiomfi2SyFD+AKuiRRyr mkEa0senkVcJmw20E6lFhgAdekNU1UScyqEnmje1kJiSEk8eAivKryog1QgcgtqIFiQmK2tBOlSr McQEXc1ClaSBGPSJNbWVmACwI6sUtdeufVYL9xaLdYZ6RmkF1AX0MMlk3HAZ52Qx2ZCexobE5kjP rsE7SDsx1CWCjh8kU2HCl7luHKRrDx6KhnW4U7xN6r7LFm3uiEpLnj5VcunIY2xIjwMc4ZlkB46k wPRQGT3kK34QiwpLWXHVau5h52TQk6FvmTTxNBvcs7ftgT3diz3aHTffbK2p1JFuS6zvTTfY4Uf/ Yh2+easNPjXLnn6rp91x97121Yxu1hGinXHVlegEKiGcyax8VlrP0mo7477vs0hRyUpZM0u57ho7 +PZ8m4CSN2H8BPsmytTerfdYwVsHLC9+prU8tb91OW8CzkGLcFhQaQOHj7CUbsWW0qePcwIH22XZ iKuuQPfXzArbtLLIb35niWkpduT0CXbNwN6cdM8KMrqv6kunsSULs53Z861rbKLlsVCyBT2lZjf1 isSJVMTfMkCSqhPUKgr+I7is+wxAghgQkWZncVrRBC8CEUemoPtEAXhwZkrn0p+INhwCA7cbW4Ho ywKPXFj5Qglx1675wHLz98D5pfngv+TiC+09RIHtuwrsb089a1++7TrO9t1hO7fnWLtRo+yqaefa 7/4yE9VUPKJRUr09IiwZbSxRHCU4ALuaxYbm6F3PPfdsypJoGS3Qz8AJDhoynFIGIOcFpr4BuGjg MSikowG8Ssux30SdoLjSI0lPVoHTVy1C/OjHP7TLLr2C1Vp0FXDa3//Bvfbww3+yl5ksxdWpDdsj xjzw4C9s/Phxnr7Ar3XrVhzWXsCxq9K7HbMZM670+OKoxbFK96cVbZnSiMsT4H5UCPtEbR/2nGY1 Lf7Ulh+26t3LNMWj6MKIe9SX7djz1zBhJFtNwXq2SiJKr/4r4k6xVeXMQZRD/ExB/zf6y1Yx6x6r 7TgKs4vXrObobqte+3eLn/LDjyqG31f7uc4qKtYtM0bZhi17bfrNj1PAiF176Qjrh/ha/NArltij A5xPOzYRxLLA1d9en48UABd35QVDHKi0HXL1hl3QA7pldj9pgq5k5bYElVT79s3tWAniOpN3Gffk ULdfr0x7Z/l269a1FZxsoi1djv0e4JbKbiPp/lIAnnARTt0jwCgqLGPfeJINH9zRTumVRck1eQjk VNxgItE9/YvQDxGM6GsZV7Fw5V3/9hfArpQngmPoXS9B7xCOdFfcD6QI3Y7VyjDfogl9xyKR6L5C 8B1MYLFtBf6KQY5pstFQ4DO48F+NP/SMNGlDrWBoTL61trud1ncfR7NiylSc6iZIk0/ZY7PWdfYV 4jh2mCk50YxC/E7MS/6B375kgEv2aTCcFoMbpn3ocGp797D8bVutW78+lvb+cis9UGjV2Z1szey5 NvPVv9j3bn/NXnl/k63YhcKZQHsjajDrbd1i+3DZ1HfqVDvKyt/wnQUW6XXISl950Q7B/R1F3Fn2 wK+s7ZQpmLrMtKFtT7PC3863koETLG30SEuCoziEePPuntX2ATqySWPGWZtOnSxv61bLRxF/PgMp snmb7czNtWxEIgQ9S0Q/UQR7nsFJdBvhfrJ25FllPmIV5i/NmNF0bOcWAPAQbLUIVQSbhiidhCK2 8BizzUe3sqrm8fWOQjDA/TLqQ3rA8LnMTAQmIh3iMyjlW5AeYmEHDy8oexNxzCqCrHIRtsze4+D5 m6+fYTt37WarWm8bjefmvF1vwVUtQx93lmV3yAQQktwLzFlnnWFv0b7b9mKWxMytmV22lFqEkdhW C3hp94mAbAGicDuAaMSIU+EkicPgkL5SJjUKzjFRr3AxTPe0wCDg0qpy69a4N8Nc5Pzzz2d7HDZV DIRhw4f51reZzz/L6vJGB3otSPzpTw/ZFVdcxkLDWtLIsDPPPMMBLcxn4sTxbnen3SniDKXblMmL CHcyekm1r8osUVSnp0nk1fMwhIAX/g6/g/tqe7V2AOJBy/OL27WYY0Uqj3Ih7gmxHRui4yv/jGmG uI0Eq2SFOL5VF0TTSpT80DL0UrN/NWc2v2txWXCQOfOt2fCbLSajc5hlk++IjTu1m81+6lY44XY8 C+hg/Kge9trfbrNteaycpqeys6etu4rbhf6v+YRBcEE6D8fsl9+7wFau3eXUMvCUDtzBlo2JeVA/ rgH2CzNeAAAdzklEQVQiAaNW+mvRu0vPnAyoleOwVwsaEptLAcFOHTJsyvg+1q410gALI+kT+zjd SScpbk/piN5Ee6IDHYG7jcOFmwOeXbJkKK8JUe1XV3oAMvjFDdRdJW/Ms2Nvv2sx+NLccfktFgeN eEzSpeNESE5LtUgZ4m6FiAGY8gxFW5BW2CvKJTrU58TNhuvwnfpbzrkEYKpnKrEWM6WzFaBLHq6i LBv2pHCqXYIN7Fhk2/Zn2Pu5rdnkIKZF/RLUS8yHJJR4MN1d1R+FCGuYyScxQ3Zg1vzZXx+zNfnb 7cF777NxrAC1/+qdiASltvOl1y19ck8b2hl9xeIVVp7W2taswt6KUIlomcXKVxb6lxIWLNqi5c9k wB0o3GfZyPs1X7nL5j/2sJ2Nbm8bA/UgBbjnciwFmeQ3F7J8rs7t39eat8xg/y77WVmFnHbmVGsF gORsybHuo4dbvx49becfH7dmE8faBso+CbBmX4TFD+jDyG1ue2S+UFRgSWPHWBWiffyBw5ayeo1V IY6uhkPTBBXHjCRbKWiMT+wDKwPOLQQDr8wn/AgHpQavBrL0ZbqnawFlACzMT+hL3bU96VaxUl7F CrlEikr2TWt2Xb78PTjnK/DmvBcxtbtNxhj6xddmY79Ybs+98LJ94ys3Y8ulTq6xbfkH7LoZ0+07 P/sjM3umSwrHAPFadr8kwxWKsy1n1kdLB+1E7IUXXmJ1s7V169YtEFnqyhrqK8M6hFXW7ymnTwl/ +re4vmuumdHo3qhRI01/0eG88841/TUNah85U1A455xzmj52MIy+mZ2dHf3Tr5VG07I2RNLgEoEH ISYRu712Qy22VU+r3T7fyhf93GK6jLPYziMs5ugejJoP+CJJhEW/qjVPi4m1aonNi39u8a17M2tV IgbPsIRTplnV6qcBxHWW8FEACAi0apliY0b08MyDcgblkJ5Of2GoQX+uOjQfHZj66H4SJirjRnYP olBHVUM16dAuI7h3gs9wIR91GSF4IY2dDaANf5hOZYbmTnreNCj1GOveUS/rWn/QqPLmfj0EUU4l p0kjItFWHB8TVFVuPlr8hjeDlte7iss/ibBMIkqnWtIS3GuEXRy1SEBK/7MEido1rBvEMgmHQSqG rpgIqT3FgWosq8jVtahlmBzyDjN5g/3l9E9WG4GwR/LXtejbihXzmBf/8ffIjTNmWCfY0lNhYQsR ofI7YBC6e6/1gTv5Sf/htmXfbuvSozs7LRjQ8butAjOL3yzcZMeSMEUYOBB/duswUzhs3VFWX5qB G3aUkIcOl9r3U9tbNbqpY4eKbS899m47Vo2Z2Zuxsjg3b7v96quZNnwzALkh1daWH7FKzBx0uvwc 8s8vLsDTyV6b3LU7s1a5rS8qtCGZ7Wxai0wr3rzFjnPaWTniwPnVeEtGZH+4ZYJ16tnTilhlmkpH DenWhTQqrBAASQIUNVF91Y7aBhZxpDuQPktg0Tqtme3DJkuAVX9SW9CXYTt/4m+Bn0RPzSzBIgH7 leGI5WlaxtJxMlmA40iGu01LxXyI2besotSqZULAhPCVu+6x8SPxEdgWN/pQ9j33fMveXrbW0/re d75rHTLkFj/NjyOdccWl9suf/9zWbNmFTV4v272vmM5Ow0CWfCSuSgUgURi2vAa946BB/ezWW2/h /XSvawh+J6pcMBAgVVETIfyt6/CerqNDMOiD+B91PzrOJ7lWOtHxotNteh10GZ/892I7kDBMxRGz G0lKsxiMmRVimFydO2Gi13sxTNy+XxvQY9ayCJxhLJNlhElTE5jrRJEeIqhRXNTzVE70UVcKT7QO kMV11L8E3VGOarbAxbfAUNeBgniUNWhX4vq7QdqqQl0XUAa1bTDAuevXuuecTx2oOAD4k+AjfDeM 3/BNTKUX/CdyGILMycXLUZUH0DF22AtHBHHPcF0qq771rqeh3xpP3KxLzy/5kNGy7sezbzyWHU9S A33mQF6SbOI55iEWCUG5VrJwWYb5msolFUOEQnmdnVPknpePPOEM3ZRPvz0Q18tK/JcAwD/ceJP1 xqffKsSzVcdKYY+r7XQ27t+AHVV+pAr7uXgO+2EDf1f0g4h5f8B/H5ZuJBVwTkqzNWLSJEBUas+9 rFj+KCbd9/IWJevAoVibU43+CI6tJWYHcwDHn36luZ2P+LbjP2NscTKcH3Z7hSxd56Dze67sqOYc S8ZcpgcAcgyO5iiVOpd9x+2wbcpixpyPuDIt0swGVCXamtRae4DN6qdCrKmIFXexEf84osEWzF/K AICOpL0yrtK+XXmY5XCInKCOEfgJtAqOVOhO3Z+efrog4g0HqgBQYKqg63AFNRaxS6KHZjKtSEq8 y4BjBabsOFxsNSA1jG1vv/nlL+wg5idDhw2yRfPn2vd+8oAVcwD92NET7f5777btuZzDXHYE84dq G4Te5jv/62d+eHYMZkpJtH9zFOCJDOxqALAc/a1WNdXtUjifPuU0u/ZLXwKE1Xcnw8kWONkC8e0Y Hkmg6GuVB20nwKehO5VdHZezhWU9YhrYYhsQ0+Iz8V93FE/Oe0EVDw3gp/WjwcxyLeAeVwMwX49h pQWPLhvg/srZnbGCmXUXA7AHA2/ewSM2dQLbU9pFLOeXOFVgqbq6iq1urCLJ7dPzgF8CgHKQmbK9 jHSYiWWmksJCRWsUmFUAYQ67P8BVS+Pe4YRymwl7nshOksMA9XCgs5oy7AYgCmWbxQpQCUV9L/aY laDEjQ46NrKsXMD3+YLAT0Hf0Ur7UFeo1dQYfCDG474rjgkgFgW3AEn6Lillj1Ne6WfWfbDKVq3d yPYenLbm5Fk/RMY+LBDNX7aSvb6LWNQ4i10rGDazYv/esnk2ZGB/O2vSSHvoydesGaJB84wqHC+k I/pL1EAMBgC14qedGTLFeGvWHPfnN3LkqHrOwgse9RHWJeAewhkz/BbnAJiGP+vfU/3Dm9HXihBM DppgGnOPYZvVJ9LoeTihBOkGcRXzxPmHaQTl8zyZnKWgD4LKFuYfxgkmBudrxDE4S1CXT9S1c1m0 pRZW9DSoZUN56jKonwAbFdBfaHjL48IRBoxIwK3wq77lgnLzGSYfNqnnHOakOoVpBhHDT3Finr+i +rsNE3PQnnqg+gftUp+8Z6hf+lNqQfqBDo+4/jNsNx7XlbguC3+sfOv7N3id+9zj2nV0dff09mcJ YVph3s6BOnfNHREFfe1xIM5aGjhYmlGLqJQAAGPwRCHmnbnzIj/9xc9xYCIYYzGBiNl0dgUlr+Sd JKSIgwBRJrs2cnSwBoOWLNy+Kcw4hUzTAalKCiKzmizS4VwjbPSCDtCxmCpSIgU7RFr9uiAKFnHo 0FG2H8Fda8Fabq4YqbafNILN/DrPg2dwdBJNaxDnMkgjnnLB1/g7GeCb7KzyKE8ynFUs77aj7Inc Y2sx7hnUMCxO8beHMhyhwUiqPsixgFh6teMXFurSD4Ek7DDlKwLRQArs5uAEqRvN5hyjiiCgap/V 0VrLPop/2vmgLVn79hUgwbGThV0K7TJbYUaD/R/mSklsK0TlygryTiQ3zCQQryVyex1JV2XQ/ZAw RMkp7Mns2Kmzt/GH69wwYAKqV4y6CkVFDuvm+UTd//Dlh98N4lAiKhz2c8PgVHy1RPT3h1M90R2V RYtbalsloToHQWkpfLZ0g3fFFmgAheUK7jb+DNL3ctRl7e3+ofYLyxWUSMWSmC1R1m0qScDbl6w0 eKPbJjrtD+etO4qv9HStfMK667dCmPeJ7je9F7zR+DN4P5B4gidhWfWrcQqUhX/BvcZPGqd54l9K V2oaSVP1wBqdiSrqfaK+UVAeQZ2D8oV11TPFCcvQEE/xY1hdwhBeCsK6wHvSkPhg5VaYjRY4BRgh joadG2TDigpxw2e6VnphmuF9xdVBQbLLcZJi8PoqHRH1LTld1nEeuOertXWJ6AtMCx/5txYylEuw 4E58GkVgGVa37lWPK6EvLIdTiDegP/IPJzZPTykGbzYMouCe19mpsOG9D13xqhNFXar8qouiNMPr 4FZDPNJ3qhUHGRhpK4aeuxgNIehN6RbDd0LdlN6TmN3Q6ZTSgV4EqHLro64+pKf3Q85Uj6KDnoXp BOVpqEv07/A6+t1Pex3m9Unea6hzUI+PeieIF7TzZyljmE+Y/qdJI3xX74TXSufj0lC88Hl4Hf39 UeWIjhO+H8YNn4W/v8hviktoKHPTtE/0/LOUR+8EQQxD41w+aXphvPC7cSoNv2Di6nNruHvy6mQL nGyBky3w/0EL1DNF/104qHyi8wqxXtyVsyz/w43etHxNixNd9qbP/lV+h3UMv/8Z9fpnpv3PKO/H pfnPrMuJ0j7RvY8r3//Esy+qjF9UOh/VBg6AyiRkpXWy1w4MYLVpXfs65TgyD2PmMMhPm/ZuNg3b t2/Hur+xl+GmcfRb+YR5+e+6SC52NmF36x597NeatbiMx23RJw1lHMIeHXJycu2ll16y1157zXcf RJdPddIRj9EhuuzR96OvtYvh2WefxWXTq/6+djisXLnC2+2JJ55gn+4S122o3HIwoCBXT8pPfTFv 3jyTb76//e1J96+nZxs3brTnnnvOxdf169fbzJnPu0gsB55vvvkW73HYE44T5s6di1MELYIEYR9b 3l599TV766233P9eeP9E3+p7mR6FdQy/o+Pq3GB5UP68IUxbtDRr1qyPFMvDfLZt20abNNBheD/6 Oycnxz3WRN/7NNfyQvPUU0+5EfaneS+si96Rj0KdsSN1hfrpqaeeYcdLhbdr6O5L9LBgwQKPo3ek kli+fLnTxLp16xqNo+i0wwW28J5oRfn9TwXRmeoWHcJ+CssY/ezTXqv95OhX2wE1plasWPGpkpBq z9/HzvajQtz9hOjCiiDnzZ2PMj3eHn3scbfc37Fzl29KVwfksvtCTiS1Q0A7A3bu3FGf9u5du9nP us29Esu7h/ZySimvIIIQsNJn3sHaQqU42tCuTfA6TGfr1m1up1aEzZ+IQgNNZ0vsIl3tDFB+2qK1 gl0qOoNCbpT++PuH2Nge7GmVSyl5+FVeKofek5PNYxwyvnYNzifZFvbd793rnn91PoaCVvnWAqLx rM727NnDy6y8VVeBn7ZtffDBB56mwEQ7E5SutmkJTAUYqoP0cAqaMB579HH3i7c9bztxd9Iend3T 8Msvv8J5u6vZ77oZjydD7G0OKPrJT35q119/nf3xjw9xDOUy9uf2tJtuusX36T6FBxYdLpSFU4Al S94h/gIrZTvi66+9buvWb6AsrQDL+faXvzxh1113rb326hv27rvv4kD1LC+LPuQvrwQD9r59+/oW KYGuzhsRYApwdbaH6qnJSye8LVy40NtMu0HkNUXb31S/EBjz8/O9TeSEIFhwYYGK9tJ9tYEmSC28 CLBlc1hYWMT9WAeDRLYAKo/a2gj3C7xvH330Merwtu8YURryyiyXV2vWrKYcbb3flZ72Ec+ePduf q09XcYaK+kj0oYGiPlf7qa8CTy6Jrj/V2carVn3gO0+2MaEL5LULRsAhulMdtUVR6Tz55NOep55r O9natetII87fWQP9yCmD2k90qjYT/ck5g44OzcnJdZp8jDEzf74Orq9wn4Vbtmz1tBcuXMSE9gTG 5Ff75KWxMGbMGO8nKfufffY5ynMQYFxo2dnd3D1Y4P0maK/i4iKnEdGtXIqpvirDww8/4rQoZxEC Vo0B0Wg4pnVP2w7F0AgwN2NDK9A6jpmU7ETVrwUFhZ6maFftI+sEjT0dFyDaUVwBs9pEeSpvPZfj illvzbbu3bq7tYHaU3VXHdSP6iflp/4MnVaIzgT2rfD8IgcY8nakA7g2bdrs+9M1oYs2tUvo5Zdf deZLTjQ03kUrMqYX3QuHDrBAqOt1a9dTj32YlaX77iXhinYizZ//NmPjr5yweLaXX/UOyxEOEHeI GjaWbsrNUDzgp8GuSugMWFVEg1XxWrdu4YXVRna5b9rKtrdR7E9VZVQ57eNcS4HUYKrEgAGn+CAT YIgrkt86xdPg0cDRATrvvPOOA4KA6Mwzz/SN9qNHjyavljZ9+qX205/8jP3JxTZu3Dj33VbATo8j OEl4+cVXbR/OLeWG/ZFHHvY0tCVLHXnvvd/3jrr99tt9MG4EMIaPONU33YtwBUAKykMOONW56iyV TeXSIFADi+AEFOqkykodCF7qjd+hQxZp5dOg7HAhvkJPDLE1UHXcZXZXPB7T8TLW3rFjFwD2rhPb TTfd6FvFDgMEmwAJEe7KlasYoC3tGdwHHeZEuPj4eC+PbPh0BGeHjh3slqE3WRHgImcKLdjud/a5 UwHXXXbhhRcC9jlO1M/jgLSlPMlA9GFHa3BpUtP2N7mSWrlypQ9WHXCkQTh8+HDqvZkBcgxj6UEO 7nPmzHVXWjk5eQyGiMfR7Ks20l5d9bXqrKMxxRGqD5988iloJ9OB+owzTrc5c+bg2Waqe3O+eNo0 mwV4DRs2zJbD8Y6ibwW81157jYOHzhSWY1JxzNpKp34QUAo8X3rpZe8D5as4DzzwAHubz3UaUZ9w qBcg8DD7k7P8WE45UTV7zu7Gi5HCozj02Lo1x04/fTID6hWnu/HQ0atMInKDJXvMrtld7Gtfu9sH 9emnT3GuXBKBwEQTkNr4oT8+bOeed64Dp7xHawVbNPwl7CpFtwL8yy67FOP1b9iDD/7auXB5srni ikt9LF1wwQXu6EGgLY49OzvbaU3toHDZZZfZHXd82a6++mqXRgQwGrga6JpANd40FgX2AmNN9AJ3 TSZqe4GMJn2NhWnTLvIxMHjwIB+rcoG2Z4/Od+5vS7ju2DHLt9YJKAWKAnX1YT4TkOp7ww3Xkc8G JtOlno/AU3TTo0cP69YNh6+M+1mz5jg9yPnFs/94zvr060PfrrC05qneTz//+S9I53p75ZVXnR7l Iq0rXl/+9KdHnf4OFR92TjkR34XToI9HHnnEQVj755uTxo9+9EPGXR701ttB9bTTJtnePfucYbjl lpvxGPR3aDACXpzunoeO0j5Xs1NpNrQrOl6xYqXTk7BL9CwPQ1deeZnXU+2tegvP2EbaWO7UgNFs uPz9lRDNFG8UsboaVOIKNLMJpORvTmAXcHBFTjwiyD44LBC3psGitDSYRSh6pncEEAIUcQpTJk+2 l1540ffDrnh/uZ0z9WycZz7pooC8jYgbEphUkb8cfKpz8+E4v/3tb3maavTRY0Y78QmwbrzxRh84 GpQClosuusgH9/vLl3MIeeBuXSA1kN0r0UH1a8aemSPsYxR3K8LXTBSUP849mOisDZVfTkHVPhI3 xeFqcKiRVV8F7XEtJv8YuJ64hHgnXs3YIiKlp0E96605tnDBIs7r2Gwt01vYm6+/gZPS1jby1FPZ 9VKBZ98BcHpwKpSpS6cupJ3k3IT66syzzqSOB2mLYk9P+YnD2rp1K4M51TmYF198sb566mi1v7gz nYeRChcsDkYz/ZVXXumTlABUM6aAcujQoe6iXpzjKbhEE/CIqxRRqY4amPPmve2r1Uo37Ge5rJeI LmBQ311++RX2D4gU4yR77tnn7TqAYi5OKWqwzdRz9YMmKg28Xr16OjctWpG4L4D9yle+7Jymyqm+ VVxtsevbt58PzAsuuJC6NPdZXnaNKofEpMWLF3tdBdB79ux20Lnzztu93YfiUk0c29q16+xsaG0i XosuvOgCOLt27oS1HU44Bcbi+tUWU6ee5ROL6pyIW/ecnFxv6xkzrvJJ86KLLnROVOAiGhB3NG/O PLYmxgNeU5kcDnm+Um5rQlL/KW0Bierz+uuv1/eTHEcMHNgfsG/HpNzapkyZ4sAqDlwcnIK4H01+ AVdX6m0mILyIOqxYsdxpQExHSYnGZbAVTj4hNebUNvLQPXnSJJ+YdwOmixcu9h1J2YCxuDnVQxyh RMdBgKfAVu0gSefiiy92mhHdFRcf8muBZS/2rUtE1f0j4EEFNq3nn3ue9e3dx1U9GueiLTFUAlr9 3X333UhIFQ62Kq8mYB3WJSC8/PJLHQjXrAk4zjGM7779+joHOGr0CMB3gPexmJM2bXTw1zbrAS2d AijnQzeiVzEZGsMa/2p3qZku5qiIcAtmCH5qUxeBdREd1AAq6OnM5Pn52+mMSV5IzWhqcOmZxAar w8RFqJE0EJWZuJJu3bq7vqZHj+4+SJW2QEMstcRYcR3y8qtBJQ7u0kunY5BcbldcebmtBmBuvfUW BzIRpAZDZrv2rsMSuPbu3ZNZ/XG4iaE+EKT3ufrqGT6o5Uopn1lMQCnRRdybCLozILKK/cpyy1RS UurPhwwZrGJ5EIGLsDQXaOCIWxVBp6WlOkecl5fraYmIVG7VUXVXXBGzCFKgq7bRnxo4L2+7A6SA W+BfgN+/CRMmmljyvtSjH3uexb6fc945tnGTPIGkeHuHs2+vPr1dnNt3YL+DszgqDR4Bhrg1cc0a iCqjnA9oUlqF+LebQT8dF1gqh4IIRWAjEXjp0qWehvpCe3vVj+L4NakJpMUJS6RW+40ZM8rBXnWb zEQl/ZhAVESvftA74iLFMUs0FEir7a+99kuex8033+Sz8O233+Yzue47lwSBy7WX6jFnzmzn3ORX MBRJBUrqt2eeedqPCBXXp7jyFD1z5nMOSKr3k08+6TR1FZ6HZs6c6fUdPHggXOkpTnOaJMSZabIT vUyZMhmwnE/fmE08bQLbBgXezRxs5B1Z3I5UB+p7cVviPF555RXaN9iyqPIpfdFvp04dqUOF56l+ E3Dv2rXbJ8M///lxnMXu8TILEKXfVH+0ROQT8Io7Xrz4HZ/ExDEK7BQ05jTWxFVLelqzZjUT1BU+ 7tT2EyaMp99xIMpkIDpfuXKFc7xiJt57b6ldcsklTEo1TocTJ07wOKJV9Y04VjmmkBRw/oXnuRci SUqZmW3cI7YmINGyuCylLw5TXOIetsP27NWDSXGIc2jDhg3368cee9wnHIH82rWr2bU0zDkyAfyw YYPhYF91gLvhxuu9zwVUffv2gd7mOEA99NAj1Gesn4kjulF5JV2JFkXPkpo2MSaGDz8VjBjo0kSr VrgzjsXFV1qKc7KiawVN4itXrnSx+jwkA7Xd2rVrkPAGQ0PPePtecsnF9vjjj3kdhTmNmD4Gqwc6 ILyUXWAEgPPf4TeEHgHo/BmDPQL3x4l3NREGZQQOyuPrt+LpG+SPAHh4xq7w50pM96P/dA+RwNPU t4LSUtBvXdMwkRdeeDFy4403R1588SV/prRVRuWlP10rH5UpzFPvVeE9IEwXnWN9GSFMTyf8UB2j yxX+Dt+F8DwdfSuvwsJC/63n+q1yNk2T2dTjKQ+lrfIpINpxHZRL7yqozPpTPAXFVRlUH9VVaStv wMjj6RkchMcN664flZXH6aPgvj/kQ3H1p6Byhv2l9wB0r4faKuxbJgjyPOjxlZ/KoKBrlUPv6U/v qJwqt4Luhe0V5hf+BvA8jvJnZw/xqj1u2K6Kr3RUdvRSXl7lp1BSUuJ9rDi61p+C6q8yKIgGdK32 UzxdK+2wT8K6KZ7yUVnRa3kZ8K7i7bJo0ULeOeZpqHyzZs2J3Hbbv0Uee+zPHk9piJ6UtuoVfuta f3B7/m7QT+rjoA/DeoRtpvIyeVCPUl02CmofBZWR80n8WumE5ddzznX2+uqe6ltefoy8g/5S24le dF/lCPtB32H/6FvPg7+A7nUviCN6qfF2A9AjN998ayQvL8/LoXqE6aifjh0L6Fnl0/vqD7W34ohm 1NYKKof6TG2ka6I6fekd1VPtqGvVTe/qT+3P4kV9veAqvT3VZ0F8jadK8jzq+f7mN/8Zuf76GyNI Mp5PODY01tTWCmov5dc0uB0gNxujomNr+CFDlcZicvjk835/fL4NqdMJcBrHXJ8oMfL/5vBJ6xTW 4dPGD9/7uO8vOs3Pl57oR0E0dCITdX/43/wRTdPR1ypG8FtcPmDiIpc4vC8qfL62bFqKpmVv+vyT /D5xGoAV9T/oKpywTT5Jal9MnOgyRV+HqTfcY1KCy8S7Nosk0jGeODTE1/PoPsBBA1pUQiO2UDdO hpMtcLIFTrbAv3gLsLvtn8Pd/Yu328nqnWyBky3wL9AC8VL4aqU1GghPYuK/QM+erMLJFjjZAvUt oMUv4Zq+FSQGa8ElfsOGTfa73/3WV/gCEBRHWBfLo578ONkCJ1vgZAv8v90CIQAGtdDhXsexEBhg /xsQtqzoBXQh8wAAAABJRU5ErkJggg== --_004_7DA761D0F7E34438AB58F989B430E321viktoriase_-- From nobody Tue Apr 26 06:04:32 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE5512D1AC for ; Tue, 26 Apr 2016 06:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwAbimT1RPv3 for ; Tue, 26 Apr 2016 06:04:27 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F48712D1E9 for ; Tue, 26 Apr 2016 06:04:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3QD4PAu008909 for ; Tue, 26 Apr 2016 15:04:25 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A6E7A20504F for ; Tue, 26 Apr 2016 15:06:02 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9D79E20504B for ; Tue, 26 Apr 2016 15:06:02 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3QD4OFD013896 for ; Tue, 26 Apr 2016 15:04:25 +0200 To: its@ietf.org References: <571E06FF.9060404@gmail.com> From: Alexandre Petrescu Message-ID: <571F6758.4050402@gmail.com> Date: Tue, 26 Apr 2016 15:04:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <571E06FF.9060404@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 13:04:31 -0000 ITSers, This is the latest charter text. The list of work items is updated (2 instead of 5), a generic paragraph removed, added DTN and ICN as non focus, and added a perspective of rechartering conditioned by accomplishment. Yours, Alex ------------------------------------------------------------------------ Intelligent Transportation Systems (its) Chairs: Russ Housley Carlos Pignataro Assigned Area Director: Suresh Krishnan Mailing list Address: its@ietf.org 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 Primer" covering - What is ITS? - Explain V2V, V2I, V2-X - Why is IPv6 needed? - Explain why some traffic will not use IPv6 - Explain why other traffic will use IPv6 - Problem statement - Use-cases - Security considerations - Privacy considerations 2. Standards Track RFC "IPv6 over DSRC" Goals and milestones Oct 2016 - submit "ITS Primer" to WG Dec 2016 - submit "IPv6 over DSRC" to WG Jun 2017 - submit "ITS Primer" to IESG Jun 2017 - submit "IPv6 over DSRC" to IESG Sep 2017 - re-charter From nobody Tue Apr 26 13:05:52 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7964512D56C for ; Tue, 26 Apr 2016 13:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_kBcHBqwmdj for ; Tue, 26 Apr 2016 13:05:42 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F3312D58B for ; Tue, 26 Apr 2016 13:05:39 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id y84so28461245lfc.0 for ; Tue, 26 Apr 2016 13:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ERBzJIYhL27Mu0IajncsjQMvvnK1JvzLet+f3mYTja4=; b=ruvW/qJd6y3b/eFY9FP8rs+C2G0qriwCjcSzZEiRSZ6cGFea0n5mcHVjYg0+4Rrv8k v4XRt91zrOJ4+JqXytWBsm6dGGFITNOSGeewZSRiRxK8whIvRPU2GiLy6YJ9DS6IUT8c 9QTiO47xK4yKMD7pQzCQIzCWof7IIX9z6cVUCqJUb+elPaUJ30+ad0R9gG9JM38gJj3i 7bJOw6ybt6koT55jDAduPIyuGXlK20kjnjRFxpOMrKjt+CC8ntZpw+j+T5lfnJinvU8k Ky6lpEpJs5tdPklB3w9yUO4v2zx22D03Upo5CEtV98wZWfDYKrzB90j2A4P7Pt+aptcH hldw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ERBzJIYhL27Mu0IajncsjQMvvnK1JvzLet+f3mYTja4=; b=LFRoSNwInIOJ4/cKnfJ5QaI01LwnuaUzpQb6yxGu2qqI3OV0HmWINegxUyhBf2+GtW fAktxIo93AXz94wniEl7g7s9CziLsMYEFwMx8REkvc/7EuCQwinBts5SY0VI5KmKRTYL OQqCelHk4oOUbUXun8lCejWMFQVPO32yyGLnBPASZl4Ui9GtkAx9gJYXpC1O9k9tBWmN 3vktxLFGNunkfW5gI0TWKhmJSdxiBgDRFO7vLAfuDGvuXPm4ao4E5rsXCFTPKlDW+zkh d2d30b+KOiIZ2knf9pRSqN+zUH5ahNliAburLpGRbJjwSAidn25cUB6wvqQ2Z5QQy1fn bTzg== X-Gm-Message-State: AOPr4FU1YMeunqrJIcqhuDdG1P4O7+gzzhxFSCqRrS9MxAmqgq36ClSJUjHEy52yL6CtWOk4kbQogLnuJrnuVg== X-Received: by 10.25.85.138 with SMTP id j132mr1733172lfb.123.1461701137248; Tue, 26 Apr 2016 13:05:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.146.17 with HTTP; Tue, 26 Apr 2016 13:05:17 -0700 (PDT) In-Reply-To: <7DA761D0-F7E3-4438-AB58-F989B430E321@viktoria.se> References: <544A6D4F.3060401@gmail.com> <544E5FE4.4000503@gmail.com> <571F346F.6060500@gmail.com> <7DA761D0-F7E3-4438-AB58-F989B430E321@viktoria.se> From: Alex Voronov Date: Tue, 26 Apr 2016 22:05:17 +0200 Message-ID: To: "its@ietf.org" Content-Type: multipart/related; boundary=001a114122f00ddd3e053168d111 Archived-At: Cc: Albin Severinson , Alex Voronov , Alexandru Petrescu , Lei Chen , "Jan \(J.F.C.M.\) de Jongh" Subject: Re: [its] 802.11p and gcdc 2016 (was: long ago) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 20:05:50 -0000 --001a114122f00ddd3e053168d111 Content-Type: multipart/alternative; boundary=001a114122f00ddd38053168d110 --001a114122f00ddd38053168d110 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, Here is a direct link to the document compiled during the preparation of the GCDC2016 with the instructions to set up CTU-IIG drivers: http://www.gcdc.net/images/doc/REP.802.11p-on-APU1D.pdf , which originate from https://gist.github.com/lisovy/80dde5a792e774a706a9 . One of the students participating in GCDC, Albin, even created a website for the complete communication unit: http://rndits.com/ So 802.11p, and even GN\BTP\ASN.1\CAM+DENM seem to work :-) Best Regards, Alex Voronov On 26 April 2016 at 13:10, Lei Chen wrote: > Thanks Alex, it is going well with GCDC2016. We have successfully > conducted safety and communication test at the the test site in IDIADA. = We > are now at the final stage of planning and the Challenge will be on 28 - = 29 > May. There will also be one week preparation workshop at Helmond, and one > day congress following the challenge. > > The 802.11p drivers is the one modified by CTU-IIG ( > https://github.com/CTU-IIG). As described here ( > https://github.com/alexvoronov/geonetworking/blob/master/HARDWARE.md) > with my colleague Alex, it seems 802.11p is not yet very well integrated. > And GCDC provides with a step by step installation guide for 802.11p on > ALIX APU1D running Voyage. All information can be found at GCDC site ( > http://gcdc.net/en/). > > Again, we take the opportunity to invite all ITS experts to come and join > the challenge. Promise it will be exciting. > > BR > Lei > > On 26 Apr 2016, at 11:27, Alexandru Petrescu > wrote: > > Hi Lei, > > I hope the GCDC 2016 plan is advancing well. > > Any idea what are the 802.11p drivers people will use at this event? Is > now 802.11p integrated in the mainline kernel? > > Yours, > > Alex > > > > Le 27/10/2014 18:24, Lei Chen a =C3=A9crit : > > Dear Alex, > > Thanks very much for the detailed explanation and also the > opportunity to share with our community about GCDC 2016. > > Please see the following for details. > > Best regards, Lei > > On 27 Oct 2014, at 16:08, Alexandru Petrescu > wrote: > > Dear Lei Chen, > > Thank you for the reply. > > Le 27/10/2014 14:03, Lei Chen a =C3=A9crit : > > Dear all, > > Just a bit self introduction, we are working on the second > edition of cooperative driving challenge (www.gcdc.net > ) and somehow we came across the same topics > here. > > > GCDC is the same organization that issued the first freely > available 802.11p driver? > > > Last time, GCDC implemented 802.11p thanks to the work with Eric > Koenders. It is open-source, I hope that is the same one you are > talking about. > > > Thanks to Alex to bring this topic up, it is very relevant for > the platoon applications. > > Basically, like Andras and John said, V2V through DSRC will be > the first implementation for initial application of platooning. > IP will most probably be used for Day2 applications that require > more data communications, for example, video streaming between > platoon vehicles or LDM. > > > [LDM? (light-based communications, LiFi?)] > > > Sorry for that, LDM =3D local dynamic map. Using DSRC and based on CAM > messages, LDM is able to be constructed, but if we consider more > accurate and complex LDM for environmental perception, I would say IP > will be needed. > > > I am happy to see IP communications are considered, even that is in > the second day. I personally do not worry very much of being maybe > later, because I think IP will support more applications, currently > unspoken of. > > It seems ETSI does this with an adaption layer (EN302 636-6-1, > TS102 636-6-1) for IPv6 to work with GeoNet. > > > Yes, there is an adaptation layer for IPv6 and geonet. It may be > highly necessary in the initial steps of bringing IPv6 as close as > possible to the deployment. > > IPv6-straight-over-80211p also uses an Adaptation Layer (the > Ethernet Adaptation Layer used by 802.11b). > > Anyway, GeoNet seems to be in the protocol stack for C-ITS no > matter what. > > > Thanks for the remark. It is true that GeoNet of ETSI ITS is > present there but one should distinguish the cases where it is > absolutely necessary - something else can not do its role. These > cases are the communications depending extensively on location: > geo-dissemination, etc. > > > Absolutely agree! In general, for infotainment application or less > time critical applications, IP network (LTE for example) will be the > best choice. However, for time critical applications or as you said, > geo-dependent applications, GeoNet over 802.11p may be necessary, at > least for the near future applications. If we consider further with > 5G, where the latency is expected to be significantly reduced, I > guess everything can be done through IP. But it is hard to draw > conclusions about it at the current stage. Anyway,I guess the > cross-layer Decentralized Congestion Control (DCC) in C-ITS should be > able to take care of this based on the QoS requirement at the > application layer and direct the traffic to appropriate transport and > access methods, at least it is supposed to do this. > > If IPv6 is considered, then the transport layer will be TCP/UDP > over IPv6 over GeoNet, though I am not sure about the protocol > overhead. It is an interesting issue to investigate. > > > Yes, it is an issue to investigate. > > At IETF there is a document called IPv6-over-80211p that I author. > The ideas expressed in this document could be used in this > investigation. The document itself lacks certain aspects that > anyone interested could contribute. > > > Thanks, I am checking with the document, I would say IPv6 over > 802.11p is absolutely an option and we are investigating the > possibilities. I hope we can also contribute to this topic. > > > For platooning in Day1 applications, GeoNet (BTP and GeoNet for > transport) over G5 maybe the most appropriate choice at the > current stage because of the advantages of time delay. > > > Not sure what you mean by 'time delay'? > > If you mean latency between vehicles, then I think 802.11p gives > better latency, in the order of tens of millseconds. > > Or you mean that products implementing ETSI ITS GeoNet have a time > advantage being already there? If so then I agree with you. > > > Yes, it is latency. 802.11p based access generally have better > latency, and a light weight BTP&GeoNet also contributes to the > latency issue. I guess IP over 802.11p may achieve similar latency > performance, though I need to check a bit more over that. As for IPv6 > over GeoNet over 802.11p, as we already mentioned, the overhead is > worth investigating further. It is also one topic we will look at. > > > We are looking at different implementations of GeoNet for > potential deployment in GCDC. As we work towards Day2 > applications, IPv6 is potentially considered. INRIA has been > working on the implementation through CarGeo6. If you guys have > more information about the implementation now, it is very > appreciated that you share with us. > > > Sure, certainly. I downloaded CarGeo6 and looked at the code. I > have the feeling that with it a car sends its position to another > car. > > At my place we have another implementation of exchanging IPv6 > routing information over 802.11p. We also have an update version > of the original 802.11p GCDC driver for most recent linux kernels > as well as other reliability improvements. > > We are investigating CarGeo6 now. But it is very interesting you have > an update version of the 802.11p protocol. I am not sure if you > already make it open source or not. If so, it will be absolutely a > great help for us to check the possibilities of applying IPv6 over > 802.11p. Could you indicate me how and where I can check and then I > can talk with my colleagues both at Viktoria and TNO for further > discussions? If we prove the performance with IP over 802.11p during > the challenge, I would say that will be a great contribution to > C-ITS, at least for some part. Thanks very much beforehand:-) > > Also, if you know teams that want to show their implementations > of cooperative driving to the world, GCDC 2016 is the place to > go. They are free to contact us for registration or check > www.gcdc.net for details. > > > YEs, this is a good announcement. Please state here what are the > participating conditions - is it free to join, what are the fees > involved, in which country is it happening. > > > Thanks Alex, it is my pleasure to share with our community the > announcement. > > GCDC2016, or i-GAME (www.gcdc.net) is the second edition of GCDC > based on its success in 2011 and with the purpose to accelerate > cooperative driving through public challenge. GCDC2016 will mainly > focus on the interoperability of communications, e.g. communications > are vendor independent and teams are very welcome to implement based > on different equipments from different vendors . However, the > communications protocol will align to the latest C-ITS standards > (Release 1) and potentially will contribute to Release 2. > > It is totally free to join the challenge and in addition to that, > teams will get support from organizers (TNO and TU/e from holland, > Viktoria Swedish ICT from Sweden and IDIADA from Spain). The final > challenge will be Q2 2016 at the test site in Helmond in Holland, > exactly the same test site as GCDC 2011. GCDC2016 have two challenge > scenarios and one demo scenario. Challenge scenarios include both > urban (intersection passing) and highway (platoon merge due to > roadwork). Demo scenario is about emergency vehicle passing. All > scenarios are defined to be close to reality and the implementations > are also expected to be as close-to market as possible. We want to > show the benefits of cooperative driving and also raise the awareness > from both government and public. > > The call on registrations is on-going. Notice that the registration > is not binding at this stage. Teams can show interest and ask for > further information and if possible, the organizers may help to > assist to find partners. Teams are also very welcome to contribute to > the implementation of communication protocols together with us. Just > drop us emails :-) > > For those who are interested, some general requirements are as > follows, =E2=80=A2A vehicle that will be fitted with the requirements > =E2=80=A2Minimum longitudinal automation =E2=80=A2Interoperable V2X commu= nication and > interaction =E2=80=93 will be tested both remotely online and physically = at > the challenge site =E2=80=A2Drivers are in the vehicles, safety is critic= al > =E2=80=A2Drivers and support crew =E2=80=A2Budget for travel, transport a= nd > subsistence =E2=80=A2Taking part in preparative workshops and the rigorou= s > functional testing before the challenge =E2=80=A2Be ready by Spring 2016! > > In return, the teams will get =E2=80=A2Once in a lifetime opportunity to = work > with universities, OEMs and authorities to forward the state of > cooperative autonomous driving =E2=80=A2Get in contact with world class > companies and people in this field =E2=80=A2Collaborate at the forefront = of > standardization efforts =E2=80=A2Help your institution learn and build it= s > reputation =E2=80=A2Win the challenge and eternal fame! > > Just a video introduction of last time=E2=80=99s challenge > (https://www.youtube.com/watch?v=3DlmRifLzw8iA) for those who are > interested. Teams now can register at www.gcdc.net or contact the > following people. > > For registration and team information: l.r.r.schrijnemakers@tue.nl > (Laurens Schrijnemakers) > > For project information and collaboration: sander.maas@tno.nl (Sander > Maas) > > We sincerely look forward for teams from all over the world to > participate :) > > > Alex > > > Best regards, Lei > > > *Lei Chen, PhD* Senior Researcher Cooperative Systems > > > > *Viktoria Swedish ICT AB* Lindholmspiren 3A SE-417 56 G=C3=B6teborg, > Sweden Tel: +46 76 777 1449 E-mail: lei.chen@viktoria.se > www.viktoria.se > > Part of RISE > > On 27 Oct 2014, at 12:22, Varadi , Andras (lesswire AG Ungarn) > >> > wrote: > > Dear Alex, John I agree with John, but would like to point out > that I think its likely that we will need to extend EU > Geonetworking (EN 302 636) to work over IP (e.g. LTE) links > also. I think we will have such requirements for EU Day2 or 3 > (2^nd , Third generation C-ITS) (example: update our Local > Dynamic Map with a new Warning message received over cellular > connection (not G5/11p)) =C3=9Cdv=C3=B6zlettel / Best regards, Andr=C3=A1= s > V=C3=A1radi Project Manager =E2=80=93 C2X/ITS Systems > > Automotive & WLAN Group lesswire Hungary***|***Office: +36 > 23521 667***|***Email:Varadi@lesswire.com > > *From:*its > [mailto:its-bounces@ietf.org ]*On Behalf Of*John > Kenney > *Sent:*Saturday, October 25, 2014 1:45 AM *To:*Alexandru > Petrescu *Cc:*its@ietf.org > > *Subject:*Re: > [geonet/its] FYI - ETSI ITS - work on cooperative cruise > control, platooning Hi Alex, Thanks for sharing this. I think > many of us in the DSRC/Cooperative ITS community consider these > two applications to be a very natural fit for the technology. > Furthermore, my expectation is that the applications can work > well with one-hop V2V communication of the type that does not > typically use IP. So, I don't see a benefit of including IP. > That doesn't mean it wouldn't work, but as you know the DSRC > community generally plans to use a lighter weight protocol, > WSMP, for applications that do not need IP. I expect ETSI will > think along similar lines. Best Regards, John -- John Kenney > Principal Researcher Toyota InfoTechnology Center, USA 465 > Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. > Mobile: 650-224-6644 On Fri, Oct 24, 2014 at 8:16 AM, Alexandru > Petrescu >> > wrote: Hello > geonet/itsers, > > ETSI ITS group is an SDO in Europe. They produced many > standards in the past for vehicular communications, e.g. ETSI > ITS geo-networking among others. > > ETSI ITS recently agreed to start working on > pre-standardization items called "Cooperative Cruise Control" > and "Platooning". These two applications make automobiles (and > trucks) talk to each other continuously to keep speed constant. > It helps relieve automobile driver stress in jam situation or > reduce gas consumption by 'platooning'. > > Currently the focus is on requirements including communication > requirements. > > In my oppinion, and this is why I forward it to this group, > establishing direct IP connections between vehicles may open > paths for exchanging IP data containing speed/location and > trigger a control process of adapting the speed. One already > controls vehicles by sending IP data to them, from the > infrastructure. It would be a simple matter for IP experts to > send that same data from other vehicle, without going to the > infrastructure. > > Thoughts? > > Yours, > > Alex > > _______________________________________________ its mailing > list its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > _______________________________________________ its mailing > list its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --001a114122f00ddd38053168d110 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=
Hi All,

Here is a direct= link to the document compiled during the preparation of the GCDC2016 with = the instructions to set up CTU-IIG drivers:=C2=A0http://www.gcdc.net/images/doc/RE= P.802.11p-on-APU1D.pdf , which originate from=C2=A0https://gist.github.com/lisovy/= 80dde5a792e774a706a9 .

One of the students par= ticipating in GCDC, Albin, even created a website for the complete communic= ation unit:=C2=A0http://rndits.com/

So 802.11p, and even GN\BTP\ASN.1\CAM+DENM seem to wor= k :-)


Best Regards,

<= /div>
Alex Voronov



On 26 April 2016 at 13:10, Lei Chen <lei.chen@viktoria.se> wrote:
Thanks Alex, it is going well with GCDC2016. We have successfully conducted= safety and communication test at the the test site in IDIADA.=C2=A0 We are= now at the final stage of planning and the Challenge will be on 28 - 29 Ma= y. There will also be one week preparation workshop at Helmond, and one day congress following the challenge.=C2=A0

The 802.11p drivers is the one modified by CTU-IIG (https://github.com/CTU-IIG). As = described here (https://github.com/alexvoronov/geon= etworking/blob/master/HARDWARE.md) with my colleague Alex, it seems 802.11p is not yet very well integrated. = And GCDC provides with a step by step installation guide for 802.11p on ALI= X APU1D running Voyage. All information can be found at GCDC site (http://gcdc.net/en/).=C2=A0<= /div>

Again, we take the opportunity to invite all ITS experts to come and j= oin the challenge. Promise it will be exciting.=C2=A0

BR
Lei

On 26 Apr 2016, at 11:27, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

Hi Lei,

I hope the GCDC 2016 plan is advancing well.

Any idea what are the 802.11p drivers people will use at this event?=C2=A0 = Is now 802.11p integrated in the mainline kernel?

Yours,

Alex



Le 27/10/2014 18:24, Lei Chen a =C3=A9crit :
Dear Alex,

Thanks very much for the detailed explanation and also the
opportunity to share with our community about GCDC 2016.

Please see the following for details.

Best regards, Lei

On 27 Oct 2014, at 16:08, Alexandru Petrescu
<alexa= ndru.petrescu@gmail.com> wrote:

Dear Lei Chen,

Thank you for the reply.

Le 27/10/2014 14:03, Lei Chen a =C3=A9crit :
Dear all,

Just a bit self introduction, we are working on the second
edition of cooperative driving challenge (www.gcdc.net
<http://www.gcdc.net>) and somehow we came across the same topics
here.

GCDC is the same organization that issued the first freely
available 802.11p driver?

Last time, GCDC implemented 802.11p thanks to the work with Eric
Koenders. It is open-source, I hope that is the same one you are
talking about.

Thanks to Alex to bring this topic up, it is very= relevant for
the platoon applications.

Basically, like Andras and John said, V2V through DSRC will be
the first implementation for initial application of platooning.
IP will most probably be used for Day2 applications that require
more data communications, for example, video streaming between
platoon vehicles or LDM.

[LDM? =C2=A0(light-based communications, LiFi?)]

Sorry for that, =C2=A0LDM =3D local dynamic map. Using DSRC and based on CA= M
messages, LDM is able to be constructed, but if we consider more
accurate and complex LDM for environmental perception, I would say IP
will be needed.


I am happy to see IP communications are considered, even that is in
the second day.=C2=A0 I personally do not worry very much of being maybe later, because I think IP will support more applications, currently
unspoken of.

It seems ETSI does this with an adaption layer (E= N302 636-6-1,
TS102 636-6-1) for IPv6 to work with GeoNet.

Yes, there is an adaptation layer for IPv6 and geonet.=C2=A0 It may be
highly necessary in the initial steps of bringing IPv6 as close as
possible to the deployment.

IPv6-straight-over-80211p also uses an Adaptation Layer (the
Ethernet Adaptation Layer used by 802.11b).

Anyway, GeoNet seems to be in the protocol stack = for C-ITS no
matter what.

Thanks for the remark.=C2=A0 It is true that GeoNet of ETSI ITS is
present there but one should distinguish the cases where it is
absolutely necessary - something else can not do its role.=C2=A0 These
cases are the communications depending extensively on location:
geo-dissemination, etc.


Absolutely agree! In general, for infotainment application or less
time critical applications, IP network (LTE for example) will be the
best choice. However, for time critical applications or as you said,
geo-dependent applications, GeoNet over 802.11p may be necessary, at
least for the near future applications. If we consider further with
5G, where the latency is expected to be significantly reduced, I
guess everything can be done through IP. But it is hard to draw
conclusions about it at the current stage. Anyway,I guess the
cross-layer Decentralized Congestion Control (DCC) in C-ITS should be
able to take care of this based on the QoS requirement at the
application layer and direct the traffic to appropriate transport and
access methods, at least it is supposed to do this.

If IPv6 is considered, then the transport layer w= ill be TCP/UDP
over IPv6 over GeoNet, though I am not sure about the protocol
overhead. It is an interesting issue to investigate.

Yes, it is an issue to investigate.

At IETF there is a document called IPv6-over-80211p that I author.
The ideas expressed in this document could be used in this
investigation. The document itself lacks certain aspects that
anyone interested could contribute.

Thanks, I am checking with the document, I would say IPv6 over
802.11p is absolutely an option and we are investigating the
possibilities. I hope we can also contribute to this topic.


For platooning in Day1 applications, GeoNet (BTP = and GeoNet for
transport) over G5 maybe the most appropriate choice at the
current stage because of the advantages of time delay.

Not sure what you mean by 'time delay'?

If you mean latency between vehicles, then I think 802.11p gives
better latency, in the order of tens of millseconds.

Or you mean that products implementing ETSI ITS GeoNet have a time
advantage being already there?=C2=A0 If so then I agree with you.

Yes, it is latency. 802.11p based access generally have better
latency, and a light weight BTP&GeoNet also contributes to the
latency issue. I guess IP over 802.11p may achieve similar latency
performance, though I need to check a bit more over that. As for IPv6
over GeoNet over 802.11p, as we already mentioned, the overhead is
worth investigating further. It is also one topic we will look at.


We are looking at different implementations of Ge= oNet for
potential deployment in GCDC. As we work towards Day2
applications, IPv6 is potentially considered. INRIA has been
working on the implementation through CarGeo6. If you guys have
more information about the implementation now, it is very
appreciated that you share with us.

Sure, certainly.=C2=A0 I downloaded CarGeo6 and looked at the code. =C2=A0I=
have the feeling that with it a car sends its position to another
car.

At my place we have another implementation of exchanging IPv6
routing information over 802.11p.=C2=A0 We also have an update version
of the original 802.11p GCDC driver for most recent linux kernels
as well as other reliability improvements.

We are investigating CarGeo6 now. But it is very interesting you have
an update version of the 802.11p protocol. I am not sure if you
already make it open source or not. If so, it will be absolutely a
great help for us to check the possibilities of applying IPv6 over
802.11p. Could you indicate me how and where I can check and then I
can talk with my colleagues both at Viktoria and TNO for further
discussions? If we prove the performance with IP over 802.11p during
the challenge, I would say that will be a great contribution to
C-ITS, at least for some part. Thanks very much beforehand:-)

Also, if you know teams that want to show their i= mplementations
of cooperative driving to the world, GCDC 2016 is the place to
go. They are free to contact us for registration or check
www.gcdc.net <http://www.gcdc.net> f= or details.

YEs, this is a good announcement.=C2=A0 Please state here what are the
participating conditions - is it free to join, what are the fees
involved, in which country is it happening.

Thanks Alex, it is my pleasure to share with our community the
announcement.

GCDC2016, or i-GAME (www.= gcdc.net) is the second edition of GCDC
based on its success in 2011 and with the purpose to accelerate
cooperative driving through public challenge. GCDC2016 will mainly
focus on the interoperability of communications, e.g. communications
are vendor independent and teams are very welcome to implement based
on different equipments from different vendors . However, the
communications protocol will align to the latest C-ITS standards
(Release 1) and potentially will contribute to Release 2.

It is totally free to join the challenge and in addition to that,
teams will get support from organizers (TNO and TU/e from holland,
Viktoria Swedish ICT from Sweden and IDIADA from Spain). The final
challenge will be Q2 2016 at the test site in Helmond in Holland,
exactly the same test site as GCDC 2011. GCDC2016 have two challenge
scenarios and one demo scenario. Challenge scenarios include both
urban (intersection passing) and highway (platoon merge due to
roadwork). Demo scenario is about emergency vehicle passing. All
scenarios are defined to be close to reality and the implementations
are also expected to be as close-to market as possible. We want to
show the benefits of cooperative driving and also raise the awareness
from both government and public.

The call on registrations is on-going. Notice that the registration
is not binding at this stage. Teams can show interest and ask for
further information and if possible, the organizers may help to
assist to find partners. Teams are also very welcome to contribute to
the implementation of communication protocols together with us. Just
drop us emails :-)

For those who are interested, some general requirements are as
follows, =E2=80=A2A vehicle that will be fitted with the requirements
=E2=80=A2Minimum longitudinal automation =E2=80=A2Interoperable V2X communi= cation and
interaction =E2=80=93 will be tested both remotely online and physically at=
the challenge site =E2=80=A2Drivers are in the vehicles, safety is critical=
=E2=80=A2Drivers and support crew =E2=80=A2Budget for travel, transport and=
subsistence =E2=80=A2Taking part in preparative workshops and the rigorous<= br> functional testing before the challenge =E2=80=A2Be ready by Spring 2016!
In return, the teams will get =E2=80=A2Once in a lifetime opportunity to wo= rk
with universities, OEMs and authorities to forward the state of
cooperative autonomous driving =E2=80=A2Get in contact with world class
companies and people in this field =E2=80=A2Collaborate at the forefront of=
standardization efforts =E2=80=A2Help your institution learn and build its<= br> reputation =E2=80=A2Win the challenge and eternal fame!

Just a video introduction of last time=E2=80=99s challenge
(https://www.youtube.com/watch?v=3DlmRifLzw8iA) for those who are
interested. Teams now can register at www.gcdc.net or contact the
following people.

For registration and team information: =C2=A0l.r.r.schrijnemakers@tue.nl
(Laurens Schrijnemakers)

For project information and collaboration: sander.maas@tno.nl (Sander
Maas)

We sincerely look forward for teams from all over the world to
participate :)


Alex


Best regards, Lei


*Lei Chen, PhD* Senior Researcher Cooperative Systems



*Viktoria Swedish ICT AB* Lindholmspiren 3A SE-417 56 G=C3=B6teborg,
Sweden Tel: +46 76 777 1449 E-mail: lei.chen@viktoria.se
<mailto:> www.vi= ktoria.se <http= ://www.viktoria.se>

Part of RISE

On 27 Oct 2014, at 12:22, Varadi , Andras (lesswi= re AG Ungarn)
<Varadi@lesswir= e.com <mail= to:Varadi@lesswire.com>> wrote:

Dear Alex, John I agree with John, but would like to point out
that I think its likely that we will need to extend EU
Geonetworking (EN 302 636) to work over IP (e.g. LTE) links
also. I think we will have such requirements for EU Day2 or 3
(2^nd , Third generation C-ITS) (example: update our Local
Dynamic Map with a new Warning message received over cellular
connection (not G5/11p)) =C3=9Cdv=C3=B6zlettel / Best regards, Andr=C3=A1s<= br> V=C3=A1radi Project Manager =E2=80=93 C2X/ITS Systems

Automotive & WLAN Group lesswire Hungary***|***Office: +36
23521 667***|***Email:Varadi@lesswire.com
<mailto:Varadi@= lesswire.com> *From:*its
[mailto:its-bounc= es@ietf.org]*On Behalf Of*John Kenney
*Sent:*Saturday, October 25, 2014 1:45 AM *To:*Alexandru
Petrescu *Cc:*its@ietf.or= g <mailto:its@ietf= .org> *Subject:*Re:
[geonet/its] FYI - ETSI ITS - work on cooperative cruise
control, platooning Hi Alex, Thanks for sharing this. I think
many of us in the DSRC/Cooperative ITS community consider these
two applications to be a very natural fit for the technology.
Furthermore, my expectation is that the applications can work
well with one-hop V2V communication of the type that does not
typically use IP.=C2=A0 So, I don't see a benefit of including IP.
That doesn't mean it wouldn't work, but as you know the DSRC
community generally plans to use a lighter weight protocol,
WSMP, for applications that do not need IP.=C2=A0 I expect ETSI will
think along similar lines. Best Regards, John -- John Kenney
Principal Researcher Toyota InfoTechnology Center, USA 465
Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160.
Mobile: 650-224-6644 On Fri, Oct 24, 2014 at 8:16 AM, Alexandru
Petrescu <alexandru.petrescu@gmail.com
<mailt= o:alexandru.petrescu@gmail.com>> wrote: Hello
geonet/itsers,

ETSI ITS group is an SDO in Europe.=C2=A0 They produced many
standards in the past for vehicular communications, e.g. ETSI
ITS geo-networking among others.

ETSI ITS recently agreed to start working on
pre-standardization items called "Cooperative Cruise Control"
and "Platooning".=C2=A0 These two applications make automobiles (= and
trucks) talk to each other continuously to keep speed constant.
It helps relieve automobile driver stress in jam situation or
reduce gas consumption by 'platooning'.

Currently the focus is on requirements including communication
requirements.

In my oppinion, and this is why I forward it to this group,
establishing direct IP connections between vehicles may open
paths for exchanging IP data containing speed/location and
trigger a control process of adapting the speed.=C2=A0 One already
controls vehicles by sending IP data to them, from the
infrastructure.=C2=A0 It would be a simple matter for IP experts to
send that same data from other vehicle, without going to the
infrastructure.

Thoughts?

Yours,

Alex

_______________________________________________ its mailing
list its@ietf.org <= ;mailto:its@ietf.org&= gt;
htt= ps://www.ietf.org/mailman/listinfo/its


_______________________________________________ its mailing
list its@ietf.org <= ;mailto:its@ietf.org&= gt;
htt= ps://www.ietf.org/mailman/listinfo/its



_______________________________________________ its mailing list
its@ietf.org https://www.ietf.org/mailman/listinfo/its



_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its


--001a114122f00ddd38053168d110-- --001a114122f00ddd3e053168d111 Content-Type: image/png; name="GCDC mailbanner1-72dpi[41].png" Content-Disposition: inline; filename="GCDC mailbanner1-72dpi[41].png" Content-Transfer-Encoding: base64 Content-ID: <8AC49B12-9808-487E-A7DB-BC9F41A69853@viktoria.local> X-Attachment-Id: ced146b7133ba161_0.0.1 iVBORw0KGgoAAAANSUhEUgAAAUAAAABOCAYAAABR7c9uAAAAAXNSR0IArs4c6QAAQABJREFUeAHs nQecVsXV/89TtrJLRzrsUgUEARUQUQFRscXeuzHGGDXWWGKMmm5v2CtR7MbeFQRFsSJI70V632XL U//f39xndh+WBUvyfv558zLw7L137pQz7TfnnDkzNzRp0qT0I488YpFIxOTS6bSFQiF3v+WfkKVS acvNMRsxZLC1bNHMNm7caKtWr7OyzZutvLrKYvGEVVVXW0VVtcW4JhIxs5RZknhEtgT3qXTIQmGe ceFwxHKiYcPDIuGwyzccDpko0XM4FNCicEonxLuQEV5heCf/NLRGiK83+q+U08qHYFHC8Z8wEYvo BWFDyodfNBy1cDTi8lR5U+kkWUQsStgUkURyOpVQJOKLFj1z77JXutyTD76kp8TDxEm5eGHRE0pZ iLKmSZUQlk7yTqGpX5KBQNJOQz+3yjmVVCi9d2RaMhF3+Ts6SFfvYvEkdZgMAlGfqVCScikv1XGC NMiLBPTPJay8MukRnSYgHQXG5eXlWTQadc+Ks8PtqIH/9hrIxjaNhS5dulh0zpw5dv/99/+osn89 YYLt262rNS0utPziImsFGHbMiVh+AwCkYUOLF+QDhDFLFxQ6UKyIx628qtLWbq60FWs3WsXmctu8 ucLKyjfZ+nUbbOOGjba5rAzQrLRqgDMJkKYSCQa1wzqL5ORYXiTX8vJzLSc3F7COul84EnYA6JBP EAFQJIVKAI9ARtga4apBr38RASHAlwOtOaQZjuQEwM97wVM6hB/v+WNxgMaBD8Am4AWiAZckABiA SEhIiAs5kBbehKA3iOMAm7ByAnQBZwqQEUgRnHuek4QlA4XSBJHkmcQIG9ynk5Q/QV1wTRFP6VRV xa06FmNiibuykowrl/JJKTzvBLgORfFTmR34CtyhLRvodmCeam2H+79cA0OHDgUjGOzeCSiyB4n3 D66MNgaURvCEyVPdD2bQchmYhfkFlp8TtSK4yMYAVH5BnjUGBHdu1dzaNyi0Zs2KbZeGja1BoyJr tEuJRZq3dOAYys2zSH4hgAB3CNdUCcxUAwTVcJObKiptDcC4YtUqW7N2rZVvAiDj1Y6TCjHYQwkG NMCQqE7iDzBUx60SYIjBZsJMARwOChj4AtGI4+CIDJhGVWjHAaahPUS+4sGASwLCEeGXgnvLFfcW IAwgkgPnGyW/GPAijgseC6CiugDRAFwFZppVyI5kSMPhsMJEHD0hcWjQltYL8tQlIXADieLcCwDB c/c+zgSQTsUtEQNU8Q+4PvjTKBNAPNdiMXGHSke8HnmJKsqbzlV6AruAY3QcsoA3SVpw4wLBABxD bmLKbuvttz2F2uF21MB/WQ1I6mXUB86LRv657lXwx+hx/9zI18DFJ87A31xR4d5u9Wf67BqvfO70 K2KQ5zLS8xC/ihBBmxTmW1MAs0XjxtasxU7WpGlja9Wo2AoLC6xdy+Y2qG17a9GjC9xfvqXzcgHO AosXFlmVuMtwDlxRFeBXaZWI4WWbNtnmjWVWVVlhleV63mib8Ksor8AvZnFESARnC1HwkMRngDIO kFYDDnG4tDjveOm4SPnHANSkA5MwojplT+c5wAlYaYFMIH460BQA6Z+rKDhTJQ5AiaOUEJxMkl9U XB00CIcMro4UkrC5IcJK5AcS8cchUqeF4i4tx7sCloAYYJiCTgRyJ6bD9zlAExgqPwE6mQD2wCL3 EsUFoAJfx5UKLLl3kF1nsssGQ5Gww+2ogf8LNVADgH4AbIsTSGtQUSPSawUDk7EmFoiB58DTjVxV mUBE4CA40Hv9D1sVflW83QBgMgpBHvSDcmWVwdVWcJ3p7sVZijDpAlty0x5usnVBrnUsLrCuTYqs e4um1rFNC2teWmo5JV0svFMHSzVpbqGde5o1aOiAMpQHZ4monORfrHyjla1bY5vWwUnCVcYBTLFl ccCgErCsgtuUSL65ssrKK+AkYcnSUeA6mmcVsTTivMKh2+QXhzOTfg4WLPjxLEQLQacDOpWXOgkD YiF5UgdJ3kcB3VSK5xygj/jpalWYakkwKG4OsNIdeUkLGg4Ddlwlwqcj4nh5R30n0uLy0B86dpHY tAeQ5ypLnJ+cuFognvg8U07pPMMZkT3N1be1C7zjz44a+D9cA9G6g6Huc03dOCDTU82NRrp7vWUc x94oVBDWXQM/d/sD/jjOMhOunLE+rwzo1G/VJob6KmuVt9A6ww3u0XCiDWyab12Lc6xpoXSEzSyv ZQuzps3NdmpjkSZNLdqqreW172SFTVtZa8TvECJ3jZPODs4qJU4PQK6qgnPcuN42rF9jG9atA/Qq ASsBmMApYhvQYa7ZUGYby6qtKi6uThxWGr1ctdNdVlRXsChBeoBjKJTgHkh0gI/4LG5QGcsP/ahA K6RVoQTAGAGqCCdRXbrFtERgN7lwLz5bCk3NCoj6SichPSRvVMdKMwQnLbFeCy+pJGFJS9rAEPHc P8cZasFH6fFaKgSl/wOcD7dlG2874vbCb+tdXX89/5j8fNj64mX7bS8fH85fs0vo/erGzw6jex+u rv8Pfc6On32fHX9b/tlhfuj9T0mrvjh1/eo+/0/Q81PzqEtLVAnJ+QRz0eE1bdq0brj/jGeJedAb 4zqD6xwA6NV1IWu9MWSlBTHrlbvWBsDJdVqz0vIWzLFqFjVCLJxEGhTAGTaySOu2ltOxg0XalFq0 TReLtGhlYcTpUE6+RQmS17CZNdqpvbWitGmAsboCcXrzJtu0EdGaRZpqFnKkR5MovX4D/mWI/nB5 cZachc8bKlO2esU6OM5yQKaKNFgJT1XBh2kBQqIud8wFCUAuDm1x/cNPqjmHkwJHIEv60BQ/XeO6 Am5J8qjmXVz3iLluIgL9eKROYACpD/GCaYAyAYDG4Tqr1LSoCaRnhAUFEMVTCoMDTpHb73UeXL43 YCbA9sLX9873u+z0f2g4xfFhfT+Wn7/XO/++vrD1vcv282ll+2XfZ9Oefa949Tmtuuejyimnf9R1 24qfXRbF8flvK3zddOt79nHrS8u/8/HqPvs4/r2u3s+H1bO/zw6XfZ/9XvdyPp3scPXdZ8et7322 3/eF1Uhyzmfep08fe/TRRxlY/2GiEmM4EKqpLHVscTXiZ1R5AgxARVJhA/ya5qJjRHZ0+jLp+xRS IAAUpSMImjKryQH4FFdg4NJwqfEHIFGSrBDnFzd1v8ZCRFycRZgYCzRaSVZcLWIEFj1wgyS/vqLc vvn5udb581nkFwXoBErQKnSDOxPdjnbS0gKL6yiOLj0H9En81X2whMNVUUSi0pG/nvkX8H6CS4og 9YTSo3yiXWWIEPCqxmGbmBOyvCT8pmhwnKBAE8TdhmvdurUddNBB9uGHH9q8efNs2LBh1hj97Guv vUb5xZsHTv1kt912s5dfftnWr19vRx99tK1YscI++ugjF6Br167WsmVL99ykSRNT+I8//hiOWqZF tS4od+3zrrvuavq98MILjqs+4ogj7LvvvrNPPvmExbRmtvfee9u4ceNsw4YN1r17d9tpp51sAlYJ Sse1J0n5NDWR77HHHq4se+21l82cOdOl5d+3bdvWOnfubOPHj68lIOuu7uDx8XwQPXfo0MGKiops +vTp3nubV+V18MEH2x133EG3q52EPN11IwowfX1l3yucp8WPU//s08p+1r0vi78qjez7us9aIBCN Pp26+StfXwbdKy1nyaCEcD6e7vVO6emn8ii8wmaH8fcKm+3kX5dOH9an7Z+zw/l0/LvsNLPvtxKB CwsLbZdddskO87/2XjCxZXXSMJnS1Pp78FDYgAML4vHX3WSAigg5OXnu5yskz99krgnMa/KwjWy6 ehU+BZm8JK6CzFs4gdXWrpYm/84JsAEZNTF8qLogFqQYpCxe0KyYSUE2jU5B6LhLwjBZaEHEdxDl 5DuOOua1115rHTt2tN13393ee+89+81vfuM6anFxsY0ePVrBrYCFqN/+9rfWvHlz6927t3322Wd2 +umnW0NMoK644goHevvss49dfvnlDiQFjkcddZQdc8wx1q5dOwdsa1nZF0CtXLnSAaWeW7RoYX/+ 85/dAGnUqJGtQw1x7rnnOo7p17/+tV144YUuHQG0bFBFg8BPP7m6nV3luOaaaxx9F110kY0aNcqW LVtmJSUltmDBAkf7mWeeaV988YU1aNDAcWfKU3QtXbrUpdemTRu30CZ/0afxsQrLBKlHBL4/+9nP nElVNgD6+nREZf1Rvan82XVfH92ahG688UZTHag+le8f/vAH+/zzz91VpmJyO++8s/3tb39zE4/q WhOCyqs4s2bNcvX4+9//3j799FN7++237S9/+YvNnj3bHnvsMRff11fda//+/e2Pf/yjrV692n73 u9+5djvyyCPtnnvusTfeeMMB+PLly11empREw/XXX+/qzCXMH19GpX3BBRfYCSec4OpMJneqB5XF 15nPX3GPO+44V/8yU1MbvPjii1u1q89D1+y427rPDl/3voYD9C+UiNBZaO2dT9gXyvv/J1xFm5s0 GNvcUfMCAg16ARt/5eWeA2r1Ro5oxBMvFXB8gYcWJAL+yqXiAmfSD6IpJv/kiOcCuQf3RyYoaeot DvzI/EXQp3R9ntkDQ3Rt5RyxQerZ70SrwzEBqcuTP5lg2VFq0oQwZjbyF59IQMeBKoqAWHGVeSYB 3SkDnOi7/fbb3fXKK690nI04LYls6rRSj/h+cdVVV9mQIUPskEMOsW7dutnYsWNt8ODBVlpa6gBQ fUj+p512mp166qkmgGvVqlXNgNZgOvnkk+3WW281pSWA04q9Bos4QHGX4q5uuukmE5jKaFUArMEp p7T3228/e+6559yz/mjQeE5F3KpoEHho8CqtCqwVfvWrX9mxxx5rb775pn377beOI+nVq5ejQ8Ci eALy2267zRYuXGh33nmnLVq0yA1wDXSBnrjhl156yQGCnh944IEaGrLbuMYzc6N69hxd3XfZz+Kc xZUKwH/5y1+6iUYcscrRs2dP+/rrr11wlemVV15x4DJ8+HAHHCqvOHbvBIqazMT9nn/++a4cqkPV wbvvvuvoEZir3pSvyqU2FEiK+9ako/hPPPGEnXPOOU4qEIjLkF7u0EMPdXHFpWc736fkJ5oFyPfd d58tXrzYRowY4fI95ZRTTHUvOsTVK30BpaQI9TX1LU28jz/+uOtroufBBx+smZzV36ZMmWIHHHCA C68NHZqQevToYTNmzLAxY8a4vr29NtlKB5hNuC+QEvj/7jRGs8gQnaLLFU7EMehlTuKAjIBujOs9 r9SxP/v0E9tUXsawZ1A028n2GDCIuAK8wAVFJH4mjsMJvcoECDgrQUqQpsuKQHqt+6COJIoH/J7e CHxEtk/DPfkMg5h6S7gM7ylE1X8XRil4fk7eLifnF6C6S9kFFu1KO0iaOAI8xXVlERDyTvUFIGiB xu0acWFc9jV/BBjibm6++WZ79tlnXZnE5YkT2YyZkTqoBsNf//pX1+GOP/54xzGKU9DMXlJS4oBF CWpASYy++OKLHZe3Zs0aN2jEjUgMFOcgLu6GG25wQCOgVZt26tTJTjzxRLvsssvs0ksvdQNFopZo ++qrr7CBZAGJtDWA1fkVrgz9rMRrpSv/V1991Z555hkXR+LpgQce6MBBIC4uVGE18MQNqm9IRBct GkACCQGt4kik18DXgN9zzz3dhCAQ1CA77LDDHGcpEBVweFff+PHvfuh18uTJ9s033zigfeedd0xc KDu2bMCAASaxXcCnSUnv1D7nnXeeiSMTMPfr18/Vj/ISR6+6EeDdcsstLo7KK263tLTUcXlPPfWU AwzpJr36QmCrdFR34o4lEU6cONEEWHPnzjXFEehoMtx3331NHKs4N9W5OGQBnCYjSRCqV7XZoEGD HLgJwASaqtszzjjDqSQuueQSB3QnnXSSm4BUh/qpzc866ywHmmpnTUS/+MUv3ESmOhBdAlfRojKp vOoD4u4lJagO1T7ba5Ma2Wx7gbbdcCK0Vk8QhAsG5g9N7/vC1bwPRncNKR6U9V6vHCwJCQA1eQQw FQQvK9vEQPu93XL2Ofans8+Fy7kVU5YtdVEukkspk4XLT2hUCyyCKh/OZaU/yslduSO4VmIFR/ov cxW3HptmTdZ5BeFdDj5cTZ6iWJAZd+kI5KTXc2S4Py4W3tS5fkEuLlMBnHsOMuFNwMlqpwyW2ryD G+WdFj+SMtuR4jJDc5Bq8FfA8vDDDzvuS/fS44kr0+BSJ1fHlygmwBNYiKOSXkvgJm7p3nvvdfdK TTP4tGnTHKBInBPnI45RM7yASINCIKvBIpBRO7Zv397da2CJ+5EIpAGgji4aRJN+qm8NWImlCqtB JyfAlQgoYJBTGKWhQTN16lQXT3FUlrfeesulKc5Sg0nAr3casD5dxRV9qgdxsOKUJLJrYKrMAhYN 5n+3E/crAJbYKhWDnEBWnKm/Fzhp4Ou9QKlv376OLgGP748CBNX7P/7xD9ceaj+J91JJSBRWGgI2 gYg4RQGfnNLUhCbuV5OMJkBx76p7AajqXD9NHErjoYcechy82lx5C5TFGSu8nLhFAan6jCYdvw1T 4Cx9qOqzpKTEtCtNkoTe6yd6FtKvVP8qi/IR/eJSpZoRVymOXe0ljlVlUr9SPxTAapL9PreVCPx9 EbZ8Xzv4HRBReO98I/jnbV19uLrxfXi939Y777/FVZBRS4ZLRjASzcu3tgDDBtKL5OVaEhDJ8ZnU c/VpZr/yfrrKedprwmSAyam3MYMJN21ieSOGWnrtGqsaP9HSMZaKJR4LsJg4wpYLd1btRFULcZ9G FNm5uyUWIE7QkIHIqsIE+dXks60b1X9WUAefwmzJz5jzCCYDLeeWOkCfnDqZOqDEJQGDOpwGkMQq dTCBgH4CHIGXOroGhjqr9IACFe/0rBnbcykaMNL7KC1xdBpYAjZxHQInOfkrXQ0qcT3iFiQCaYBL pBF9AmgNIonG4hwkKn7wwQcuvrhI/bxTOA1kDTCJQ0pDOjFxMiqHOEGBr8BMorQGm0BCXIMGltIV 8EhsUz7iMgSK4rTEkan8qgufv/L1/dXT8GOuPq7yln5TYKbJQ/UhnZwGvPSdAmk5gaT8xZ2rHhVf AC2gllM/FTiIXtWXOHi1p2iWmCixVcAvkVrApslOTqCvPMW9C0zEtSu+9HHaeKBwqlulLW5LtKp+ RbcASECX7VSv4swFdhKDBVTiYFWvahtNbqpfcW9aLFNfU7srjOhTu2lCVH9QfHHIKq/iKK4mVnHH ak/RozIuWbLE1Us2HfXdhyA8LdbTOyU2DnlcHbY+lw0CWwFAfRH+A/zWrFltp5x2orWePMfWYkPX aL+h9vBDD7O9Lbce6oQgAp0f79ZvLrPPD/qZ9ZwwVQycNTjrdEtsXIGZDbtXPp1q4WI4lSpxYJi+ RFjhW7DY8np1txQG1snZcy3ae2fLP3C4bb77EUtvqqBDY9aS+fdDqQGDiREC3NN2XqsCe4ci5rB1 LhXHHIddKO7gBoBGO2fcYRU/NOF/czj1HQ0qdWLpsfzg/1ez+Xel82PpyB4LfoKsm4Z0mxprV199 tRv4dd9n066JQoAr8JArLS11nLdAweelfMTNCngE4vKX/k+cuQDNPwsgBUziIDXJCCAk1osD0wQm PawWOwR0ckpD3J04OAGd4opLFrgovugSd61JRNy8JitZDGzLiYMUN6YJTHFEl2hUOqJB+QnoVGZN pgJ44Y/KpXxEv/KVhKD6EGgqTaWhMJqklJYmXNEtgFZZlbZo31Z7SIf8ozlAX/n+Wl+hxSBp365z 3Kswnh2uL/xP9fNgvHX8LUFMcJbAdo8lCif+SQ/oEGrriPj8NPBzSSmqjx6mahvAaU6YZ3n7DLFQ zx4W6drBqt5+33K67WzRTh0t9sXXltt/FwyjAcBOpRZqUeROqMkwmI5eAVpNmi6TH/ZHZKh+ZG7j yBI90Yy2EdF8W07t6jtM9r3C133+MX5181MeAgJ1UJ9u3eu20vdpKbzctvuBDxnQ7sN63+z8/Dvv 58Ns75od1tfZ9sJ/3ztfDl2lZtDPO4GPdz6cnsUBeSd/mSR5l/0sWj2Hp/fiquXkr0Uocef+uS4n Lf9sgBMg6ae44jaz3/k6yb4K0DzX6jLJ/BE3KSfwU/js8maCbMHF+XwUNjs9cb3eaSKQ81fvv63r jwBAjUQ5Oh23M2dNt/c+eM9mws5WUpCGRcXWuaTURmA31rG0FEX6jTYZuT8KGz98/wPsl+f+Oohe 5++GDWttIqzrZ198bsspiLp061atbff+u9ve++xbo/eoE809Ug/OSbE/Czb53ffftVlzZrsTU/IQ c9u1bmMD9xiAwru3devR3cqnzNZoCUTCQPDcKlntH54wYbx9+eWX9t2K5W5wtdyphaNn6NDh1pCZ xznydPrGrVIINHk6wCDEAQ0RZmjp4awoz2JffWGJNSssf+T+llq73sLsZ67+fDJA2cBymN0SK7+z SFN2sVAwidH663dvbJXN93koDZWVhLR3mOkXzGeRhtnfQaKvvO2kowEk5zuzf96WnwvMn+xw3q++ q8BPzofX1eflw/t3/jn7mv0u+z47jL/f3vvsd9n3Pu62rj8m7LbSkH92mX9omnXDKQ3v/Dvvp2fv 58P4q3Rl+v0UVzdNn5/Sqvvu+9KvL3x2vdSNX/edz7u+dOrGzX6uBwBVkUHHzw6oASn+YcWKZXbP 3Xfay2+8asn1ZdYC1rQQe7P5xHmfcX7fQ/fZvkP2ZtVnT0twGMKzb75hJSjKA6d0axvqvXffsptu u9nmMxsVxxPWkAMDZJoyifE6evTj6AN2sUsvusyG7DM0K36mcklGULOImXHUvXfaO+++Yym2qbWA uZNuTzzOJyj7H33kYevM0V1HHHm0tWvWzu59/FFOkNHMI52YnATGgKYP3n8P84ebbAYgWgjH2Fhb 0AC6z6DnqafGWC+4uPPOPd/2P/Ag6JRyzUWvLZIAQ50N1IlwcELFP9+ygsMOtOTCRRYD6EKNG1lo PaeyLEbHh8lMbObsIHcmifR8xOE9d7fkkmWWrtC5OKRPcr5fa0FE5IhS7SgR1cEqb2Bn6BrevQy4 PNGh+nFPYWojhUZRJKek2tCu46D0PGzhlI6U65phpeeSy+5U0h1JdyMO4Mc4SQFStGsWlzGzOBCJ M3Wd8vKdWzo22QEqL+l/JP79O112uZSuz1finvRrXpelRQMtFNx9993OXyvh0n9JH6nVUi2GyBQm mxP5MXTWpUP6N4mD4vq06ivOTeKcdxLvJHZKV+td3TTkX5+fyqZ6FP31ufriSB8srlDiq9pQOkRJ dAJO9QU5X3c+TYmrojubU/Pv6l5LS0sdF1i3T9VHi+LW51+fX9186nuO0LjX+dUfBVAFnXHGmU5e 17MSVuH0b+Gi+Xb+BefZJGyoBlaGbFA8ak0BnAb82vPbLck2Og4S+HbWDJs4c7oNRsZu0aGd5RcW 2fD9RpAYCZJWMpmw++8ZZTf8+Tpr/N0a2ycesV5VYWvEdorWibTtys6FUraKLYK9f+aDtywHDqpv v/4BTQ4URA0K+/fesfMvvcjmTPjY+nG4wKAYaZB/UTJlLUHsXQHUTmwhK1+5xt6cON7ibVraXocc jHI513GXOVFWzPinMj7+2EN27R9+bzlLV9iQRI71ByObAYI7gR27JlgRBTgWrlphT7//jsU4WUY7 DJyeVKCTcVWcKrPsyaet+aKVrDtwcszm9VY9+StLzptjoSoEcLbPSfSOT59msRl03o2IERvLLb1+ HZMJYVkYSHw7A4DLI0UHcc6Q2e3ycMo9bYbDIVpDNOEUxt1Sr7rhT0ZmFsy9VRS1xYi9UQEm6An/ RzCFYYtdjMUX2qGuk/JZA1urbVrUEOBJdyNdkXQ12iWkTi9xRcpy9Q11cimhZZirwSldl0Qx6W2G Dx/u9DVS6D/99NNO4a761iBSXur0fqVTdl3S72iwqW7/9Kc/Of2O8pa/OEaZU0i/Jac8tUIoWpWG BqT0QQMHDnQLFBrkMneRzkuDWHmp3UpKStyAk399TkbbAjvpJlV2rVxrVVN5KR3pnhRGiyVajZQ+ SvUksw/Vx7acyiE633///a0GcXY8mdxoNVsLQlp1F51asFB9yUl/JzMcLR5JB6a6lJO+TGEklupe baF6V92JfrWHbCqV19lnn+3qWO2oNKRDU1kVVldNPhJRBfCPsSihBQbpA2WnKWN1TRB6FkgrL98m fuVV9Ku/aGXX0yh6VBbRITpFt+JpoUUTotLz+aqPKIx0jKJHeaj95af4+v2rTiZX9XCAtcl68JOP OuVll19ia778xn5enW+fFqXt2bykFTZpbA3hbCoqqqxs9RrrwPl8IzmzbsnilXb3w/fazw49Eu7r KI1nB35a/bxn1N12y5232lAAqzX7eceTTmWjQvbhIv5R8DWIwsUsDIyozrGFG+L217//jS1oMTvv /N9kpM6QvfvOm3bplb+1DhyQsE8yzz4BMz5rGLbGLdtZEY1ZyYkvG1etsTDHYg0AmPeAeXjjtddt SuepdvUlV1GhbP6FKEHImCf+YTf85Y82pBqgA/zezau2suYF1qRlW/d+AwCaR6cayfvV5Skbdc8d 7kSZy6+82s2Evp50DVKU2Qlb5gYMtCaXnQtXt9Q23nAzgLeR4okNE18mPjEAJKYE/OQrkxUxaxmg kyeitHP45Q7ai7S+s5xB/S0+6WuLL13i4khUDvIWx8ehrnp2UBeIvRFWgQMQhcMm+xDcYPaACzII /mqAiNtQx5NCWQbRr7/+ujNylimDOBNNkgI/dSB14uuuu86tVmqFVANcwCBw0uDSQFWn1yBSeuJc BBbS0ciGTEawylP0C/TE8ci+UJ1dQKoVRuWrd7K/k9mJDKu1WiuA1MqoVggFuDKOFvckA1oNGtkr ypBYA+yMM85w2/YEWFr59cbEAjT9tCqtASjA8CYhskdU+bVAoDRUPuWptLTK7Tkc0SKa5VQOOdWv v3ce3/MnO6zMSTyQCDRUdhmoC4BlWqRJSO0gukSHr8eRI0c6fwGUjIb3339/t0KtuhAH681IRJvs 9kpLUVnRjk8++aSzp9RiiHZnaPVXZRcAC6DUZh7gtOqsdtEWSFkMyL5QQKd60uSklXnVkZx2p2gr pe8fWrBRe2uCVX0K1NQeajNxlMpTeas+xZRpBV/vdK82ueuuu1x7ClyzOeLvqdrtvtZo/EHuySce t+mffW5HxXLs1UZh+xLu4rQzz7Knn3zOnnriWXvmyWfs77feZpG+PeyRfGYRVjmPLgvZC/983p5/ 8VmOlJLYafb5Z5/YAw/dZ3sl8qwDnN/zxWnrd8hB9vDjowGip/k9gzjxiHUasqc9l5+wDlUJ68nJ K/c+eK9NnYK+jIE96dOJdsU1V1m3tWW2D6epPFmQtlUlrewPN/wJep6xJ/4xxp5+4jl76OHRtv9x x9uHzXLs7cKQHVqNfdH8pfa7639nE8Z94NKaMX2q3Xb3bdYrmWMdAOMnipO2C8vx9z/8uD1JGk9B z0OPjrY+cLNPFCasIJawgTAgTz43xubOmaUibQEm4cwAEAQV//oMqx43Ft3fN5aLeUvTB263ol+e galLJ2s2+j4rOGKkFZ54hDV/+jErOvs0y9l7kDV7bJTlDRlghT8/0Ro/cKsVHHKANR71dys89QQr vvw8K77gbIvCcRQctr/lAzJF555hBccdaY0fusNyd8NmLM0OCCBQ4A4KuANbtfWNMQT4ScWAnzjF bTgZCmuW1cyvDi3w8jOwQEuAI0DSoFBH18AQ8IhD0GDQjC/gEScmEFQnlgGzOAuJbIorjknirzg0 AZwAVml4jkLvxTUob3EmJXBsGnQSNZWfQEE0agB6swiJqwIyAZgAQgAnMBV46KfBJtqUv8ol0JST OKtdKBpgchqk4m40IKUKUF4CUSnqtSNBnIf8xR0qXeWntOu6bECr+25bz9mTkupLTnWgfESvdqeI Q9K97C+1P1ocmQBIdKt+JN5qdVN1JnoFeiqvuHQxMZq05MRxyZ5O5RKgaCKbP3++m6TE3WpLpMBR TvpwhZcTPfoJgDQhiQ7F1a4ebYfUwpY4XLWb8lY9qC+JboGewmt3kLhX5a/JTxy1yijzJJn9iH6t lqs/aHFG/UG0C/Dl9+8CP5VnuwDoG2Q95+g9//I/bdcUxq0FiIK5Ebvyoivsiquvtc7MSjvt1NI6 dCxh5v2ZPf7wP9wM/W5RxJajgzs0jujz3DN2791sAEc0HQO6h8oqbFdEwteQnU896VS77ZY7rV// 3WnENtaagbXnXkPsrttH2YA9B9q4Npzv13In48Qo+/LzSbZ2zWr7/fW/t7w166w3APpEUcJ6DNrN HrvvUTvmuBOsbbv2zJ4trBUdYjcG4N/+frPdd9u9lsehqq8UxO3gihxrvGajXXnt1baIQfjiC8/b plWrbTCmU+Ny43boYYdDz+02YOAg16laQdNuiE033XiTDdp9oH3UuqFVtm5pOYjWH380XnVY40Lg ing6gY8OI43ARQn8yp57GhMX7PsWL7W8fQcDjOcg8mJPd/jBlr/vXlY9Yyrc3R7W8JJfWahJQys8 iK09u/axzcx8yQ3rMRHMs3w286eWLreqL7+2SPeuFmraxIp/d75Fdu1hBcceajmoGgoPPoCcdWAB 4AcxOVGMUDkMIcpkJBBzdtGIyDpeX1xiXadB1Kd3H2eAK7AYNmyoA62f//znTnSUaCUxUiKaBovf tyu9noBAnIvy0b2AQjZr2lmhASjg1DuZWYm7U1oygVEfk8Gv8hPXI+t9iVUSv7RdTSKgwE0AKWNf mUkIHDzA6FmDR3lrYAo4BWgCNoGgBot2EQikFEYAoQEl0JDT7oXDDz/cxmH6JSdbNHF2AkrRoIGt 7XMSX8V9SrelcqhsKrcGusooMJLzY8ZfnecP+JMdXqAksV5cnABLz6pPTSACC+Uv0BHQiBsX9yq1 hOpBNnKyS1RZBVriWqU/Vb0I6NQ2qn/9NImp3Npip8lEaSsf1a+ASjTJz7eXL4YmB+WlNpSTraf2 CKtNxKV6ExqJ7apLtZHqUn1GaWkSk0iuCcqL6xLr5V8KVyonfare61k0yQZRdGqi/Xe6begAz3CV rAKpEj4cP85eAriGVaN3y4nb4UcdYxdfenlNY2cTVEDD7MUiSLNGje2VaZOtNedE7QKX9syMyYBC yL6dMc1azllia/hKUapnF7vxb7dYUXFRdhLuvoAV0uHDR9jIw4+0g48/Afb4ZOvUtZv9/tqrbd7n X9iRiMdvcwR8L8Soc885z/phPS+hEmEvk5ZEkeC+Y0mptW/d1uauXWUfLVtghyDKLti0wb5YNMfa dOhoiUkYgrIIs27nUrv95tutUeMmtWk4vZr0KwU2dOhwO+SIo2zkicfbCcefZLv02ZUBUEt7Vaza 6QB3WqzDEAAaVo+LfnGGFSK6xqfMtbyDhlqKb6DEJn5h+QftZ7FvZ3LqDCfXuMWP5SyWLLWcnt2s 8pU3OcUqzyrfet3yh+9D2OEWnz3fkguWWLSkvePkqt790PKH7W0Vo5+0cG6+5XTpbJufftHi8xYB bgAedT2WsxK/y4taHrtOdECrxGPVCuOHE7KrAIxgFTZTWLieiH088WMngkj/992ylfb+B+8zuBbZ 66gPvvp6sgMtcYLi2jQwtctA4CYAkx2WuAUBw4zpM9zOjOWspL/x+tvM+N/YpM8m2eq1a+yzSRhJ szA0e/Yc9Iyvo99ahiXARDdIJD6vWM6qJPR/+cWXDODFThcpesRJKs+X/vmyfTtlqn0z5RubN3ee G/QS3b7AkmDIkL04z3GjXXfdHxwtEhFleCtDZ4GB+rSA1du86dn3c9WDAF66SuUnUJBeUbo9DV6V S2K9uBI/uLVQJNCRmKaBqrS25batAwz6KUV2Y0p5LFmy1E1AAhbRITd16rcARjkWGLMdI/AFdb1w wUIHxuKoBC5SXYgmAb/aRYAvTlyg9uQTY2zBogUujsILZGcSZui+Qx3nJTWCQEhgqglEqgKVTdyX 2sU7AbDAWGCk8gpUtQtHE45O3VE9axLz9aW+oTIpDdGj+he4ycmAWvmJbhlsK1+J5BKVNbmIQxTA i15NntpDrjT+HU6Ty3YNoT2E3DXqThvz95tsOLq0F9iNc/89D9m+yPYB4GzNRG7cuM4effgRjpqP I9o+bMeuS9rCHNju9s3tzNPPtFW3PWBvb1xlfY841O4adZ/jlrILlN0hs/0feOBeTp74k51WlW9T o3wrY0BfO3CfYdYSjuzoY08gaECx74S1s2rarrzsUmvWsrm9/9F4q5g6zQ6ryLMxhXEbedrJttea KvvzU4/ZnmecZrfC/dV126Knbrh1FYEhdK/x7GzQIggGz9EB/TB0WmOJeQstd2A/SyxZZqnlqy13 9z4WnznDGv/xWkusXmnlDzzO6ItZDmJsYtocvu/BQsdaFk2YPaN9uljqu5WWXrPBQu1aWRr9aGrV Wos0a2xp9K4pWL3orjtbcipiSplWZxH7+Ht5SRP7tJAv+XEuoY7I15a4ahaJUAHamlXLrbxskxtw vr58eTQcVZP/XrftVDXwt8ANPFzoLTy3Rc2W6WrArF+/gQEzZVsRtumv/lK3LrYZ+Ce8kBhfnyF0 zaStouC2T0MmEC2keNI5/ytO4mhpSaldf8P1JFOb9r+S5r8jrkRm6RvFTUqsFicuLlLG8/8u972G 0O5wATqFZgXxDhX8chDHmiB+BW5r8JN/NJoLe/629WzV3o4beQji84t21uZcW7t0lY1D7Dnvl2fZ i7f+HU6r0Vbgp/i1wKWnwE1B/3f/Iw/YfiywrIOOmU0K7GwONHjmqX/YdX/+axAowD93v2UaGIHC ri8Z84xdce75diVi5aSFq2w4+swXnn/eOp11jpXuM9iaFAWrbJksf/RFC7DB/l04AeqNDcdW/ckE YEd7fBu4hQsJnxQQ+7+v6W5sVr/tQcRcQIzVYAQ5i0/4lLDsqeQvZ7pYKI4V/8RJhGQGwSVnsaJM SMVNfLecv4Rh5k9M/Jy32osZLLCoK+eRlQxeJPvqE6HiASW6CN7W8SyXPdicD/GdH1duFJtfMMyc 2Q2FDD4Iha/eq5yZdOreB+lAKfUigVs0Ky3FEK+uVBUnSB1fOFW3WOOAT2H1LhDVXbgMPW4lR2EU N0ND0PQhx6GKnsBMSRyZnmqdT6fWJ7jblr/ebuud9697rZv29z07lawnFHrFYaXcQhU1k6Ff1eyN 2gOvoN5dZWaV0dPi6fZ519RTnbDPPvuCswgIQJj6pH3VBkrXtZ9PIOuanUeW9zZvfXh/9QH9s67Z TvlKypDILtATV64FGl3/3a5+BKuTSyHiqE4n1rppgtXY9eiv5LZVQdUQXc3gX/bme9aH4+h32X0A +reE7RuL2vSJn9iLS+fbISD6Zk5alt5mW86nv2L5Mrvuhj9Yw+XrrXM8ZO8Vpuzwg1jpmznXlsBu b5J5CS5o29pB6dONw4mWV26y2KKl9u3rb9lxx5xg04vgsFhh7b8xZg+88LTtOXS4NUEHVR89dRvI p1v36jqya0xAJBWz/AOGW+Orf2f5J59koQboxYAjNiJZ3uABFm3R0kWPLZrFokg3i7Zux9vNNWXg +FXuK+mH2BSGCrlnCgoBdh7kBHTuma6re1onFBIwEkMVoR/+jRHR85mQdBZ0GPDTd5gl6kpHme1c ZyRuUOfq/QIeLeUEfL4GBi8D76zBofD6+c7s28xfHT2EdwPYpeWtEANIVJpuohXB+q+wosPlHYCf 6PR5OJqhjVjOT5HcO0deJjyZiW68tnKeruwXnnb56V6/+lz2u+w4Pk1/3Vb8+tKUn3IL2tDdUMcq h8rFxTmVVTcqlxx/XaTMbR16ff6ix/8CepWP2op4/JRmVZW2maFTdZ4+9SCecvLOpxmkE7R39jv5 +zDyz3729eKv/r1/9jT6q09Xdoce9Pw1Ow8f7l+5bjkKMikF1eCq2fn0ZAVzE0fLI01ZXixec+RR honYKv+vv/7KlqPw74eO9NGHH0SXN8wKunexD/JSdjTntL/zanCK8H6stukD6t75CvHPKqx0QOdd +Gubj/5naCJszwGkg9H7NWB1bv4b71hLjrN/7a3XnE2bBo5r2UwCPr1Z2NxNQYfQL1JsX6G3WLxk sZ2PovxN1HfST5Zgi/j4M0+yANMacGDlYDsuCbD7X12wVO4eIbQYUXD0ocwYnKW3N0cpnXSsNf7L 763h5RdaTq8eVnjkSMvr19uKzjrT8gHEvEF9rckdcMV//r1F2rW2Rn+91pre/EdDBuC0afFxrAqq YVwmus20kjgy9WSxWfgJGnyYGBxVFWNJK/IN0c3m5QpE+RYy4nUErjDbKQ157drabFDHsA3sgJ1n +4jt2SFsg7gvZr7o0ixsu+OnT6HWdYpff+fE35EaxClgUWZgu5CN6BK1to2CUhDCOjYmv458YpVP isr5tPxVfsrDJaUHXOem0Ak9SlP+PXcKWb82+j6KqkCpbk2ni1jnj6s//JSXy0P1mXnW1b/3Vx8u O4zu5bLfBT7f/9dlp/rjn2QFka22qP0FbRNx4MXiFvXveGlmC5XQ06WcPP3Z9eb9lXDAYSsgJ+pE mRZJSzkH+Qbp+bhUR43LzqM2veC1zzM7jPerSSA7MTyzw/r8asJu58bH+zFxtpMc8lN9rk4H2LVv P2vRsZ3Nnr7AesGJvILievCeg+1nLAjUdUuXLrGb7rrVum3mYEnAZCXL7yuXrbBb/nqTncGCwNyV ZXZiGaYrGBSXb0ZBu8eeVoiyU65uoWajaL3sikts4fRpdsrmHBvLokejrp2xFbrMrv7D1Rx7n7K9 WWX+JydDPI7pw5ln/2ILcpTeBoyMtS0vza6V1hgDf5sTttUYNN94w1+czdPTKF5PxTymbNk6u/XO 21AMN7Nhw0dskY4exEXefstNLOJMtyIMqTdXVdvBrAoed/yJdcJq8GR6DnGqMbNJo3cTlxduXGwb H3nUis47jwWPJVb8xyssPg1TmhgAx6pYqGEDDk7Iw7TldLO2zS3chA3kzZtaijKkxd1lBolEWUGB cnE8D+UUyLjOgafDQgCzAYCXk8uhC5QP4xfLzwtZUSFHGkEPC/LOqY58p8pHOn742Fzr3xbRnK/h SQzLB1xyAaWh98TspP4RO6Bb2PYalbQVbmMC+apjQ5f7p6LXuGAwBXXBW9514Ij++46O2n5dEMWJ tmRTjl31Rtyenpy2swaG7by9QjbkTrY1rkEqILyjTTdbOA1YuZT9es88O6G/2d6jYjZvXdr+enCO lTSJ2LD7Y7bOfalVIK/QSkzpcdV/efk2ctcAfFSGWv+AZoUMInNxcX0Yld29DKK4NJV25ibz6odc XE2hL5axuijRxHPtAbQxIFVNG8i0Sm03bWXa7p6QsL8eErWXpoaoN5nKeDpEjGgO8vd9QUCnVF0J Kb/Oq2yBpufSIVEbVGK2qdrskUlJe2ma4mXTrn6hSiOm0sz0k5riucLjr1e1OSg7VYJrO11dvrzX vULKx8VwXhm/4EI+/j1BFCdzCdKnw/I+091ITpH+dacespVznTrLtwkD8RC2f30dilt/OlYzlPV/ +Mv12Mg9ZutY1UuwxK5VxRms8F7424utbMp024MV40+KOSIeihN8/axP3/525aVX2cfI0Yv4LseJ m6M2FXH4jF+eYc8+PcaWY98jQNQKz4pl37Fq95Sd85tf2VI4txPLovZNbtKWNi+2a6/6nfXapbcd AEh9k8uApg/0rEzaTaPusDFPjnaAlwB4qviA0Uz2B198+cU2ET3coVURW0Z46Z4idLQcFhcuvuhS a9Gpkz2fX237VYes0ZIVdsHlF3Fsz60Yci92uk+ZD6xaucJG3Xm73fvog7YJsX7VS2/aBx+OxTQi EGOzqoo2UiNmVqNBmcITTmG1dig7P+Zagl0mybmz+Tg7H0SaM9Oi7dpa1QQdk8VqLHqf5Lylllz8 nSVZNInmFfDRpuZOHFIH0D/XCZVZpu1ru4C6VdC19DL4F7ZmjRtao+IG1gATkDCTUSKEKEyLF/KJ 0VyxSUrKdXJ1Ng22kP32zbgd8XjMJi5IGR+/s3NeiNvRo+M2ZWXKTTigoiixxvnqjBokUKFeia++ w9K0UPpG6RnVX4O6cBGok8v2DdvI7mG74d2kHTWa76tQP3ccHrFW2IIG3zZWeE76wKyO6ghocyOK 4/0BgKYFMunJKjUcrp8AXIb6w4DVoAtcmu9Pp61JvhIDUCi8ypsPoOunKmiCWCPylaqrY/4WU7YC Jkq9L2ICcSfoZAZwQxSrbOvGkY8iib5akvTixzuRm8YI3tWjDMJTxgK+tURCObhrjg1oF7Fm0NRE /Z0J6dAeUevSXJk6fj9Dh+gJSlFDALQFkwgFwem1OPl7jsixS/dRXaStRzMsNE7NsyN6q80cIQpZ ++PW8YfyynY+CH7BK7Udd5lwysu3g/zlHbzytOhJ+QU/n3Pw7GnBV+m4xBQic+/ueA683NNP/VM/ B1hPaj8/8xcYMX9ur37yqR1anm8zqzlk9I/X28NP/MPat20LR1RlCxjcPZeusz7YC77DTNwsSRW4 SSoo+lEY2VbyHd4bb7/JVm2oskPY/rbw65l2w/RrrCHb1FpjPKuyLl+53MpWrLJBiNAcw2hj8xK2 olmx3fynv9jQYQF3dvJJp9mHE8bbi5hUHJLIt04rN9uN0PP4mH9YG2z3KgHAuSzxN1+1zk5B9ziN zhSlk0U2BxWXBNg6d+lq97EK/bvrrrGnPvmSBZaodVux2R6540574pmnrFuXLgBF1OYtWMACznd2 ZCW6s9wG9ma40k7Can3goMGOXrVSMGkE5VTHlK6u/MEnLW+3XlYxd4HFv5ltOR3b08kbW9lDT1oS kF975gWYtizkt5TwGqCqLFJDLZA7aHcLbeZILNkB8s8dbMAAcW0uFs9nldVW+jJcrXcSI97GVtKW BSuO6Vq6jsUUOL9Egq/awW2k0B/KBVxR0EETcBsfzAkSHLlz2Eqbh+yNGUlbWxF0Wn14qhgQuv84 DppomLbPF/HhpbeScFtpO2TnqF20D18j5cv3C9aG7Pr34vb1d8FEoIGQzxrO0M4Rm7gwbTeN59w4 zidcwC6fPdpCM0Trq3d56CVvPjTH2jQN2ewVKbvm7ZTNJ61Lh4btuN3gYCFt2cak3TEhbW/NClaz VSPZ40BphZz+0uyU3SJ21u5hQC5sXyxO2g3vJ23JBrNf7QUQw8nGQM8OiNETZiXt6reTcEMcITY4 YqcSpxp1y3p2/QhifvlCiAX6tF23P9xlV45pYhJ45duU3T6B0xwTwTCvrfeg/n7c3wAiAl1oyCYu Qg0BV9uuUcg+Pd/suSlpu/hVmSyFrIS6KYfOtsUh+91wDLyp11ETPUdu1qNFyM7cg91ATATPT03a p4vdFBEAIYA4uCRkh/UM2Y1jU/a7dxJwzAm786ioDW6ftlfgKouZLE7tH0KdELHpTHqjv1K9IGmV hm1Ypwhtlrbd20Xtq6UJG8O+hDjmNe0xqTyjf9SKAOk5a1L0gbQ9OIm2pz3PHhC2eWtT1o92rmLn 1z2fJpjMwnYmddyQBn0GLvbjRdQyfUuT0S8HsA2WLruYLz2++G3SZqwK8R3wtJ3aL2xNi0I2dXna XpiSslWsh6i+/rV6BxO211BCXs8NNsFm6Ibrb7Czz/25PTN/kR2QKrBTNpot5Iy9jZNnWiMGz0EM +k20yCsYOFchJrbGtk5DkrZwLhrNsdPP/DmcU2u7Hg7yVfSEw1L5dhIDaOXs72z9zMVuQh3A0U2c J2tLc1L2zzDnfXUptTuvvNaGjtifdJRY2hqjG7v84svtfLjEFzGK3pftcMduTNjiL6bZRptuOVT+ fuTeIJxv4/PjtgAD7n02q8ICLtAp9Umpe4+edtetd9rV115jL4/9wPYCBE+sDNuKBStt6YJlbhmi O+JnCeA5D53JuGjMDoAbvuoqjLE5ZDVwmSGoGZfBF2hUMDidOpnfpzwDnFaE3d8Ut6AR/0YHgPLR 9tXreMfg3zCdq2hTODoD3+jcfO/jlsAeLr5uPb5wIYAbATKu5sZ7uGvaDXxSIijNYcOHDbO15ett 1aIF1qV1gS1bzab6CsAVrijYsUJYBRYRckpW9/hpAKmmAkYxGERKszFFnreaDlgesnMAi48Bwafo xNcfELH5DI6bxiXshgOi9scD2QkEl1ft1rjEUcF5wnUt4MPzvkNMXYZt2zJlqn4WcVucV9Oxv16R sGuHYciLKHztO0lbzAB6clLaFgNeNx0ahXtJAYCoDYiq2PpgPDwj1MrxnWa+jdyDQXPzIRF7c2ba Rn0St3uPhAOmAL/6J6cPNwnZ/l1D9lcAccWmkAO9l6albMaatAMVlePV6Qm7ZG/tjUUXR/on94va rwaH7dLX6I/FYcCQBb2VCcJpAcFl63L/qX+CakezRxuq5tUQUltoDLrJz/mplKiV2Rl1ZG9UOZvD 1n0ntpM2TNgvno8zKYVt9EmoPQikaeGEXcN24lNJm7CAmtHMQMqNC4IV5klLgsl24fqQHQ+HL70i Q8auHha18/eOMGGanT5Q3LnZNQCl9MDXH5RD20stwkQxMMeqkLReADRvPChqx/WL2MxVKWvWIGJF SAIvTZVUwwQJSG/C7rYSmheuTds/EbXvPzbHmsBFr2M94Ge92AEyBoljkTH5RW0oIDuX/jW0O31l PeOwjLanTGhubBkT0h4dIzaJPicAVIn+VRdM7XVScSwnfh78/OvuO7Of8L5HrP/+B9gLRSl7CWBZ A5qHUKqv4sPkbzVI2RvMTLvtvY9TuicRcVTvDYoCHV/AyqbtwIMOtidGj7HDTj7V3m6cY2PyYjad 2aO8MMfKGSnTqZwxpD2xeZEdd+aZ6PeeyICf2lGNSQch3T3YrXE/9PTuvau9E6my58h/GeJeCvG2 EiD+BG7l0fxKa8Pui8G9+9r08g02XWYlnLbiZEEKJvpat21nd98xyi665FL7Zie+fpYfsxmUKy+K Po4V1DVU/rO5MfumZaFd9JuL0SliLI2ht68nXz/qo1pkUMNoESTSqp0Vn/sbKzj8OAthqxgpKaUz aylfhzAIKJOW03sXi7btaDkc24UCEF/Yf7i0KrjbxFxOQSYxrRzDFhKPwcYvlaZzObDL5OxGIPf0 YA0dObacW98+ve3KSy7AEHagralIWstmhVbSmuO8IloMUciAUlcJVIRAWL/AX6Mo8AmGHVRDzFIm vevfTdjNY+O2EXVI24YhOBVzs/bKjSnr1iIMlxayAR0Q4RqoewX5OKZViKU0me0Dp7zkEEfx3wRL 9uf3E3bb2BRgl2ZA613KxjOAN7OTsgMc0Wq2VxYiDsvpVG+1gb53LJqVvK50O+vbloGIuLduc8pa wTmsYSCNgAMtRoRMIup/+V2EgZ20P7xdbes42KMl5WjRgAmTtJ+fnLJbxiXtn1OVPoBBugd0QzLZ xPZG+oJ0dcpreJdM+XwxlP1PcOqDmv5UVtVPMDnxLLMg/fPtqxB45yIKvwLwDr67ykZ9FLcD4UrZ nGWnAELN4b4OeyRmIx/mEFzSOm8QfYLqCpKgjlRngF3AACh1bA3iYacLbMnYPbpP2B75DKC5C+sI OMsTSLMBdRajzAkq9uKX47b/gwlbQ50Npz7ZqGV7lsL0fJu2Pe+O2VNfSQGUVo+FVno5Rbr9w7gN vLPKjn4i7sT5nekjx3E/4v5qx83+ejDG+oDqQV2j9uLUlJ3yTMKG3xe3MV8n0Eenbbd2YXvgs6Sd /GTSDn4wbl9lJk31m3/V1csB1gW+7Ey679yDPbaP2fhxH9g/X3mJ8/fmWLmzQM+3gR1L7MRjj7c5 szm6+5OPrRmtNZfKbsd2HedoCa8f62P3mCcAAEAASURBVFTa2W5ApNVRQ9KnfYWdn2x/ktRYM3SO +zF4Dzv4cOsFQKigHmzEKQSdJUiyLws0Dz02msMR3nLnEy5El7gOemT426lla/vl0GF25NHH2PRv p9lkOCKx5W3Y8hXBFEROHULpC6R12MIBBxzEtp5X7TOs2letWunCFDcqtmN67WrHIsLv3KOX84MI 4gZ01dSXBmM6OG9PQFVw+MEWQ9cXKSy2nF168kH2llYFXUmMmqOdulp8/TKL7tLNkuxPzunbExu/ uYAk5wJ+t5TV6EILl7bnpGiMogH0SGlH7he4vb0RdpjE5y90x2aFpDvin+sK5O86OrQJCpeiRmhR 0MDO+fmprHC3tCefft7CrGJ3btXQZtHhAscgyPQjDUQNRTn3bRMBlXtHL3Y3pM+tdplQjKCTE16c XQixugersK0YRDF0vi8BHlqBDhw2pIyIargA6Q4DMw/ah1Xl3i1DcCj0CtoBjYnDWprYkaFBJ0B6 8qRca8le7plwaM2RLlYCgqInUAcyMDNFCVQA1C+r5vn0bBkF9W4VsQ5NUm7QrN7MBAKdoj+OuiEX TkWAkiBj/VOa0vepbO5eZVblQFsuVVHMn8El4sjgcBCBZ6zU6rzn2DJEKOqPdS4LjQ0BVUCJS4K8 1V9TOs7MOQFYAGjz4NDK0FvPhiNTW8nOszWcbSPq6+FjmOBILEY0hCneMR2zz10A6zh+3qkO5JQb 86IrZyMYj7z8FJNDyom94hJPBgCbUPeKV43aYs4aNjSsTyFZKE/0wogIWoycswZRmUlq0QaZbeVR ZXzbhiw0WUxdkUaNovxSiPCOr7WbDua0c7xyWerOYVNDjEZ8bir65745dkQvTo5mwr5xbNomLEzZ u3NY8IIrPW/PiM1aDUf6dty+qQFBleKnu60A0A9mmXhUsrBRXFxkSxcvYVvMY85ERE0hzBiJCctt iI7VGBjroIPCQrZj5XIEO1uI7hg1ytpTWc2q4pbbaScbtu8wRAkqhsJqQSRNB9X2GeXVb7c93K+i YjPbd8qdvzagZ5ujuFk+02AqKt1iixI3hBvTThD9yso2un2P4XDEcWm+PLvDLeq3tdsyrS7dutmF 3S5l5qITsIKtjiRw1N7KLVwmmk/fvYNGHTrqRi89L4y2PDllhlWvBuB6D7QwwFNw0FCrfu8Ty+nf y/Ja72fJpYBsnDrBvjLvEDbhd2htSUT6NLtF1PHzuh2oArNlDq4PHWIYExlQ0CKcClL12pu8KiQc nEIGrDSgVVXiuBqzr1ggHqHRDuEQ1p47d7bHRz9lk6fOpHzBBOAak7CO5ux6JREtRKg03glU5efo 0T23GniLEE03oc+dit7uj+9XW5/WHEEGw7oKrisYBZwcDPh9tCiN7idiF7ICqY78l5FRa80CSN/b ZfMoYNJJNmpdBjWJCz+bw5UN7hCyc1+K28vohF46nT29GfDWoQ8NAdQecBSL1rMziMZqhojXvZnZ HMTmJMDwCYP4ro9TiLwc4LE05eiSeUmYdyo2GOgAT34St9Yj2p/UP2wt0GUesYvKEfS2qexuHNJZ 4nTS5q9L2D6lEXRUSiPTEUjrJzvodk2gBGpudK+HQNR3la6X8qKRg3ODgolISCJv1TmqdbsOLhqV L+DEM1y6OF6mBcKEbD3Cj9psUPuQvTyNY8Kah+2pU6L2yWKzO+F6k5iFqU2UX0c47hi60HK6niYG /QujPhGgqo8JwKoZz1I59IdL0+TXg/SSKo+A3JHLRKPO6FzIcdsJZtEb0QMv4fDqgpyErYdm6YDF kT+A7lCLYNIF/3Gk2eB7AOEnYrYTageGj40+gQWcIRE77VmHRKTq085k8SMvtR9GVzuKYKiOMMBm w9m9++57bAT/pTXFFOMTPiv5zRefYYuXa1PzQeuXnrNzzzjbRqAP0569tUvWsgn7PbvrvlEo3ats JPq4N6MJO+aEk9i3uN4uOP8iTqd41Fnq6/BInVRxz6h7rA0LKAK/1xnMXbp24RSK328BfirPFiDz PQUsLs6c2Pw94b7vtazxpWf0zoOw50TlX5cuNUXQFRm6cIKpdeUWHdIP8BxCT+SbszPncxx+ieUO 4GzDFk0sxKThxBGOwg9hshIuYPscRt3xr6ZZGJOY+JLvLGdEB05xpgdG6RUhONsclPBzFlocblGi tEAiTOeha0KPOqbA0M31tnrlBuvIgtBydowsYJ9x55LOdjki8UuvvslWsa+JSZIimsHvxFLd1zjX 3TPdS52DH//FqQUDkwvPRGWApOyhz5N20dCIHbdrnuUCSvd9lLAvlkIPwTX8ROffPohbl6ZmN6Af FJCuhyu4+DUM5hEtoyCeBo3EPweB3MNcIPKm7d15KbvzZ3l21dAUYqphJiNxnPMO4QxkmnPf0TmI XymU42kb0sXsgeNybMSDMXscmqTPOmeg2KCQXfNGwmbDqWhgqiwBVQIRlqxIbwV5XYe+S4suUvhL Z7UTYKDDIx76FNGva569eDq7dRjwqytTbpHnW0xT1OZbVB3J/xCn/pPdn7aMA4dLJeXS3nmMo2A6 oGaolzy4vBzKQwuwKi4uWZxU2l4D0H7BIsIFe0cdZzgS0L8aM6NFqCYkEakRPmUx6N1ZEcqYa7tg 7iT7y14tw3YjbbNgPQtbvL9kn6h1bh6xo3qG7a3ZCdtQiRk+6Rcgegv45PJy9RyGG0/a2zPIF/3o l7/R2X2Y86P7V/1KrVGoOJplMjX0IW155XBAbF9UVIv5sBO62KvfTMBxpu3pk/Js8aaULUX90YlJ bOJCsz6t+Fb1z3Js3MIUVgMs0lDW+esyRPykWhf1ta6GA3SdjgQjmnpJv7y8jM3ti91m8Aq4vMsu /S32dxfaqtUb7URMXMav2mg33vJ3e+DRhzmzqxhuaYNt3LTeuqSiNoKZdDxfOMvp38/OASRvv+tu Tk752N5+6x04vKi7XvybSzgF5B27+pqrXB6xqhgboXdzYFpL3o+/ywYq38HqAtWPSdWn5+P4tOrr uK5Z3EgAjNK5VvGSDjPYm72/mAp9y+nPdOaU9vdy0GpO756AYpklqONIq+YWWzzJkvGY5XbvxsnW HJC6FHMYVhAq3xvnwLHghMMt9gmHNkz6whlSGwsaXo8XtF3A0ehefV1mFdVw5h9xEnWfLp2tYXEh J10vsCYNC9mPfaq9/MrLcPYsOvEvACmVUANSKZjdNT5pT3yZhoNwibmOf9P4hD38RciZx8ThDI4f zR5v7O/08m8fMLBmp7D1AxzK0/bZEkYbUZW2B82FzPhHjk6gH6Qj0/OmIb5JpFL80eQ1dj6mToi3 khJOfyphq+FeKlkz+cVzCdurhINS4V42w+XINlH8zNg5CTvwgTScAYeywoGO+Vqrhik3MKtYtb3k NQ4A+DplrTm+bQEc4TesIMrdOzGFropDYREL17IAdywcxhxEStExZnLC3pkTsQqsBO4/CtEbroOu aStQ2B/xaAx9FLtpYJ6nLBcnqLrR0A7qyD18zx/ff1w8h8TbioDagDIIgKYCst6Jk36bBaDZcNDK eQHi6BuzAiCduChtZz+TtHP3Cew1J1Cf8wE11xCagXASU89+PmbSuw3rwsIV5b72zZi9PJP+Q9Ar mSSuHm7Wqw26UDjcG8dqsYR81oTstRmOt3F95APm37nQIFC6DAB7azZSCZOvVpl/weJJGC5vU3XS Xp/JyS6AmpzK/sV3STvzadp0cI4d3CNtH89Lwr1Lb5u29+ZylmgPABnQe4aV3lvHcRQbcbSIM6CD JJZAR3z/pwA6/vWNQZfRj/hTcxhCASu0WtXRZvJxH35oYz8Yy/ljd9mxnDX3OadyXHjBhbZk4Ty7 CgNkw1ZtMKu3aSfSJtkjjL0bfSA3Ajyjf5uMuNaIs+2uY6W0cdMW6PIOcwcbtmvfljPEDrdb+PB2 p06dOCqn3A792SHBZ/HGTbCTTz3RzjjzdOzUpJSodXVBqPbN9u9+arztpbq9NNdv5hilkXyZ/qNp tHY+g59dI2jKAkhRA+pOHUq8R+CP+p/uFXTwoKtqaMMhOT8JOuzDRu8Y6dzB4p9NtjhG3ExROK0M kyaR3KCi9waroTyjYlC+rd562pb32tkmc4htSUlH696Vo5XWrrYo+i+dI/fPV19TZAdS4r7E0kmw FYAmpeyTc+9FmacyyN1l7AIQhH8SYQMXgILupa/S0f/mTG64QmMAFpmgAfGO/iC7IB+SI2wmH0eX /LOdctySAr2t9eM9D8EAEV16I5ftDyUECjBI6Qdhbj0sFwNhFmQAxkEdQ3YtNot3YnwcpC2aatNT qWspq71TTvU5Heelw1yvuOIKQF5c3bada1Ne5yE+qsfEnRgrjpsegxiaRG8p0VbcaYQwrJs5WjSB SfRV/6nMZKG60FtJCS5UhtQCuEiJqzE1kWK7+nCyBJNM2KktXFCATWKz+kUCwNNUK47Z6U+pjoMw mdJq9EyA+urhmCsxQY24P85EGXCo0uv73qFslJtWnWXTKUD3da83ss+UBYKMBYIS6Spzn6CAVajW 5K/RBCm1Qbj9sW6//faDS3UEIcvTUXWrCpGT+NerV087+aSTXKPJr0uXTvZY67Z293132tvjx1s+ G/ibUwhgj/gpNtinLLdbW74BepydceqZnLnWxB0TNGzYUM7ZO9Tee/99bNFigN5hiLrX2Ftvvm2b OLanoCCf45NmYkg9C06yrAYAPdj4ziAavs/5OAoXdPCgo39fvOz32Wlk++ve01JvGDoQ0ijdTF2E RgcAwhxvHzRxABPSEQoEImnEV4mr/HMB5Kuems6YvCgzFzHf4jNm85vBI7Ms1nCuC6qzBgRxVVx1 I3wcyEjRzDMgUtKuDVxfA453ettmzZ5rhx60Hx0XWM30SNf+riPpj5x2LKucSkrpBWQEe4eJRDuL fr0XYCrvAPzwCCIpEW4VQGG5J0XHWTow09vgffCOB+XDOxdHdCldFxY/7oPM5O9eZcrJEgf1p6jK R8AdOHmIpkwexHekZAZ/QCthSda1oW5EKk5pPf4FnzXYyMonnfrGD7GLnCtuI0hR9e4SVljdKCqR lNcPcTobT9+4lX5ZTuV1dVxPZOdP+lVulAeqBnH8ru3YDx/El+5MPz0LuEQTbetAQiFUJ5m6z5Tf lSVDd6VbPdIDdURUlUMpiboKpJRMrq4NBLD+rcLE3KKK/NLOrOjXe0ad7u6b5Sm74OUY3F+QrtQF Cq+4rn+KSjKTLWUA6oJ0P31iK5gBOBdDY0VF4j3LCRkXUKlx5hDYe//Eaw0H6OMPGbK3jRs31jWO zhDTYkVdl8J/2rSp9uFHH9nceXPcoYZNOBq/e/edbeSIA1lxbJuJgtzO3mHZ/0mnpllPDasi5CIK p7T65gYUAMoR9ppRGhTq2wRUmQYBYdVg1AD3ulFMuaAya5/kFYR3jZkJR2xeEMqlo2oMKlP+ftuN ax4aJKhohSYUFR+EDmIo1vZcQCcK5opNfBeYlevxU0gFnZ06nXoWztGfudez2k8d2ufrOqp8lb3P z4X3ZeCqZ5cc9wqqyFs4vSc2r2Uqs/nem6zz2Sc7Y+5YvNJeffk1ztpbB1d/lF1w4QUcef7MFrF3 PPzP1oAAT+NA4+q/ywW7Z7CEQ2UiAFbp6vbN/7wSOw6wLllCZ/3TQogayzk/0DSycDpVpHefvu7n PLb6o5k54HRyOT4rcLDD7KrwYKE8yILZRlyN2PqiTDDy0DjWHwEhzt3zV0/iKTx41FayKls/ARvz l4CF+yAv/PVc4y9wU1D8a9FHUd2jW35UWsF/hcyEd7c1f4IqIRAu4HbcHX80m5GY4/QCWh1/4ojW a8VhJnd1GcQPSqYAAXhxo+xxgsIgPDfuTjoRJeHALwikYM4hCbk4qiM0VfYZp0dPadPC9t97sDVl gjrqqKNt/IQP7Yknn7T5HJzqQrv0fELOa8ef/6EaUJv9t4Gf1BzqPWVVaX6qOJ7UH/9Du1Rdrjtr ESQzwKBeR6hv4dxg3cLnex4AGSpBw7fWBfceLIJ32SEyYWsutXFdqMxjBr4ydezjBy8DMjP3ZBzk lYkofdkWjrhZ5XKhMkFdC3LvU98iWuYhOy//PoxOVDUnIdWDtgMrQSIdQn1C2jkH4jxEEHelHdGz oB3BmPgslPAvCK2pIXir9Hyaeuc5WAK6oKLVh5Hoy1ICOwZi9uXkb2zpnLl2yMEHYcPYlQ/oDHPf zniG029cVMdZZxJxPjv+7KiBH14DbiKm57kx46Pp8X+JE0vmSPU0b2L1d/KXfNAcEIxJ8AcI/Lu6 6OnL6P39VQy+VLcdIvlWAFKs5146p2Kx/7xpyQBdysDWu+boL3JBh3UwQPNZeZNs1xYF7DrE40aE bQS3qSN78gi3CT0li48mfWgC9lGf0dQhhcnW6A4Wau9FylhYdDsEGjGwm5KfYE96GumwpNhHL2s5 7BDJQ49STnxMNq2C9ysADOlToihwxZHFsc0Lyq6nABlDjiPmmbTknN4pA5Q62r6sqsLmsmzpRHi0 xMpThxDkYHQtvjCPY/V10m0Y+44yTi3ewHmIjTl9pgHmMLlsuq/CHOi7VRugQV+Vk+KZ+BG+s0H9 hDElEDfdsBHfSOFdkpVSx6FvAdRqKRTI5RVWkJ9nTbEZjFA2ndDz2OOPwgEey66QfhxH3p5vW5Tw RbEvCC+w3eF21MBPrQH1OTl/DZ7+U/8GgB1Qp4NOYFiCwS0v3c2a+q3tt/c+zrq+SroKBp8AINiP yCOBMpjpOCh/H0irsspnRZiHQwoa2rD8BjYjGbc5rIa2xK8Nhq4dAaaVANlS5LWTWClNwTYvxpL8 mniZLWT721GtG9hyNlSXV6TsiHChNQUMegHGaZaqPsYwGPMgWw09vQHJ9oBO5Ky0zWcJf/2baXud z1m+n6hm0GMfFi6yERwtVQhQRFEuRgGk1egmluSyRawL6S3E1hH9JIdU2bPEGR3bADhCI1vh1mHH uI5lqCSrpWmANgBAienSh3IFiAJLenG6AJN2agB0sRjf2ZCJS7ti1jKiVsBe4YaNmliLZtgTUo/N mjRl//KlHLnVyMoXz+NzAPdbz9672cnHHmEJdK1FGPHe/fdb2Z9aZfnsbSouKMIQvYEVY4idzwku snEcMWyYtW3TynTorMsbA201qp98II/Piq6wlZjJDGzZzDa8/YZN4ZsOmzAyf+bppzgGfwPfbNnL jjnmWCstLalXx0shd7gdNfDDakCg4bBPf/Twn+80VgR++tBWVBKQyM6H08oFaKoBq/XY/bniEFCB /apVULSaErtHtzWHOy0oicspYe/ssfmNrRVcz/vVZbYRMOoWZvMzXF8TuKwP+T5FIbskzuIElzZw WeNDVXYtx2A1YPP6ud2K7bOFnCaNNf7hkSJMa/g6FfFiGH99C2jqIM75gGUPaG0Lsxg9NmEVC9gF wAb3JWyRmoKiv5KtXsM5BqoHdmH5aGM3s/DSgvzXAkyrYf/y2UjRhG08X7M3Kx8Q3ggNn3JoaTkm QGGJ/qxOrUOZoU1OOq5JHxNKMBFoZ4l2s+jq6gTTDu141L30fflwa6oZAaGMm8Vtxsi7gtNvNvH9 keIGhaYPBE2bO8sG7rabdezaxdqz62PKjKm2z5p9rFWzRta2tKsdfMA+dtfol0i7iHRkAI1JDECe QoSPJdfa+Ikf2/4cCtG8eRN3XFcC+qKRYKFK+cu1aNeefboz+fjNfBvJvuuCvEL7+NPPMTmodKvy C7E9PPnkE/jg93FBhB1/d9TA/9EaCMugnMPU3UAuR2dUBcfEQyBeUSke/PxAD3YbKDyDHbEMPAD2 0F8hFQ7IL7KLGzV31utvAnTVDOO+7GDoAKfWmAAfpDiCCpHu8lSRlTK238Fe8FLAp0fXHPtVr2J7 ZUalbcCW6HAWRBoBIr05jCCfZfHFSp/4iziNpR2cUW8ALXogXM/6iH34QsJmcSjgN6GELQe8OoSx 48LEhC/CAkKsKsPhxTnYgCMDOWwBC/Mm3K/Bgh0TCo4nsKkA6zR+QBtAkeuAq4p03GIQZZSAKCt6 vzXPn6QsYHTY5/7AZVIXeXBjOj4rF4CGQcUwFK0cIKgthQLRNCuzn3J8V0gcLcz34IF7WAKAfOfd sW5FeNHipTZk+P4YLnOcF+JwVSWfj+RYr0q4PV1jAPqSxUv4Uts4t/Ku7Xk6UVtfdxMXKLE5WFVP WZduO1uHti1tOl9yGzp8mO2790DoobHgqD/j86IzZ86u6fLZYoG+1Tt//nz3LYaaADtudtTAf2kN MIyxseFXwUCVDSDQ5sBGgyJ7YLh75wcqMOjd1iXYRxguBlbIDmQ3yHGcPzcxFbP34TSaACg90AG2 5lqOLdATsXIbyP7T4xKFlos4+xCnm1wdZ1dJnzwbwemPf/2kzPI4d+5EDg4QHT0k3gJEq2IJi8Fd zWY7UD757B6LWFWDmIWXh+yt12I2ns90VgBmcxG1pXvc3XKsmKX4BtBWBgIWwIluBAg5FMSSbGtq VsH3itnGJNwqQqE4ARm8HFFXHF8hO+grnf2TuF4ARSIwNOh7xhKHA6d64ZmCB4BD+aUbpCadwafC C0DZiaFlDXHSSepWABiBU1swd44tXbbcfRS89659rUXTxjZt+hRbyGGpq+EQwzkFdtRhB3M0FMAN sFVDTwU7OuIYmFfxNTidyDF/4XxA7EvKgEEpx47JvixJuEQ1bDEThV8gaVfS2drwFbmJE8bxbd69 bMTwYeAftgpMIF6loTK5yS0onPsE5MKFC90nKCsq2OcN+Krt9ZnFaew/1i/G5z83beJYGJw+xRhn 4tTqpj6+rWd9S/a/bbUzUz07Lv9lNRBNsbjguBwGkwaCBqwG/racU/DzUoaMIJ91Ksq3AXkNrBP6 vc9SlbYKbqoPO0K6wOXoVI6pcH2zEC/PThfaYM7mC+P3YKjSRkcr7dgOBfpkhl0zZ4P1gvs6mJNL KqFnbwClCFpWsXKyFBb1WzjFdQDMOZxoHGe53TZGbQmHMb5C2qWEXch1BYDUA66qOyJ4V7iwJYBO EwauTNbL4GpXcK7gTpxVFoVrnAdv2hrWlbNnoA/uSYUl/SYcobVwgz4SE6y8avEkQbrapiNgAZN1 QpFbWOHOLUyIOxRAaPuWwEn1CeQ5gAlhJJ4A9MPQEgPII5job+KToV9hnjJ8+BBr1ryN9d+1l730 zvt85/ZbO/jA/WzRgsXWh88E7D1wso2dNA1dYK47bVvifz6HTYQjSSlu7Wu+kdK+XVt21JRy8CkL IwJp8qlgz3HDRkVMOzJPYCLhGDCB9Zeff2q7A4IFRQ05Oedd6HSldrS7dqcMuurA1JYcTCvA08e+ l7IlrxffMJk7dx5hkRYwWl8MF6oPV/fv3999e1bV15gv/CmOPm6+fPlyvmk7zNl9+u+/KswOt6MG /tNqwHGAIkrDllEr9OPBPcmnxrnN1AxCjQK3+okodVBhI/tFQVPLhdsam6i05QzA3dBXDYLTEQfw alzcg9nFLEj05ePdFeR2SWqTjeZE5ROaF7B1ptrumrmJdzl2Agp/TuKxEQzcpoiQG9lgP5fl3mnR uC0EUE4MFfBRJk7m5SSQAkTae9JsFEXEXA98f0M+Ms7eBXG7HRxfLuWIVCUBuaith0OVHnATq7s9 oW0Viyvl6Dm7QdencH/zAHuBgU4S2YRidEMF+j9AWtwcKx1AiM6DE8Dhh7/AMZGMuY8wucJpuxvp J9gALlE0BaBqAkmhFFW6Asc4cWPab6T6A0g///wz/LQ6u9SG77+fteBbIV9P/pIv13H4J/q5GNzc yJH7uTPS1sJpVVYl2I8a40w2cZJMPnBcZXw64K2337FlcJP6DKlWoaXPEECvWLEu4PAoo9B9l767 W2nnzvYBH/juvUsPO/OMk60xR3zJefBzD+4P2seiImvXrh2AxsEM1In2hPfs2YNfTw6zbeXqoEeP Hu7D1/oGb9u27fh6V6X7AHfXrl05GajQla3GjrQ28R13O2rgP6oGIsccc8x1+qq9QE8cgwaEG9iO zAAI5ac7jd8Uf4rZxfFrFjqOCjWwCZyZPB3dViMG9kB0drsigk5iNfTpZIXty/NpOUVWBJdWDhj8 KbbRPgE8urOaOm7tZpvCRyf257ONxxYUm05O2hvepjG/1YiYX7HYsQTgmwhIHQ/49QXMprNq2wEu 6j1A5mV2jvQg/TmAz2JASQsf/TmKvycgsICFjdaIyjoxYz6IsBzurLhV2HZRGhxlBB9q7eAA74uV 2Uy4R7J2J480wBRlxcZgAUjAEYi0AYipDgSyAjStADseUfXiQFJVFojJ4hZVV4HJjEJJnEZHCCda yGqxMivD1GiXnn0AihwrKS21Vcv4XOfMeXynpMD69N6Zz45utM7dulv52uU2deYiuEg0lABcVCAn QIajI2ur4Mh87afu3r0rJjJwioisWg+JU09VmOM0KMJGiEmCP9YS4BKN48Z+aN279bBOnUvwD95x E7Q71zxo1D7tgoICdz5jcXGxA7//1955ANZVXOt6qVnVkqtsy03uNu427gXbFNMxmGoIvV1IAklI hbyQnlxIcu9NAwKk0BIwvbriBja44F4lWe62ipskS7LKed+/trZ0JAyPlnvfy/PYOmefvWdPXfPP WmvWrBFnp78jOL3o3LmzteW8kk5woKks7qgsvVjU0SHWOkNaonDXrl1dT9kKT+JBUF4Kap3/ztBQ x39Ork3qxU/m6bpairI+b32D8vvYbJRWk3zrKxfEr/95wotPEid88URxT3QvjB9+R8eJvg6ff9Zv tYRaVe0a3b6fLY84HJIGABhdnroODDLRgggP+ajlbxju2u9LbImOL87+zDm2+1ip7cnCw5ncz0Lc +zvmLO/DFd3YLM0uRp8lW7gdANKPqw/bhtpKVmQxP0Ghf4hBPAJOYzrmMmVwVhPwItMGzu84ALOI 1c8CgGsNQDcaN/vTEZ1z2AwYn4iXDqr/K7acZcOBynvcCoAwE9H1ktTmlo0KDGchrLzWWCdGZRFm JcUA5A72KI9tl2BJGBuuhFPrTT2OkM8fj5cBzAFwpSeysEK9C0qlEQ2INuTg1DQ+MXgzqFUEagAh ddEfjeNUL3AM3lFzSTTWXkYBaKBSSEpBNIULrkZHmgr33B9uTL3ZqWMHW4FIu3tvgU2YMMGK8OEn Dzt9e2Xb+nVrbT+ThfpaLokk2GohRoeTC9wOHznk3KlEYZnjVFG/FkwGhQWFvmiShglNCHTi3uQh ZhH7uDt16oxZTWMuUHUUyOlbB6hnZ2dbjx7dHdjk8iwJ28KsLPYWA3TiEvW+RFxxiy1atHDwlDgu AM3IyMDcJwQ/SiD6JITtqGu1jULTe9G/PQIfHxW36fth/OBb6Wti12fj4RI8b/gM09edIP9goEWg kdrCjfhrPGIxyYF7ND3XZMJXXb3EOHDtuSiBQPur38pX1fQrjxPUWTf1TlAyfTcNGtwE0DRCeupu JVafnr8b1iwsB8/r0wyeBeVsKK+nwKOgrKqDv+BZhR+quf4Fpf/w86AUYeyP+o5+j2tXq0Xf+6j3 PuK+N6L6kjQov1JSDcVwSEJr9EfTifXQWAzu87sujqwzgjEZ9K/USR8OnkGgQ2KsudcFHaw1HW5u KsD2DhzfUjuOiBljp8clW5/aBIyYj9vDNeVuA/hd4kgcFeczr7rC/gwostOXhYk424lSXTzXCMSk C5PS7RBxTgc4W9ER1QzoeXFVbsy8Hc5M5xDf0CzF8hBnOUHR2gKmf4BrK6UsbeHmViAWFlOhqYBn hAPOW2FLtwXHon1r2E/BQTgHERlxhWat0vF7xq6LXHSKarh2DO7njh9j1VjOJsmEvzRA9CiipppW cVwPqGd1IRwgalR5ExbhaJFGor5HEwZSFjW0HBrUALpKSNAXw8bxRN6LEBdVqXNzm7fgMSZyAeLl LjdOHti/j739zmp7a+4iO2P8qbZxw0YbNGiAXTh1su18/Dkrp66pnHuSQPqxiKXaqhg4l4Xjfv99 B6BRrCqnwlGrTO07tEZvt4PMY9HphUAUsbFjx/og0el70eFEAyH6+ee9PlH6uhe2a5h+9L3od6Kv FVfvRccN34/+1mCpzV9steXFeNSZpmnqQ6Eck6/CwkLr0qVLk2cBHRzf8KxVbZ9nMYktLHnknfhx xI0ZQVYJ6njRijeovvxaH0FO/lv3uRAl6Xfg3AEVCSvyNYdK7eji9ZZ+xhCLl2/IujoRjRCkIWsE lSRwgBo8CdKDlplglaiDVV1mfh1m5rlqEm4AOh/2StPj6KX6yEHifHoZuX9s6ftWvikH1QoLZ3qB 8nklxOLqvfB1Lrycfl8JUGLRu5oIWmzWPtOSBvbhWnl9tiDrk1qsKeI7ZlmsjtEl7+WbCuzRNzZ5 +3p/kLRbb3i/gCcsvqIR82JrM4FgUS86G8HYTU+F6YkuTkhk6ogInIp+awD3pwHuTGhhFexgeDhy 1Mrp/N4MwFEsdmTVxNnTgNI78F4j+f3VhFRE3uAAmifgdF7hDA58J+LbDP0a3IkKPgHu5kLE3gM0 zkV0bQrFAH+MUzBsD51VTEPtpAwPJgKQKL1ycWncjTLMB0znHS+3MegT9/KuQHIQol9v8s1m0aWY wrZB9JXDyAJqJs5zN0B0fms8snAa3E64TnxAwmWyglzFiipNoZ0S4naaw10WHcXhHOUL20FtEw7Q 8Fu6QD2XfqsGcT4gLhZISEN7pNXJ0pE6gIoTgArkSki/ZReYqCMqIY79+/fatpw8a5/Z2g7hF3AC xslLln1gi99ZbKefNgHv2uVWVFhsw0eOtkmA4WsMFIGvnExKXym+U4VVutJBLlmyxDpw7ogGcsB9 RuDeunI0aK6oEBG4rcfXW2PGjHWQ1HV0kG6xkDyjB0z0c7WB6p3JGcaqr44w0CqxxOa2bZU+Rtjc 0wKJ7klU1rcCryKuH2bBJqNR+0a3tUfko+k91VGONJSXOEyFME747TebflSWMoj/AyPVYxbfa6rl bN9jhzllTxysxHS1pxZ8Nm7E0w4FFHe7Z89eytzMdu3aaektMy27tBhwame1CXjeLisCAFUXTW51 o58v1U14EICP7nOtvmecKGqc4mgAE8fNp+g9wduht1bYgd+/ZBlTBvs70XVReSpY1U9OivZEXpc2 7REjyUM/STN8z8sVEHDwgE8vZh2YeiZhfMoTQKvfbfxBugLBg39+ygoffYS3U4kL3QMgom1dC6AF JSRX9xls2xRY654CNgq8UWYtp19unZ98WFxF8OCzfFKm41tyMX07iqd1STVsaigosWcWbHNsVnuo ZAI5OYetBpf6ZR20HQdT0Ldj3yzvNdRJ4Kcyyp1YW84jagSA4SAXkTuY00jTAaEvNUu3hXB9r9dg qkKn9gFWR7KJrAXbyR6uLrF1cINnY/JyI+BXQ4uLw3sE8FsKYEHutkdmEwI/wghE1SvTWrBwccym 4F1aZwrEsqiRC5e3nhVO9jXYspoKuyspxbpQiHmklYm4uxuxejYLLW3RH6ZQ2W0sOGh72Dm4w0/F 7KUL5VoNIPXAT04sYLacMkHifqB0Z1aFj3AiHNYv6A3jbROc4VbEcVnjsWRhqSjOxLCVs5IqglE7 hG3hhW7yoWda6Ah8sqGfc393Qbfr7FkO3vDFiFoIIAYVgTb4NaP+NUwCEfwoantbFW2yYuVKu+nG ay1nW671P6W/dc7KtPV5e2wJR3ROHj8E8ZZtceglzzrrDFuxbisiKLuMKV8l3CCWLCx+4B2aBZNY uAmZwixcuMQuufgid+Ev8VuA0at3N7jJbf5uBostQQhAX/UIB4/u5+Xl4/rsWnSL5Q504Qp33Uve JjIJuuZLV9t3vvMtu/fe79vcOXOtE0D3d852XrBggf32t79nlXin6yTHjx9vP/jBfQBxD2+vpUvf cxdrWrjJzs72VeOCggIbPHiQm9dom6AAU2J4cXGxL74IRN98800bMGCAl7VNm9ZuZqP7MslROro+ UajZtxL0gcjTe1gVDmdXrSuznl3bOcdXVsbEzES6gclFHLNAsE2btv4tm0/9VdYUWOcOIyx+7xK8 dWdYXKa4v7DN6IgYFuUw0n/wD/M5f+WwpTZPYocOUgAmWd+4fbItWJpre/cftfu+doat3bjfHntm md1100TrzTERCkcXr7W08YMsTrraJkFHmK5Ys8cy26RYi/Rk27H7sLUg/UQ4BR1Bm4o6Ihm1Tf7u ImvbRkdI6GwNzLiOYZJEGSPovROwmW3GnybtquNYD3BdVlZtaanNOB2QRTXosV/39uwyagQDXhIf /6SH7EI1sW3N6mTx6H1rUa3EMZlWYy8a35yDwbDwwPDXqlDfxLeCvrCCiADc0lNX792PcQX0jm47 lvJ+3hCHn1BNLGFQndOgF00qQeDoBY7AnTpoO05YBZJxOLSNswl99toLq7pRXyRDmCkBv7A4hbZs cInPTSn3NSBqSLAdVb8huYV1Y+X0kdpSywE0ZIc3KiHJJtQk+Ha2h2rxGs39G+JT2bkh9+7Y2DHl PQO4CXxwDmybWFWtkPzP9SmYUJyHqctquLgzqxMwimb/K5xEKfq9N9nmJq7mTYDzUg4EupBtZJtw xZvN830MulVAlWz9xmIKIru9jRWVNpQtac3w+tiPsuZoMQPnipmAdyGNVADgJGBEfUpGnCXD2O1H /G0PS9yWxYinEX8lOtMS/OlQFwiZ+CI6MEE39fGxIOiThPP4SkLv4ccPTq+GMsZCPdJNRGgbzZRu J8iVbAG1sKLFDHXOmtUfWPGhaW7oHEc7nznlNNuy/e82a+4c69+vpx0vxV0ybZ4J4Z07Zaw98coC 64D36EpMaryvyE//quCOYuC683fssDnz5tp55wTHFMhhKlGsd59u7ofuFPw7pqfL6w43RQakHR20 eJKXu91Kjpaw/S7dJxiVtxy7PrlFE/eqhaAH/v1BGzxosJWx53jfvgPUPcZ+B/A9+qdH4Vq0Qo6P H2jhhZkvuFH1s88+A3fagVXjPOcO16xe6w4ZiuEWFd7HODwTTuxN/EMqaMVZYT0HWSlfAVSXLl1t 9erVft2hQ3t79dXXPc6yZe/ZN795j183+qB/j6+faXHQcG3RVqtZNxNuahoHdGVbAfaWLZg4pTNd t269g73aQws84oI7d+5oBQcKsMvcb5HBUy2x+ziShjqhLRejqK94H7WfOLs4lMc79x22pa/tsLHD s21An3bWplW6zV6w2XLyi+x7d50BgB2yvz233K68cJgDYBWHdRxbk2sdf3BNo2KHP2RY37JFsq1Y u9vac2SCXMcVc8RCc86ZqYb+D3B2dsuWqT6Qt+RuQ5xLtYH9O1j+zmJ85wF20NixsiporprFNsCS wV58qIxtmSm2bmOZJQJ6CcTJ7tzqhACocoi29Cl8SWiXCViPsioO9Mq49DwrfuI5S+zW1WoAwgQm rIp1iKKiLdFJV5z3Ygp16O/P00rSxn0xQZyn6DkMzqioJ3wix8QNZmNKv922ZldbPIQLV8AHnMe+ sqaz9etwEI/iSZZf2NwXPFUuBSQqdar6NmAgxU9OS2huF7GrYwWg8zv0d+pkrT52AIz6MeiXYDo9 B32fjIS/k9jct7aVwmJuhitb1IyFDji2bZx0sg0wk9mG5PchGDhfhH4qF4C4gLN3u6IMK4NwDkLc r8dUWhvyXwpXNJYZ59aubBtjP3AsALYXbioXgHmaGbsj3B9JcSh7JSvRcTYI5wKtST8dTuhduL/J 6BLjUFbOomxpcGIVVH5YeoKVc/ZrMQXhzGgrpswLMJupYoaMYZAI8JKYSQ6j/wuNnZt2mBN6gIz1 oCERUFvjFAKRkQOg4CmrmRHFHcYB7gruzEADh/9uLuP2gIjklOUI4tjcOfPg2s63/PwdLICcZq/O WmAbc9jt8fZi+9KVF9hB9FMHmHVHI7bOXbwM/4s7nENKA4y0EOKOE6hTpYygIdZ1azfg/j7dJk06 zQ+q0iyvxYqu2R1t8ZJ3bczY0daKRZLoEBCQsTWvs/3bHbe5XvKdJUvZN3yUQcaBU5deYtvhDtes WeOcncTRe793HxxGM18MkanMU08944NRCx/XXX+NbVi/0RYuWIzN42p78omn7Fvf/iZtIocOzWzE yBEONm3btfVFlO3b890wXOXU/sxly5axqtzLxVQBZ2ZmW54XUZ9kON0S53bT05ujIx3oIBlysv5N xdzPYgUnNSVlWNL4b8CNI4gt+oVVFu0E8BIQkdAPc+xAS2wXBw0eiPMIdt2wMLcRp7xt2mQ60Meh cskCaJtBG85uaxiLBjRe6LtwHKahu7vva2fbWws22bLb/2q3XD3Gpp8XiLTqmxT2cCuuwCaNawGb QsmSNX6/+fCe9t7qnfbU88uta5dWdttVY2hT9pYTL40jYoeckmUdMtPhjBPsIACmya8zh90fZ8LW HC4uKDamm+ueNVmkc2hGKoyG5rYaJnyJrVKJ6HcFO4ni2aIkfkTpSyQXhxi0GxH4H9KC3nSQ1ye0 fnxTnh0pKGbvfoUdW406hjY7vhHbUCb5CGMvBiYmgnVIDHHL31ttEeLFMinX8FxSkALZWQ22ohJX aw4eZuLgmwmzWlwlZlkRGJ4Y6qlmFuD6Qh/liw/VHhpEGjhhoFL+i/gCNJng7j2YBtDBkSKdJrJz TNhVVsGxvUdT2OWG+AtzJA4w6EF0hGFaUt6n0lB3prSyzjTsM1WllgfiVrP7IEJH9INwh7PYMD9S YStxHtASwJMpTAkdy7nMNg+x9VAmq7ZJcfa33GO2CS7PFxjIrg8NIW5yM+9NBvx6IwIeROxlvcNm c3ZIKxpuHfFbsEhyz+Rkq+XcgFrOKqhG7C6BXX+Z83yPAZTpcHxFfJcDcue3Tbc2xRj68s56GrkN bSzvL7kA5maIuSdA2hzwa4EuYB8mgzCAmNhgg8fKci6zYtBkagYZGGN3iPmLo1TdzBC2i75FFNFB P4PFD3EBalTmJrH8EgeorwBBcQSSHtRpegeKFUclExkNCJVpxcrldvHF09z0ZcCA/jZ+1FDbun2X vbd8pV0+/QKTdx7pvQoPl9llF51pv/jtkwATi020X7JAkH863lFgjGRMvrX2HhyVVmZ798Y8hkFR ViYD5bY2oH8vW7x4iU2ZfJo7WAjrFHKCGXia+fGPf4Qer9jOPecCDrMqsu5tM+3Xv36AUwGfwXvM ++jDMHuh/LuwYdSkKVFR9T3uf5yZcepQu//+H2DruMIBVyvWObm5ntVVV11FWcocNNWm+tOg1feu XbscqAV4Q4YM8rNhxo/HjyHecsSVKQ/p7g4fPuJgJZ2j8h88eDDtH7RvMGjJShMbqpvk0+5jJMk5 GVg4+X5LB5CHDx0I17ofnWgmpkDdERvJnz5RUB0kRgpAO3fu5LpAqRfUeU4D9LN0YA3wp7eCoAUp CsKEH6Tld6mXYnsB+FJfheO3dMl6S+7X1Spp8+/e/rSNG5Ftb8zd6KqTr9822cXW1+dtoh0QV+nv li1SbGsuJwVSt749MVTnqLYUxmUJIrikjcF9O9ikcb2sTUupOVQGz9lz5YMAIAAuKkV9gXTbf+sN 6ff4p8biW2WFsoPYAFzylEmWMqi/FfzHf1mXP/0KUGputQKvwoO2565vWDrWC63vvt3PCK+FkSl+ 7Bk78syz9SkpVYXq/QVw5tuCc2+OllnSII6DZTvo8W2YgeEspIwJM45+jm/fziJHS63ZKb0sfvSw 4OUTfHq/gFs1MD+9Mossg11i2+DyBH5eT9pL36VwhGf232kvf9Db66aaqarwVkGH9WVL1f2pIioW LG691uJO6QOEmF1/91dtSut21q3kuL1YdtBmHyuxTnhLuQvTl/2ASSvO4lvFvt82/Y7bzReNtVkJ XWwTRE6JHMGnn3uu/ftXv2qrjh60dpzZNwg+6QjLD/F06hy2x1VC3HuxZ9txpMzuPDfB2rbHnfbK MqtCD3Wga5a9TyGyzp5q44YOsSpmj+2lRy0TvVhGUYV1wmTlOIi+C1DsyQEyMXB281F8d+nSzQ4h gvTlWTWGz4UQdiL9rtlAdoiHASs1nJTgAiItUlQg/obEwMUJQ8gJikgEOHrfFyEQT3StNDUoFYL7 zH5cC5QktgS7SoLZUC6+JDIXYvKyZt1G19tpAWLq1DOtPdvjDh0ustdnL8BEprPr5I5DbEOHj6Ud eiB6HqLd2IpHmuVwfuUOvORJOyhf6f4WLVoMqHIKEQVIwcu2bASzsjpZn55d4MwWuB7NC1r/oYER BIGaB25J1PYFHspKRRxsWsPlqZ7iclVv1UP1FJjlbMuxV15+lb9XMAaXnrSm3hzmjTfeZKvdfE9D uj6Z1uj5YbzVSG8o4J01azb6xH94ugJDcaBadJG5jQyss7I6uJmNuEW9L1BUcGBRIeoGfxx6qxjA T781mOO4Hj9hkh/10LNXb9Lo5uCnN7z81EeLHzr+USqLZKQLgV/QW0pY9VffeiZ67f8YBCk6ECqe iVCcX8AQ8D59V/r+ZmsxYYDlbi/G/OmQFR08xuRw3N5dkQ/IyflGrPXqkWmZrdOse5c2lpGexO82 NmEkB1yx+yoTr0Xt+RN32LlDS0sGKBVUV/1vCHVlb7hxgiuVTXDXEJdiezLhokc8Ho0SsrNZgU22 OLwZ7f3O9233zXfavm9/3yJgQ9m8d23XbXdYZX4+z+6zktfeoP2CMinVoEhM1l06uW4wvmtni4MD l+OQeETm+E4d2RXGKYpw+zFtW8NVMr4YqzUlZeBI0AtNC6401SUquY7q3HO4uW0vbEG/aizyDM5T ddIKsI6BXbKtk0t9YT1FM/FJpHAJK1xnpWVg3lJpi8pL7ZlpF1on9DBPP/qo3XHLrXb/S6/awcmj DVti67d6g90z5UzbAWFlbcixowP6Ws+ixba7sMDuf/eI6RCq0yZOtJbodPZymNIPv/ltW/vuYusw cIBd13OA7VuyyNqPGG3b01taee56m9i9py3Elu3rdOKYnjl2eCYrpdePtk3LFln/66+yLdoJsQn9 AuXsOm6MZbViBe+dd2zQhMnWAz3V8sULAcMj1qZrD4sdd6odmPeGzbjjdisvPmjdf/9frD5jQkNF JfSVsDq0AjCshmPkUoyCpSASVAFgge9D3WzazA2/QwBsuEN0WjoEPjV6oFLQPYkeAhKuxRUAFPrT AoY4jURARh1XwfW8+fM5s/cW28YsOHbsSBs5fJDt2DfX5qPPO2vyONcxaf/tltxdduVl0zGO/rUd LD6CSI1tJLrDNAzS4zl+UEEKb5HEdkRq7RS5dPolDkzJqUlWwnkrvXGSUIb4ou1qWpxQ2QMOMHhf aajsCsE5IA11lK5PnNitt93C4fFvwOWtZHElGSBKsZ7de8B5vmf7UHzfduu/ORBLVJZIfP7553l6 et63bz/7wx8egttLg+s+6pzWSERi7TbRBLBlyxZ3HvHAAw8iniXY17/+NTfxUQINZfXkon5TB3+u 9g+4lppDOVa9bRYK+8FwHM9ZTHPE2ZQ2Ful+hsXkzbWE4bdY1cYXrXrXUkue+ku/rtoxnxXGzhxX 2tKaDbmegb3XKubfb4kTv2XxbfqRX5DvR32qfNFBixT7i0ps2ap8gG27e0xKxm98zfb9VgNHnzZ+ gHPvmph7dWtjp8PBpdJP6j9qa4P7dQQrMQdjj3olO6MSxMGRB0Ks+AsHyiomfi2SyFD+AKuiRRyr mkEa0senkVcJmw20E6lFhgAdekNU1UScyqEnmje1kJiSEk8eAivKryog1QgcgtqIFiQmK2tBOlSr McQEXc1ClaSBGPSJNbWVmACwI6sUtdeufVYL9xaLdYZ6RmkF1AX0MMlk3HAZ52Qx2ZCexobE5kjP rsE7SDsx1CWCjh8kU2HCl7luHKRrDx6KhnW4U7xN6r7LFm3uiEpLnj5VcunIY2xIjwMc4ZlkB46k wPRQGT3kK34QiwpLWXHVau5h52TQk6FvmTTxNBvcs7ftgT3diz3aHTffbK2p1JFuS6zvTTfY4Uf/ Yh2+easNPjXLnn6rp91x97121Yxu1hGinXHVlegEKiGcyax8VlrP0mo7477vs0hRyUpZM0u57ho7 +PZ8m4CSN2H8BPsmytTerfdYwVsHLC9+prU8tb91OW8CzkGLcFhQaQOHj7CUbsWW0qePcwIH22XZ iKuuQPfXzArbtLLIb35niWkpduT0CXbNwN6cdM8KMrqv6kunsSULs53Z861rbKLlsVCyBT2lZjf1 isSJVMTfMkCSqhPUKgr+I7is+wxAghgQkWZncVrRBC8CEUemoPtEAXhwZkrn0p+INhwCA7cbW4Ho ywKPXFj5Qglx1675wHLz98D5pfngv+TiC+09RIHtuwrsb089a1++7TrO9t1hO7fnWLtRo+yqaefa 7/4yE9VUPKJRUr09IiwZbSxRHCU4ALuaxYbm6F3PPfdsypJoGS3Qz8AJDhoynFIGIOcFpr4BuGjg MSikowG8Ssux30SdoLjSI0lPVoHTVy1C/OjHP7TLLr2C1Vp0FXDa3//Bvfbww3+yl5ksxdWpDdsj xjzw4C9s/Phxnr7Ar3XrVhzWXsCxq9K7HbMZM670+OKoxbFK96cVbZnSiMsT4H5UCPtEbR/2nGY1 Lf7Ulh+26t3LNMWj6MKIe9SX7djz1zBhJFtNwXq2SiJKr/4r4k6xVeXMQZRD/ExB/zf6y1Yx6x6r 7TgKs4vXrObobqte+3eLn/LDjyqG31f7uc4qKtYtM0bZhi17bfrNj1PAiF176Qjrh/ha/NArltij A5xPOzYRxLLA1d9en48UABd35QVDHKi0HXL1hl3QA7pldj9pgq5k5bYElVT79s3tWAniOpN3Gffk ULdfr0x7Z/l269a1FZxsoi1djv0e4JbKbiPp/lIAnnARTt0jwCgqLGPfeJINH9zRTumVRck1eQjk VNxgItE9/YvQDxGM6GsZV7Fw5V3/9hfArpQngmPoXS9B7xCOdFfcD6QI3Y7VyjDfogl9xyKR6L5C 8B1MYLFtBf6KQY5pstFQ4DO48F+NP/SMNGlDrWBoTL61trud1ncfR7NiylSc6iZIk0/ZY7PWdfYV 4jh2mCk50YxC/E7MS/6B375kgEv2aTCcFoMbpn3ocGp797D8bVutW78+lvb+cis9UGjV2Z1szey5 NvPVv9j3bn/NXnl/k63YhcKZQHsjajDrbd1i+3DZ1HfqVDvKyt/wnQUW6XXISl950Q7B/R1F3Fn2 wK+s7ZQpmLrMtKFtT7PC3863koETLG30SEuCoziEePPuntX2ATqySWPGWZtOnSxv61bLRxF/PgMp snmb7czNtWxEIgQ9S0Q/UQR7nsFJdBvhfrJ25FllPmIV5i/NmNF0bOcWAPAQbLUIVQSbhiidhCK2 8BizzUe3sqrm8fWOQjDA/TLqQ3rA8LnMTAQmIh3iMyjlW5AeYmEHDy8oexNxzCqCrHIRtsze4+D5 m6+fYTt37WarWm8bjefmvF1vwVUtQx93lmV3yAQQktwLzFlnnWFv0b7b9mKWxMytmV22lFqEkdhW C3hp94mAbAGicDuAaMSIU+EkicPgkL5SJjUKzjFRr3AxTPe0wCDg0qpy69a4N8Nc5Pzzz2d7HDZV DIRhw4f51reZzz/L6vJGB3otSPzpTw/ZFVdcxkLDWtLIsDPPPMMBLcxn4sTxbnen3SniDKXblMmL CHcyekm1r8osUVSnp0nk1fMwhIAX/g6/g/tqe7V2AOJBy/OL27WYY0Uqj3Ih7gmxHRui4yv/jGmG uI0Eq2SFOL5VF0TTSpT80DL0UrN/NWc2v2txWXCQOfOt2fCbLSajc5hlk++IjTu1m81+6lY44XY8 C+hg/Kge9trfbrNteaycpqeys6etu4rbhf6v+YRBcEE6D8fsl9+7wFau3eXUMvCUDtzBlo2JeVA/ rgH2CzNeAAAdzklEQVQiAaNW+mvRu0vPnAyoleOwVwsaEptLAcFOHTJsyvg+1q410gALI+kT+zjd SScpbk/piN5Ee6IDHYG7jcOFmwOeXbJkKK8JUe1XV3oAMvjFDdRdJW/Ms2Nvv2sx+NLccfktFgeN eEzSpeNESE5LtUgZ4m6FiAGY8gxFW5BW2CvKJTrU58TNhuvwnfpbzrkEYKpnKrEWM6WzFaBLHq6i LBv2pHCqXYIN7Fhk2/Zn2Pu5rdnkIKZF/RLUS8yHJJR4MN1d1R+FCGuYyScxQ3Zg1vzZXx+zNfnb 7cF777NxrAC1/+qdiASltvOl1y19ck8b2hl9xeIVVp7W2taswt6KUIlomcXKVxb6lxIWLNqi5c9k wB0o3GfZyPs1X7nL5j/2sJ2Nbm8bA/UgBbjnciwFmeQ3F7J8rs7t39eat8xg/y77WVmFnHbmVGsF gORsybHuo4dbvx49becfH7dmE8faBso+CbBmX4TFD+jDyG1ue2S+UFRgSWPHWBWiffyBw5ayeo1V IY6uhkPTBBXHjCRbKWiMT+wDKwPOLQQDr8wn/AgHpQavBrL0ZbqnawFlACzMT+hL3bU96VaxUl7F CrlEikr2TWt2Xb78PTjnK/DmvBcxtbtNxhj6xddmY79Ybs+98LJ94ys3Y8ulTq6xbfkH7LoZ0+07 P/sjM3umSwrHAPFadr8kwxWKsy1n1kdLB+1E7IUXXmJ1s7V169YtEFnqyhrqK8M6hFXW7ymnTwl/ +re4vmuumdHo3qhRI01/0eG88841/TUNah85U1A455xzmj52MIy+mZ2dHf3Tr5VG07I2RNLgEoEH ISYRu712Qy22VU+r3T7fyhf93GK6jLPYziMs5ugejJoP+CJJhEW/qjVPi4m1aonNi39u8a17M2tV IgbPsIRTplnV6qcBxHWW8FEACAi0apliY0b08MyDcgblkJ5Of2GoQX+uOjQfHZj66H4SJirjRnYP olBHVUM16dAuI7h3gs9wIR91GSF4IY2dDaANf5hOZYbmTnreNCj1GOveUS/rWn/QqPLmfj0EUU4l p0kjItFWHB8TVFVuPlr8hjeDlte7iss/ibBMIkqnWtIS3GuEXRy1SEBK/7MEido1rBvEMgmHQSqG rpgIqT3FgWosq8jVtahlmBzyDjN5g/3l9E9WG4GwR/LXtejbihXzmBf/8ffIjTNmWCfY0lNhYQsR ofI7YBC6e6/1gTv5Sf/htmXfbuvSozs7LRjQ8butAjOL3yzcZMeSMEUYOBB/duswUzhs3VFWX5qB G3aUkIcOl9r3U9tbNbqpY4eKbS899m47Vo2Z2Zuxsjg3b7v96quZNnwzALkh1daWH7FKzBx0uvwc 8s8vLsDTyV6b3LU7s1a5rS8qtCGZ7Wxai0wr3rzFjnPaWTniwPnVeEtGZH+4ZYJ16tnTilhlmkpH DenWhTQqrBAASQIUNVF91Y7aBhZxpDuQPktg0Tqtme3DJkuAVX9SW9CXYTt/4m+Bn0RPzSzBIgH7 leGI5WlaxtJxMlmA40iGu01LxXyI2besotSqZULAhPCVu+6x8SPxEdgWN/pQ9j33fMveXrbW0/re d75rHTLkFj/NjyOdccWl9suf/9zWbNmFTV4v272vmM5Ow0CWfCSuSgUgURi2vAa946BB/ezWW2/h /XSvawh+J6pcMBAgVVETIfyt6/CerqNDMOiD+B91PzrOJ7lWOtHxotNteh10GZ/892I7kDBMxRGz G0lKsxiMmRVimFydO2Gi13sxTNy+XxvQY9ayCJxhLJNlhElTE5jrRJEeIqhRXNTzVE70UVcKT7QO kMV11L8E3VGOarbAxbfAUNeBgniUNWhX4vq7QdqqQl0XUAa1bTDAuevXuuecTx2oOAD4k+AjfDeM 3/BNTKUX/CdyGILMycXLUZUH0DF22AtHBHHPcF0qq771rqeh3xpP3KxLzy/5kNGy7sezbzyWHU9S A33mQF6SbOI55iEWCUG5VrJwWYb5msolFUOEQnmdnVPknpePPOEM3ZRPvz0Q18tK/JcAwD/ceJP1 xqffKsSzVcdKYY+r7XQ27t+AHVV+pAr7uXgO+2EDf1f0g4h5f8B/H5ZuJBVwTkqzNWLSJEBUas+9 rFj+KCbd9/IWJevAoVibU43+CI6tJWYHcwDHn36luZ2P+LbjP2NscTKcH3Z7hSxd56Dze67sqOYc S8ZcpgcAcgyO5iiVOpd9x+2wbcpixpyPuDIt0swGVCXamtRae4DN6qdCrKmIFXexEf84osEWzF/K AICOpL0yrtK+XXmY5XCInKCOEfgJtAqOVOhO3Z+efrog4g0HqgBQYKqg63AFNRaxS6KHZjKtSEq8 y4BjBabsOFxsNSA1jG1vv/nlL+wg5idDhw2yRfPn2vd+8oAVcwD92NET7f5777btuZzDXHYE84dq G4Te5jv/62d+eHYMZkpJtH9zFOCJDOxqALAc/a1WNdXtUjifPuU0u/ZLXwKE1Xcnw8kWONkC8e0Y Hkmg6GuVB20nwKehO5VdHZezhWU9YhrYYhsQ0+Iz8V93FE/Oe0EVDw3gp/WjwcxyLeAeVwMwX49h pQWPLhvg/srZnbGCmXUXA7AHA2/ewSM2dQLbU9pFLOeXOFVgqbq6iq1urCLJ7dPzgF8CgHKQmbK9 jHSYiWWmksJCRWsUmFUAYQ67P8BVS+Pe4YRymwl7nshOksMA9XCgs5oy7AYgCmWbxQpQCUV9L/aY laDEjQ46NrKsXMD3+YLAT0Hf0Ur7UFeo1dQYfCDG474rjgkgFgW3AEn6Lillj1Ne6WfWfbDKVq3d yPYenLbm5Fk/RMY+LBDNX7aSvb6LWNQ4i10rGDazYv/esnk2ZGB/O2vSSHvoydesGaJB84wqHC+k I/pL1EAMBgC14qedGTLFeGvWHPfnN3LkqHrOwgse9RHWJeAewhkz/BbnAJiGP+vfU/3Dm9HXihBM DppgGnOPYZvVJ9LoeTihBOkGcRXzxPmHaQTl8zyZnKWgD4LKFuYfxgkmBudrxDE4S1CXT9S1c1m0 pRZW9DSoZUN56jKonwAbFdBfaHjL48IRBoxIwK3wq77lgnLzGSYfNqnnHOakOoVpBhHDT3Finr+i +rsNE3PQnnqg+gftUp+8Z6hf+lNqQfqBDo+4/jNsNx7XlbguC3+sfOv7N3id+9zj2nV0dff09mcJ YVph3s6BOnfNHREFfe1xIM5aGjhYmlGLqJQAAGPwRCHmnbnzIj/9xc9xYCIYYzGBiNl0dgUlr+Sd JKSIgwBRJrs2cnSwBoOWLNy+Kcw4hUzTAalKCiKzmizS4VwjbPSCDtCxmCpSIgU7RFr9uiAKFnHo 0FG2H8Fda8Fabq4YqbafNILN/DrPg2dwdBJNaxDnMkgjnnLB1/g7GeCb7KzyKE8ynFUs77aj7Inc Y2sx7hnUMCxO8beHMhyhwUiqPsixgFh6teMXFurSD4Ek7DDlKwLRQArs5uAEqRvN5hyjiiCgap/V 0VrLPop/2vmgLVn79hUgwbGThV0K7TJbYUaD/R/mSklsK0TlygryTiQ3zCQQryVyex1JV2XQ/ZAw RMkp7Mns2Kmzt/GH69wwYAKqV4y6CkVFDuvm+UTd//Dlh98N4lAiKhz2c8PgVHy1RPT3h1M90R2V RYtbalsloToHQWkpfLZ0g3fFFmgAheUK7jb+DNL3ctRl7e3+ofYLyxWUSMWSmC1R1m0qScDbl6w0 eKPbJjrtD+etO4qv9HStfMK667dCmPeJ7je9F7zR+DN4P5B4gidhWfWrcQqUhX/BvcZPGqd54l9K V2oaSVP1wBqdiSrqfaK+UVAeQZ2D8oV11TPFCcvQEE/xY1hdwhBeCsK6wHvSkPhg5VaYjRY4BRgh joadG2TDigpxw2e6VnphmuF9xdVBQbLLcZJi8PoqHRH1LTld1nEeuOertXWJ6AtMCx/5txYylEuw 4E58GkVgGVa37lWPK6EvLIdTiDegP/IPJzZPTykGbzYMouCe19mpsOG9D13xqhNFXar8qouiNMPr 4FZDPNJ3qhUHGRhpK4aeuxgNIehN6RbDd0LdlN6TmN3Q6ZTSgV4EqHLro64+pKf3Q85Uj6KDnoXp BOVpqEv07/A6+t1Pex3m9Unea6hzUI+PeieIF7TzZyljmE+Y/qdJI3xX74TXSufj0lC88Hl4Hf39 UeWIjhO+H8YNn4W/v8hviktoKHPTtE/0/LOUR+8EQQxD41w+aXphvPC7cSoNv2Di6nNruHvy6mQL nGyBky3w/0EL1DNF/104qHyi8wqxXtyVsyz/w43etHxNixNd9qbP/lV+h3UMv/8Z9fpnpv3PKO/H pfnPrMuJ0j7RvY8r3//Esy+qjF9UOh/VBg6AyiRkpXWy1w4MYLVpXfs65TgyD2PmMMhPm/ZuNg3b t2/Hur+xl+GmcfRb+YR5+e+6SC52NmF36x597NeatbiMx23RJw1lHMIeHXJycu2ll16y1157zXcf RJdPddIRj9EhuuzR96OvtYvh2WefxWXTq/6+djisXLnC2+2JJ55gn+4S122o3HIwoCBXT8pPfTFv 3jyTb76//e1J96+nZxs3brTnnnvOxdf169fbzJnPu0gsB55vvvkW73HYE44T5s6di1MELYIEYR9b 3l599TV766233P9eeP9E3+p7mR6FdQy/o+Pq3GB5UP68IUxbtDRr1qyPFMvDfLZt20abNNBheD/6 Oycnxz3WRN/7NNfyQvPUU0+5EfaneS+si96Rj0KdsSN1hfrpqaeeYcdLhbdr6O5L9LBgwQKPo3ek kli+fLnTxLp16xqNo+i0wwW28J5oRfn9TwXRmeoWHcJ+CssY/ezTXqv95OhX2wE1plasWPGpkpBq z9/HzvajQtz9hOjCiiDnzZ2PMj3eHn3scbfc37Fzl29KVwfksvtCTiS1Q0A7A3bu3FGf9u5du9nP us29Esu7h/ZySimvIIIQsNJn3sHaQqU42tCuTfA6TGfr1m1up1aEzZ+IQgNNZ0vsIl3tDFB+2qK1 gl0qOoNCbpT++PuH2Nge7GmVSyl5+FVeKofek5PNYxwyvnYNzifZFvbd793rnn91PoaCVvnWAqLx rM727NnDy6y8VVeBn7ZtffDBB56mwEQ7E5SutmkJTAUYqoP0cAqaMB579HH3i7c9bztxd9Iend3T 8Msvv8J5u6vZ77oZjydD7G0OKPrJT35q119/nf3xjw9xDOUy9uf2tJtuusX36T6FBxYdLpSFU4Al S94h/gIrZTvi66+9buvWb6AsrQDL+faXvzxh1113rb326hv27rvv4kD1LC+LPuQvrwQD9r59+/oW KYGuzhsRYApwdbaH6qnJSye8LVy40NtMu0HkNUXb31S/EBjz8/O9TeSEIFhwYYGK9tJ9tYEmSC28 CLBlc1hYWMT9WAeDRLYAKo/a2gj3C7xvH330Merwtu8YURryyiyXV2vWrKYcbb3flZ72Ec+ePduf q09XcYaK+kj0oYGiPlf7qa8CTy6Jrj/V2carVn3gO0+2MaEL5LULRsAhulMdtUVR6Tz55NOep55r O9natetII87fWQP9yCmD2k90qjYT/ck5g44OzcnJdZp8jDEzf74Orq9wn4Vbtmz1tBcuXMSE9gTG 5Ff75KWxMGbMGO8nKfufffY5ynMQYFxo2dnd3D1Y4P0maK/i4iKnEdGtXIqpvirDww8/4rQoZxEC Vo0B0Wg4pnVP2w7F0AgwN2NDK9A6jpmU7ETVrwUFhZ6maFftI+sEjT0dFyDaUVwBs9pEeSpvPZfj illvzbbu3bq7tYHaU3VXHdSP6iflp/4MnVaIzgT2rfD8IgcY8nakA7g2bdrs+9M1oYs2tUvo5Zdf deZLTjQ03kUrMqYX3QuHDrBAqOt1a9dTj32YlaX77iXhinYizZ//NmPjr5yweLaXX/UOyxEOEHeI GjaWbsrNUDzgp8GuSugMWFVEg1XxWrdu4YXVRna5b9rKtrdR7E9VZVQ57eNcS4HUYKrEgAGn+CAT YIgrkt86xdPg0cDRATrvvPOOA4KA6Mwzz/SN9qNHjyavljZ9+qX205/8jP3JxTZu3Dj33VbATo8j OEl4+cVXbR/OLeWG/ZFHHvY0tCVLHXnvvd/3jrr99tt9MG4EMIaPONU33YtwBUAKykMOONW56iyV TeXSIFADi+AEFOqkykodCF7qjd+hQxZp5dOg7HAhvkJPDLE1UHXcZXZXPB7T8TLW3rFjFwD2rhPb TTfd6FvFDgMEmwAJEe7KlasYoC3tGdwHHeZEuPj4eC+PbPh0BGeHjh3slqE3WRHgImcKLdjud/a5 UwHXXXbhhRcC9jlO1M/jgLSlPMlA9GFHa3BpUtP2N7mSWrlypQ9WHXCkQTh8+HDqvZkBcgxj6UEO 7nPmzHVXWjk5eQyGiMfR7Ks20l5d9bXqrKMxxRGqD5988iloJ9OB+owzTrc5c+bg2Waqe3O+eNo0 mwV4DRs2zJbD8Y6ibwW81157jYOHzhSWY1JxzNpKp34QUAo8X3rpZe8D5as4DzzwAHubz3UaUZ9w qBcg8DD7k7P8WE45UTV7zu7Gi5HCozj02Lo1x04/fTID6hWnu/HQ0atMInKDJXvMrtld7Gtfu9sH 9emnT3GuXBKBwEQTkNr4oT8+bOeed64Dp7xHawVbNPwl7CpFtwL8yy67FOP1b9iDD/7auXB5srni ikt9LF1wwQXu6EGgLY49OzvbaU3toHDZZZfZHXd82a6++mqXRgQwGrga6JpANd40FgX2AmNN9AJ3 TSZqe4GMJn2NhWnTLvIxMHjwIB+rcoG2Z4/Od+5vS7ju2DHLt9YJKAWKAnX1YT4TkOp7ww3Xkc8G JtOlno/AU3TTo0cP69YNh6+M+1mz5jg9yPnFs/94zvr060PfrrC05qneTz//+S9I53p75ZVXnR7l Iq0rXl/+9KdHnf4OFR92TjkR34XToI9HHnnEQVj755uTxo9+9EPGXR701ttB9bTTJtnePfucYbjl lpvxGPR3aDACXpzunoeO0j5Xs1NpNrQrOl6xYqXTk7BL9CwPQ1deeZnXU+2tegvP2EbaWO7UgNFs uPz9lRDNFG8UsboaVOIKNLMJpORvTmAXcHBFTjwiyD44LBC3psGitDSYRSh6pncEEAIUcQpTJk+2 l1540ffDrnh/uZ0z9WycZz7pooC8jYgbEphUkb8cfKpz8+E4v/3tb3maavTRY0Y78QmwbrzxRh84 GpQClosuusgH9/vLl3MIeeBuXSA1kN0r0UH1a8aemSPsYxR3K8LXTBSUP849mOisDZVfTkHVPhI3 xeFqcKiRVV8F7XEtJv8YuJ64hHgnXs3YIiKlp0E96605tnDBIs7r2Gwt01vYm6+/gZPS1jby1FPZ 9VKBZ98BcHpwKpSpS6cupJ3k3IT66syzzqSOB2mLYk9P+YnD2rp1K4M51TmYF198sb566mi1v7gz nYeRChcsDkYz/ZVXXumTlABUM6aAcujQoe6iXpzjKbhEE/CIqxRRqY4amPPmve2r1Uo37Ge5rJeI LmBQ311++RX2D4gU4yR77tnn7TqAYi5OKWqwzdRz9YMmKg28Xr16OjctWpG4L4D9yle+7Jymyqm+ VVxtsevbt58PzAsuuJC6NPdZXnaNKofEpMWLF3tdBdB79ux20Lnzztu93YfiUk0c29q16+xsaG0i XosuvOgCOLt27oS1HU44Bcbi+tUWU6ee5ROL6pyIW/ecnFxv6xkzrvJJ86KLLnROVOAiGhB3NG/O PLYmxgNeU5kcDnm+Um5rQlL/KW0Bierz+uuv1/eTHEcMHNgfsG/HpNzapkyZ4sAqDlwcnIK4H01+ AVdX6m0mILyIOqxYsdxpQExHSYnGZbAVTj4hNebUNvLQPXnSJJ+YdwOmixcu9h1J2YCxuDnVQxyh RMdBgKfAVu0gSefiiy92mhHdFRcf8muBZS/2rUtE1f0j4EEFNq3nn3ue9e3dx1U9GueiLTFUAlr9 3X333UhIFQ62Kq8mYB3WJSC8/PJLHQjXrAk4zjGM7779+joHOGr0CMB3gPexmJM2bXTw1zbrAS2d AijnQzeiVzEZGsMa/2p3qZku5qiIcAtmCH5qUxeBdREd1AAq6OnM5Pn52+mMSV5IzWhqcOmZxAar w8RFqJE0EJWZuJJu3bq7vqZHj+4+SJW2QEMstcRYcR3y8qtBJQ7u0kunY5BcbldcebmtBmBuvfUW BzIRpAZDZrv2rsMSuPbu3ZNZ/XG4iaE+EKT3ufrqGT6o5Uopn1lMQCnRRdybCLozILKK/cpyy1RS UurPhwwZrGJ5EIGLsDQXaOCIWxVBp6WlOkecl5fraYmIVG7VUXVXXBGzCFKgq7bRnxo4L2+7A6SA W+BfgN+/CRMmmljyvtSjH3uexb6fc945tnGTPIGkeHuHs2+vPr1dnNt3YL+DszgqDR4Bhrg1cc0a iCqjnA9oUlqF+LebQT8dF1gqh4IIRWAjEXjp0qWehvpCe3vVj+L4NakJpMUJS6RW+40ZM8rBXnWb zEQl/ZhAVESvftA74iLFMUs0FEir7a+99kuex8033+Sz8O233+Yzue47lwSBy7WX6jFnzmzn3ORX MBRJBUrqt2eeedqPCBXXp7jyFD1z5nMOSKr3k08+6TR1FZ6HZs6c6fUdPHggXOkpTnOaJMSZabIT vUyZMhmwnE/fmE08bQLbBgXezRxs5B1Z3I5UB+p7cVviPF555RXaN9iyqPIpfdFvp04dqUOF56l+ E3Dv2rXbJ8M///lxnMXu8TILEKXfVH+0ROQT8Io7Xrz4HZ/ExDEK7BQ05jTWxFVLelqzZjUT1BU+ 7tT2EyaMp99xIMpkIDpfuXKFc7xiJt57b6ldcsklTEo1TocTJ07wOKJV9Y04VjmmkBRw/oXnuRci SUqZmW3cI7YmINGyuCylLw5TXOIetsP27NWDSXGIc2jDhg3368cee9wnHIH82rWr2bU0zDkyAfyw YYPhYF91gLvhxuu9zwVUffv2gd7mOEA99NAj1Gesn4kjulF5JV2JFkXPkpo2MSaGDz8VjBjo0kSr VrgzjsXFV1qKc7KiawVN4itXrnSx+jwkA7Xd2rVrkPAGQ0PPePtecsnF9vjjj3kdhTmNmD4Gqwc6 ILyUXWAEgPPf4TeEHgHo/BmDPQL3x4l3NREGZQQOyuPrt+LpG+SPAHh4xq7w50pM96P/dA+RwNPU t4LSUtBvXdMwkRdeeDFy4403R1588SV/prRVRuWlP10rH5UpzFPvVeE9IEwXnWN9GSFMTyf8UB2j yxX+Dt+F8DwdfSuvwsJC/63n+q1yNk2T2dTjKQ+lrfIpINpxHZRL7yqozPpTPAXFVRlUH9VVaStv wMjj6RkchMcN664flZXH6aPgvj/kQ3H1p6Byhv2l9wB0r4faKuxbJgjyPOjxlZ/KoKBrlUPv6U/v qJwqt4Luhe0V5hf+BvA8jvJnZw/xqj1u2K6Kr3RUdvRSXl7lp1BSUuJ9rDi61p+C6q8yKIgGdK32 UzxdK+2wT8K6KZ7yUVnRa3kZ8K7i7bJo0ULeOeZpqHyzZs2J3Hbbv0Uee+zPHk9piJ6UtuoVfuta f3B7/m7QT+rjoA/DeoRtpvIyeVCPUl02CmofBZWR80n8WumE5ddzznX2+uqe6ltefoy8g/5S24le dF/lCPtB32H/6FvPg7+A7nUviCN6qfF2A9AjN998ayQvL8/LoXqE6aifjh0L6Fnl0/vqD7W34ohm 1NYKKof6TG2ka6I6fekd1VPtqGvVTe/qT+3P4kV9veAqvT3VZ0F8jadK8jzq+f7mN/8Zuf76GyNI Mp5PODY01tTWCmov5dc0uB0gNxujomNr+CFDlcZicvjk835/fL4NqdMJcBrHXJ8oMfL/5vBJ6xTW 4dPGD9/7uO8vOs3Pl57oR0E0dCITdX/43/wRTdPR1ypG8FtcPmDiIpc4vC8qfL62bFqKpmVv+vyT /D5xGoAV9T/oKpywTT5Jal9MnOgyRV+HqTfcY1KCy8S7Nosk0jGeODTE1/PoPsBBA1pUQiO2UDdO hpMtcLIFTrbAv3gLsLvtn8Pd/Yu328nqnWyBky3wL9AC8VL4aqU1GghPYuK/QM+erMLJFjjZAvUt oMUv4Zq+FSQGa8ElfsOGTfa73/3WV/gCEBRHWBfLo578ONkCJ1vgZAv8v90CIQAGtdDhXsexEBhg /xsQtqzoBXQh8wAAAABJRU5ErkJggg== --001a114122f00ddd3e053168d111-- From nobody Wed Apr 27 01:24:44 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C8912D61C for ; Wed, 27 Apr 2016 01:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2-LT3LhUwIy for ; Wed, 27 Apr 2016 01:24:41 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A32612D619 for ; Wed, 27 Apr 2016 01:24:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3R8Od62005120 for ; Wed, 27 Apr 2016 10:24:39 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 11946207637 for ; Wed, 27 Apr 2016 10:26:18 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F3B31207647 for ; Wed, 27 Apr 2016 10:26:17 +0200 (CEST) Received: from [132.166.84.250] ([132.166.84.250]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3R8OdJa022359 for ; Wed, 27 Apr 2016 10:24:39 +0200 To: its@ietf.org References: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> <8385.1461611347@obiwan.sandelman.ca> From: Alexandre Petrescu Message-ID: <57207746.1010904@gmail.com> Date: Wed, 27 Apr 2016 10:24:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <8385.1461611347@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 08:24:43 -0000 Le 25/04/2016 21:09, Michael Richardson a crit : > > Russ Housley wrote: > > Carlos and I had a telephone conversation with our Area Director for > > this group, Suresh Krishnan. The result of the discussion was some > > pretty clear and pragmatic suggestions about the charter. > > > The suggestion is that the ITS WG have only two deliverables in the > > initial charter. Once these two documents are delivered to the IESG, > > then the group can recharter to tackle other things. > > This charter sounds reasonable to me. > Do we have enough participation from non-IETF ITS-types to actually get this > done? (I mean, other than Alex P) Hi, This is Alex P. I would like to mention something here. Some IETFers may tell they'd like to reply to this email but woudlnt because of that. Once you're subscribed to this list you're an ITSer. Once you're subscribed to an IETF list you're an IETFer. That makes for the question itself to be non-answerable... Is this what's intended? BTW, what's a 'type'? Alex > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Wed Apr 27 01:45:52 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0336E12D630 for ; Wed, 27 Apr 2016 01:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnGiqiltYgaQ for ; Wed, 27 Apr 2016 01:45:50 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C47812D0BD for ; Wed, 27 Apr 2016 01:45:50 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id u10so66404442igr.1 for ; Wed, 27 Apr 2016 01:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=3Suy+0f7GxealhkRz6bJMhCC0k/Nwm8zte8ZsaEy/Ws=; b=pPO8naraY/bAmJmseKHqszpoVGtQZAy9fcrlXhRILrYZ6s/cMWt7rGbw7QKk8Td50Z Kv/QEDoBLVXF1CIRXys0r29f+v8FDVDGh8eTIOE9lSh6Xa/n4ktv4PlTmL1R3UrSrz0/ L1AQBtEz9UlF9mCyam03Us+0l1bytEY8AtWwwZJHItE17PaD282cf0mFaFELreBhwysQ VIF46Y0kUGhrhOV/FJp3+Jtu+GHpnfJ5/weSlfXICNI3ASkeZtSzSwoikwpjJFbpNtf4 TwnL39QzEWWG8gUERE1wfJ/bjZrOS9Zv78BGJi+G8hvjHAO5yWZjIaOfJXSxT2N1/yBS Rspg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3Suy+0f7GxealhkRz6bJMhCC0k/Nwm8zte8ZsaEy/Ws=; b=L2rnLyFa5ZGXzLmR5gCUaX24Po3ZTkE8VYaLndc4e3RPOZ/p2hOYJAJpnTLzFb+uou lHP5r42NKR6PS/OkYbI/wqetnUPGrLYuJD+eezNfjfX6D90Cf42ZE3NCr526krYb1vq4 OvVmHsjwBSubMyedqbhWDa+pMJjX2BQuHjJYpJKF0IdFSiwNOV9febcGU3OOUNOljp7q 5Y1FBA4jh1mBBsGn504B3B5XuIEmfwmjW/4KfkS2XyYIgFiPk/hh3T5f5/6brxaJd0mQ j9MzJ3+cULTlHqY159pA0SXrL0OUnIuOC6Kkk7K4nBcccmUSczkkxES2rZM098TglhM8 lChg== X-Gm-Message-State: AOPr4FXbjGSOV28BnTyagv/7o2gdxTawLtqLX6tKq2KFqMKKag/bz1+mxwjfSdU05lRmIaXXgoaj62cuRTbsKQ== MIME-Version: 1.0 X-Received: by 10.50.46.197 with SMTP id x5mr9324781igm.3.1461746749977; Wed, 27 Apr 2016 01:45:49 -0700 (PDT) Received: by 10.79.78.213 with HTTP; Wed, 27 Apr 2016 01:45:49 -0700 (PDT) In-Reply-To: <8385.1461611347@obiwan.sandelman.ca> References: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> <8385.1461611347@obiwan.sandelman.ca> Date: Wed, 27 Apr 2016 16:45:49 +0800 Message-ID: From: Dapeng Liu To: Michael Richardson Content-Type: multipart/alternative; boundary=14dae9340be9c8c1370531736f63 Archived-At: Cc: Russ Housley , "its@ietf.org" Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 08:45:52 -0000 --14dae9340be9c8c1370531736f63 Content-Type: text/plain; charset=UTF-8 2016-04-26 3:09 GMT+08:00 Michael Richardson : > > Russ Housley wrote: > > Carlos and I had a telephone conversation with our Area Director for > > this group, Suresh Krishnan. The result of the discussion was some > > pretty clear and pragmatic suggestions about the charter. > > > The suggestion is that the ITS WG have only two deliverables in the > > initial charter. Once these two documents are delivered to the IESG, > > then the group can recharter to tackle other things. > > This charter sounds reasonable to me. > Do we have enough participation from non-IETF ITS-types to actually get > this > done? (I mean, other than Alex P) > > Hi, As discussed during the BoF, I am interested and would like to work on those problems as an IETFer... I think there were many others also express their interest during the meeting.. If considering the liaison letter from ISO TC204, there are also interest from other SDOs and wish IETF could provide solution for them.. Thanks, Dapeng Liu > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > -- ------ Best Regards, Dapeng Liu --14dae9340be9c8c1370531736f63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2016-04-26 3:09 GMT+08:00 Michael Richardson <mcr+ietf@sandelman.ca>:

Russ Housley <housley@vigilsec.c= om> wrote:
=C2=A0 =C2=A0 > Carlos and I had a telephone conversation with our Area = Director for
=C2=A0 =C2=A0 > this group, Suresh Krishnan.=C2=A0 The result of the dis= cussion was some
=C2=A0 =C2=A0 > pretty clear and pragmatic suggestions about the charter= .

=C2=A0 =C2=A0 > The suggestion is that the ITS WG have only two delivera= bles in the
=C2=A0 =C2=A0 > initial charter.=C2=A0 Once these two documents are deli= vered to the IESG,
=C2=A0 =C2=A0 > then the group can recharter to tackle other things.

This charter sounds reasonable to me.
Do we have enough participation from non-IETF ITS-types to actually get thi= s
done?=C2=A0 (I mean, other than Alex P)


Hi,=C2=A0

As = discussed during the BoF, I am interested and would like to work on those p= roblems as an IETFer... I think there were many others also express their i= nterest during the meeting..

If considering the li= aison letter from ISO TC204, there are also interest from other SDOs and wi= sh IETF could provide solution for them..

Thanks,<= /div>
Dapeng Liu
=C2=A0

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its




--

------
Best Regards,
Dapeng Liu
--14dae9340be9c8c1370531736f63-- From nobody Wed Apr 27 02:09:47 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8EB12D642 for ; Wed, 27 Apr 2016 02:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAPvxf66-92H for ; Wed, 27 Apr 2016 02:09:44 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 618F912D5E9 for ; Wed, 27 Apr 2016 02:09:44 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id o66so66830160ywc.3 for ; Wed, 27 Apr 2016 02:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XrXzp7beQugHHdQRb+JZ+J4HEOP7tUqS7Qxr0J7vERU=; b=MfDXTwvA7bS3bQArXVt1l8tr3/zBXEWBP9bcLhDTIVVYj0XmOnag6m0bex14pSQ8SW kZO/nAv4GO2620rpESgZhx4ZMzGKjn7Z6+B8LX53eNPZ3yb6eKxP69FZEqRGn4DJMWlU kBrk0gOMOarjXvEOntHf6JJAf4GZDiYDXYrDGZKEbMwV4uXR1HT2UZVsBObajBF6/GBB itTfcx98Mjnb2RSnm2TI7gveJmGhP0clXSGu+BwXa4siy1Dn8VlIC9H75PnuUoM9JhFW uvT7UjoqzrBM6N9AdDQs5y4oQd8A814dlkVi2ToQmZw6IQrHDUYNSD6i7+40NlWozrVI Qz2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XrXzp7beQugHHdQRb+JZ+J4HEOP7tUqS7Qxr0J7vERU=; b=dA/nbt0FaTf54JBt7mF40y695E1IorlWO3Xva3Fw6qZ/Mdg5zldKFcdA2ei2XvYuX5 sMRB7AOmx5F9pTF1y6UNSOEkx7aiYzIhscS3+gF6HtyxbWjfbZefBLF7Q12eAwmeEL/m rfZt/wyPyKKPfdtAhKeTcyZzt/zyB9b8tFuk43i1EWkUl9ZUTxhXRol3Zn9ZDQ6FDO6t lHkDI8awGsF9fyNd7R8Kq9XTojBtMYaDdxgewv6THzQosNaM4+zWz6WApGQbV5x2Z48E 0KKqOUfzrK9kiriYYV3Fc1zo1zWYnUnqAOocZrpU1Jn23zj9spWihIMg0JxRpYc0Sabj smNA== X-Gm-Message-State: AOPr4FVHvdGWV5sAwovAUmS8myiJurhefQnJCNkh9bHe8gp1voHosYR4pgOUK68I6bQZfEKbupX0d2+l3JARQA== X-Received: by 10.129.88.135 with SMTP id m129mr4011832ywb.204.1461748183505; Wed, 27 Apr 2016 02:09:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.4.132 with HTTP; Wed, 27 Apr 2016 02:09:14 -0700 (PDT) In-Reply-To: References: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> <8385.1461611347@obiwan.sandelman.ca> From: "Mr. Jaehoon Paul Jeong" Date: Wed, 27 Apr 2016 18:09:14 +0900 Message-ID: To: Dapeng Liu Content-Type: multipart/alternative; boundary=001a11492ebe3aa2b7053173c559 Archived-At: Cc: Michael Richardson , Russ Housley , "its@ietf.org" Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 09:09:46 -0000 --001a11492ebe3aa2b7053173c559 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I am willing to work for ITS items as one of academia people. Three other academia people (i.e., Nabil Benamar, Sandra C=C3=A9spedes, and J=C3=A9r=C3=B4me H=C3=A4rri) and I are working for an IETF draft on a list of academia papers for IP-based V2V and V2I. My research lab (http://iotlab.skku.edu) will have a plan to design and implement a possible solution for V2V and V2I under the scope in our ITS BoF. Thanks. Best Regards, Paul On Wed, Apr 27, 2016 at 5:45 PM, Dapeng Liu wrote: > > 2016-04-26 3:09 GMT+08:00 Michael Richardson : > >> >> Russ Housley wrote: >> > Carlos and I had a telephone conversation with our Area Director f= or >> > this group, Suresh Krishnan. The result of the discussion was som= e >> > pretty clear and pragmatic suggestions about the charter. >> >> > The suggestion is that the ITS WG have only two deliverables in th= e >> > initial charter. Once these two documents are delivered to the >> IESG, >> > then the group can recharter to tackle other things. >> >> This charter sounds reasonable to me. >> Do we have enough participation from non-IETF ITS-types to actually get >> this >> done? (I mean, other than Alex P) >> >> > Hi, > > As discussed during the BoF, I am interested and would like to work on > those problems as an IETFer... I think there were many others also expres= s > their interest during the meeting.. > > If considering the liaison letter from ISO TC204, there are also interest > from other SDOs and wish IETF could provide solution for them.. > > Thanks, > Dapeng Liu > > >> >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >> >> >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> > > > -- > > ------ > Best Regards, > Dapeng Liu > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a11492ebe3aa2b7053173c559 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
I am willing to work for ITS items as one of a= cademia people.
Three other academia people (i.e., Nabil Benamar,= Sandra C=C3=A9spedes, and J=C3=A9r=C3=B4me H=C3=A4rri) and I
=C2= =A0are working for an IETF draft on a list of academia papers for IP-based = V2V and V2I.

My research lab (http://iotlab.skku.edu) will have a plan to design and i= mplement a possible solution
for V2V and V2I under the scope in o= ur ITS BoF.

Thanks.

Best = Regards,
Paul

On Wed, Apr 27, 2016 at 5:45 PM, Dapeng Liu <maxpassi= on@gmail.com> wrote:

2016-04-26 3:09 GMT+08:00 Michael Richardson &= lt;mcr+ietf@sand= elman.ca>:

Russ Housley <= housley@vigilsec.com> wrote:
=C2=A0 =C2=A0 > Carlos and I had a telephone conversation with our Area = Director for
=C2=A0 =C2=A0 > this group, Suresh Krishnan.=C2=A0 The result of the dis= cussion was some
=C2=A0 =C2=A0 > pretty clear and pragmatic suggestions about the charter= .

=C2=A0 =C2=A0 > The suggestion is that the ITS WG have only two delivera= bles in the
=C2=A0 =C2=A0 > initial charter.=C2=A0 Once these two documents are deli= vered to the IESG,
=C2=A0 =C2=A0 > then the group can recharter to tackle other things.

This charter sounds reasonable to me.
Do we have enough participation from non-IETF ITS-types to actually get thi= s
done?=C2=A0 (I mean, other than Alex P)


Hi,=C2=A0

<= div>As discussed during the BoF, I am interested and would like to work on = those problems as an IETFer... I think there were many others also express = their interest during the meeting..

If considering= the liaison letter from ISO TC204, there are also interest from other SDOs= and wish IETF could provide solution for them..

T= hanks,
Dapeng Liu
=C2=A0

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




_______________________________________________=
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its




--

------
Best Regar= ds,
Dapeng Liu

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its




--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant ProfessorDepartment of Software
Sungkyunkwan University
Office: +82-31-299-4= 957
Email: j= aehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu<= br>Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
--001a11492ebe3aa2b7053173c559-- From nobody Wed Apr 27 15:37:45 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BAA12D8D9 for ; Wed, 27 Apr 2016 15:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t05qnyWBsGkE for ; Wed, 27 Apr 2016 15:37:40 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAFC512D117 for ; Wed, 27 Apr 2016 15:37:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u3RMbokK022039; Wed, 27 Apr 2016 15:37:50 -0700 Received: from XCH15-05-01.nw.nos.boeing.com (xch15-05-01.nw.nos.boeing.com [137.137.100.58]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u3RMbici021991 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 27 Apr 2016 15:37:44 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-01.nw.nos.boeing.com (2002:8989:643a::8989:643a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 27 Apr 2016 15:37:33 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Wed, 27 Apr 2016 15:37:33 -0700 From: "Templin, Fred L" To: Alexandre Petrescu Thread-Topic: [its] latest charter text Thread-Index: AQHRnuovD0zPM4Y86k2Lvn9a/gJsy5+a0K8AgAGSCYCAAgNlkA== Date: Wed, 27 Apr 2016 22:37:33 +0000 Message-ID: <6c5b616460dc4853b254fbd5645dff0b@XCH15-05-05.nw.nos.boeing.com> References: <571E06FF.9060404@gmail.com> <06cb15e70fe04a07abe10678600daf8a@XCH15-05-05.nw.nos.boeing.com> <571F26A9.80409@gmail.com> In-Reply-To: <571F26A9.80409@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "its@ietf.org" Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 22:37:43 -0000 SGkgQWxleCwNCg0KSGVyZSBpcyBzb21lIHByb3Bvc2VkIHRleHQgZm9yIHRoZSBjaGFydGVyLiBQ bGVhc2UgbGV0IG1lIGtub3cgaWYNCnRoaXMgY2FuIGJlIGFjY29tbW9kYXRlZC4NCg0KVGhhbmtz IC0gRnJlZA0KLS0tDQpUaGUgSW50ZXJuYXRpb25hbCBDaXZpbCBBdmlhdGlvbiBPcmdhbml6YXRp b24gKElDQU8pIGlzIGRlc2lnbmluZyB0aGUNCkFlcm9uYXV0aWNhbCBUZWxlY29tbXVuaWNhdGlv bnMgTmV0d29yayBmb3IgSW50ZXJuZXQgUHJvdG9jb2wNClNlcnZpY2VzIChBVE4tSVBTKSB3aGlj aCB3aWxsIGJlIGJhc2VkIG9uIElQdjYgZnJvbSBpdHMgaW5jZXB0aW9uLg0KSVB2NiB3aWxsIHJ1 biBvdmVyIHZhcmlvdXMgYXZpYXRpb24gZGF0YSBsaW5rcyBpbmNsdWRpbmcgVkhGIGRhdGEgbGlu aywNCkwtREFDUywgQWVyb01BQ1MgYW5kIHNldmVyYWwgdmFyaWV0aWVzIG9mIFNBVENPTSAoZS5n LiwgSW5tYXJzYXQNClN3aWZ0QnJvYWRCYW5kLCBJcmlkaXVtIE5FWFQsIGV0Yy4pLiBTaW1pbGFy bHksIG90aGVyIGF2aWF0aW9uIGVudGl0aWVzDQphcmUgY29uc2lkZXJpbmcgYWlyIHRyYWZmaWMg bWFuYWdlbWVudCBzZXJ2aWNlcyBmb3IgVW5tYW5uZWQgQWlyDQpTeXN0ZW1zIChVQVMpIGFzIFVB UyBwcm9saWZlcmF0aW9uIHdpdGhpbiB0aGUgZ2xvYmFsIGFpcnNwYWNlDQpjb250aW51ZXMuIEFp ci10by1haXIgYW5kIGFpci10by1ncm91bmQgSVB2Ni1iYXNlZCBjb21tdW5pY2F0aW9ucw0KYXJl IGluIHNjb3BlIGZvciBib3RoIG1hbm5lZCBhbmQgdW5tYW5uZWQgYXZpYXRpb24uDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleGFuZHJlIFBldHJlc2N1IFttYWls dG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbV0NCj4gU2VudDogVHVlc2RheSwgQXByaWwg MjYsIDIwMTYgMToyOCBBTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBi b2VpbmcuY29tPg0KPiBDYzogaXRzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbaXRzXSBsYXRl c3QgY2hhcnRlciB0ZXh0DQo+IA0KPiBMZSAyNS8wNC8yMDE2IDE3OjMwLCBUZW1wbGluLCBGcmVk IEwgYSDDqWNyaXQgOg0KPiA+IEhpIEFsZXgsDQo+ID4NCj4gPiBXaWxsIHRoZXJlIGJlIHdvcmsg aXRlbXMgY292ZXJpbmcgY2l2aWwgYXZpYXRpb24gYW5kIHVubWFubmVkIGFpciBzeXN0ZW0NCj4g PiB1c2UgY2FzZXM/DQo+IA0KPiBIaSBGcmVkLA0KPiANCj4gVGhlIGF2aWF0aW9uIHVzZS1jYXNl IHdhcyBleHByZXNzZWQgYXQgdGhlIG1pYyBkdXJpbmcgdGhlIEJvRiBhcyB3ZWxsLg0KPiANCj4g SW4gbXkgdW5kZXJzdGFuZGluZywgYSB1c2UtY2FzZSBpbnZvbHZpbmcgSVAgbW92aW5nIG5ldHdv cmtzIGluIHBsYW5lcywNCj4gb3IgaW4gdW5tYW5uZWQgYWlyIHN5c3RlbXMsIGRvIG1ha2Ugc2Vu c2UuICBCZWNhdXNlIGl0IGlzIHNpbWlsYXIgdG8NCj4gZHJvbmVzIGRvY2tlZCBvbiBhdXRvbW9i aWxlcywgd2hpY2ggaGF2ZSBiZWVuIGRlbW9uc3RyYXRlZCBvZnRlbi4NCj4gDQo+IEhvd2V2ZXIs IHRoZSBJRVNHIHN1Z2dlc3Rpb24gaXMgdG8gZm9jdXMgbm93IG9uIElUUyAoVjJWL1YySSkgYW5k IElQdjYNCj4gb3ZlciBEU1JDLg0KPiANCj4gRm9yICJsYXRlciIgKGlmIHN1Y2Nlc3NmdWwgd2l0 aCB0aGUgYWJvdmUpOg0KPiAtIGFyZSB0aGVyZSB1c2UtY2FzZXMgb2YgY2l2aWwgYXZpYXRpb24g YW5kIHVubWFubmVkIGFpciBzeXN0ZW1zIHdoaWNoDQo+ICAgIGludm9sdmUgRFNSQzsNCj4gLSBp cyBjaXZpbCBhdmlhdGlvbiBjb25zaWRlcmluZyBJUHY2IGluIHVzZS1jYXNlcyBvZiBQbGFuZS10 by1Hcm91bmQgb3INCj4gICAgUGxhbmUtdG8tUGxhbmUgY29tbXVuaWNhdGlvbnMuDQo+IC0gd2hh dCBpcyB0aGUgbmFtZSBvZiBsaW5rcyB0aGF0IGFyZSBzcGVjaWZpYyB0byBjaXZpbCBhdmlhdGlv biBhbmQNCj4gICAgdW5tYW5uZWQgYWlyIHN5c3RlbXMgYW5kIGhhcyBJUHY2IGJlZW4gcnVuIG9u IGl0Lg0KPiANCj4gQWxleA0KPiANCj4gDQo+ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ID4NCj4g PiAqRnJvbToqaXRzIFttYWlsdG86aXRzLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2Yg KkFsZXhhbmRyZSBQZXRyZXNjdQ0KPiA+ICpTZW50OiogTW9uZGF5LCBBcHJpbCAyNSwgMjAxNiA1 OjAxIEFNDQo+ID4gKlRvOiogaXRzQGlldGYub3JnDQo+ID4gKlN1YmplY3Q6KiBbaXRzXSBsYXRl c3QgY2hhcnRlciB0ZXh0DQo+ID4NCj4gPiBJVFNlcnMsDQo+ID4NCj4gPiBZb3Ugd2lsbCBmaW5k IGJlbG93IHRoZSBsYXRlc3QgY2hhcnRlciB0ZXh0Lg0KPiA+DQo+ID4gSXQgaW5jbHVkZXMgY2hh bmdlcyBpc3N1ZWQgZnJvbSBkaXNjdXNzaW9ucyB3aXRoIERpY2suDQo+ID4NCj4gPiBBbGV4DQo+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPiBJbnRlbGxpZ2VudCBUcmFuc3BvcnRhdGlvbiBTeXN0ZW1zIChp dHMpDQo+ID4NCj4gPiBDaGFpcnM6DQo+ID4gICAgIFJ1c3MgSG91c2xleQ0KPiA+ICAgICBDYXJs b3MgUGlnbmF0YXJvDQo+ID4NCj4gPiBBc3NpZ25lZCBBcmVhIERpcmVjdG9yOg0KPiA+ICAgICBT dXJlc2ggS3Jpc2huYW4NCj4gPg0KPiA+IE1haWxpbmcgbGlzdA0KPiA+ICAgICBBZGRyZXNzOiBp dHNAaWV0Zi5vcmcgPG1haWx0bzppdHNAaWV0Zi5vcmc+DQo+ID4gICAgIFRvIFN1YnNjcmliZTog aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCj4gPiAgICAgQXJjaGl2 ZToNCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaXRzL2N1cnJlbnQv bWFpbGxpc3QuaHRtbA0KPiA+DQo+ID4gQWRkaXRpb25hbCB3ZWIgcGFnZQ0KPiA+ICAgICBUQkQN Cj4gPg0KPiA+IENoYXJ0ZXINCj4gPg0KPiA+IEF1dG9tb2JpbGVzIGFuZCB2ZWhpY2xlcyBvZiBh bGwgdHlwZXMgYXJlIGluY3JlYXNpbmdseSBjb25uZWN0ZWQgdG8NCj4gPiB0aGUgSW50ZXJuZXQu ICBDb21mb3J0LWVuaGFuY2luZyBlbnRlcnRhaW5tZW50IGFwcGxpY2F0aW9ucywgcm9hZA0KPiA+ IHNhZmV0eSBhcHBsaWNhdGlvbnMgYmFzZWQgb24gYmlkaXJlY3Rpb25hbCBkYXRhIGZsb3dzLCBh bmQgY29ubmVjdGVkDQo+ID4gYXV0b21hdGVkIGRyaXZpbmcgYXJlIGJ1dCBhIGZldyBuZXcgZmVh dHVyZXMgZXhwZWN0ZWQgaW4gYXV0b21vYmlsZXMNCj4gPiB0byBoaXQgdGhlIHJvYWRzIGZyb20g bm93IHRvIHllYXIgMjAyMC4NCj4gPg0KPiA+IFRvZGF5LCB0aGVyZSBhcmUgc2V2ZXJhbCBkZXBs b3llZCBWZWhpY2xlLXRvLUludGVybmV0IHRlY2hub2xvZ2llcw0KPiA+IChWMkludGVybmV0KSB0 aGF0IG1ha2UgdXNlIG9mIGVtYmVkZGVkIEludGVybmV0IG1vZHVsZXMsIG9yIHRocm91Z2gNCj4g PiBkcml2ZXIncyBjZWxsdWxhciBzbWFydHBob25lOiBtaXJyb3JsaW5rLCBjYXJwbGF5LCBhbmRy b2lkIGF1dG8uDQo+ID4gSG93ZXZlciwgVmVoaWNsZS10by1WZWhpY2xlIChWMlYpIGFuZCBWZWhp Y2xlLXRvLUluZnJhc3RydWN0dXJlIChWMkksDQo+ID4gbm90IHRvIGJlIG1pc3Rha2VuIHdpdGgg VjJJbnRlcm5ldCkgY29tbXVuaWNhdGlvbnMgYXJlIHN0aWxsIGJlaW5nDQo+ID4gZGV2ZWxvcGVk Lg0KPiA+DQo+ID4gSW4gdGhlIGZ1dHVyZSwgc29tZSB2ZWhpY2xlIGNvbW11bmljYXRpb25zIG1h eSBub3QgdXNlIElQIGZvcg0KPiA+IGV4Y2hhbmdpbmcgc2FmZXR5IG1lc3NhZ2VzIHdpdGggb3Ro ZXIgdmVoaWNsZXMgYW5kIGluZnJhc3RydWN0dXJlLg0KPiA+IE90aGVyIHZlaGljbGUgY29tbXVu aWNhdGlvbnMgbWF5IGludm9sdmUgSVAtYmFzZWQgcHJvdG9jb2xzLA0KPiA+IGVzcGVjaWFsbHkg d2hlbiBtdWx0aXBsZSBhcHBsaWNhdGlvbnMgbmVlZCB0byBzaGFyZSBvbmUgZGF0YSBsaW5rLg0K PiA+DQo+ID4gVGhpcyBncm91cCB3aWxsIHdvcmsgb24gVjJWIGFuZCBWMkkgdXNlLWNhc2VzIHdo ZXJlIElQIGlzIHdlbGwtc3VpdGVkDQo+ID4gYXMgYSBuZXR3b3JraW5nIHRlY2hub2xvZ3ksIHN1 cHBvcnRpbmcgYWxzbyBhcHBsaWNhdGlvbnMgdGhhdCBpbnZvbHZlDQo+ID4gZXhjaGFuZ2VzIG9m IHNhZmV0eS1yZWxhdGVkIG1lc3NhZ2VzIGJldHdlZW4gdmVoaWNsZXMgYW5kDQo+ID4gaW5mcmFz dHJ1Y3R1cmUgaWYgbmVjZXNzYXJ5Lg0KPiA+DQo+ID4gVGhpcyBncm91cCB3aWxsIGRldmVsb3Ag SVAtYmFzZWQgcHJvdG9jb2xzIHRvIGVzdGFibGlzaCBkaXJlY3QgYW5kDQo+ID4gc2VjdXJlIGNv bm5lY3Rpdml0eSBiZXR3ZWVuIGEgdmVoaWNsZSwgd2hpY2ggaXMgb2Z0ZW4gY29tcHJpc2VkIG9m DQo+ID4gbW92aW5nIG5ldHdvcmtzLCBhbmQgb3RoZXIgdmVoaWNsZXMgYW5kIHN0YXRpb25hcnkg c3lzdGVtcy4gIFNvbWUNCj4gPiBjb21tdW5pY2F0aW9ucyB3aWxsIGJlIGV4dHJlbWVseSBzaG9y dCBsaXZlZCwgYnV0IG90aGVycyB3aWxsIGxhc3QgZm9yDQo+ID4gbWFueSBob3VycyBvciBkYXlz Lg0KPiA+DQo+ID4gSW4gZ2VuZXJhbCwgdGhpcyBncm91cCBpcyBjb25jZXJuZWQgd2l0aCBzaXR1 YXRpb25zIGludm9sdmluZyBtb3ZpbmcNCj4gPiBuZXR3b3JrIHRvIG5lYXJieSBtb3ZpbmcsIG9y IGZpeGVkLCBuZXR3b3JrIGNvbW11bmljYXRpb25zIChWMlYsIFYySSwNCj4gPiBJMlYpLiAgRm9y IGV4YW1wbGU6IGEgbW92aW5nIG5ldHdvcmsgaW4gYSB2ZWhpY2xlIGNvbW11bmljYXRpbmcgdG8N Cj4gPiBhbm90aGVyIG1vdmluZyBuZXR3b3JrIGluIGEgbmVhcmJ5IHZlaGljbGUgKGZvciBDLUFD QywgUGxhdG9vbmluZywgb3INCj4gPiBhdCBhbiBpbmNpZGVudCBzY2VuZSk7IGEgcGVyc29uYWwg YXJlYSBuZXR3b3JrIGNhcnJpZWQgYnkgYSB1c2VyIGFuZA0KPiA+IGNvbm5lY3RpbmcgdG8gYW4g aW4taG91c2UgZml4ZWQgbmV0d29yayAoaG9tZW5ldCk7IGFuIGluLWNhciBuZXR3b3JrZWQNCj4g PiBkZXZpY2UgcmVjZWl2aW5nIG1lc3NhZ2VzIGZyb20gYSByb2FkLXNpZGUgZGlzcGxheSB3aGVu IHBhc3NpbmcgYnksDQo+ID4gd2Fnb24tdG8td2Fnb24gcmFuZ2UgZXh0ZW5zaW9uIGluIGEgdHJh aW47IHRyYWluLXRvLWludGVyc2VjdGlvbg0KPiA+IHNpZ25hbGxpbmcuICBJbiB0aGVzZSBsb29w LWZyZWUgMS1JUC1ob3AgdG9wb2xvZ2llcyB0aGVyZSBpcyBhIHByb2JsZW0NCj4gPiBvZiBlc3Rh Ymxpc2hpbmcgSVAgcGF0aHMgcXVpY2tseSBhbmQgcmVsaWFibHkuDQo+ID4NCj4gPiBJbXByb3Zl ZCBzYWZldHkgaXMgYW4gaW1tZWRpYXRlIHJlc3VsdCBvZiBoeXBlci1jb25uZWN0aXZpdHkgb2YN Cj4gPiB2ZWhpY2xlczsgYXMgc3VjaCBwdWJsaWMgYXV0aG9yaXRpZXMgd29ybGR3aWRlIGFyZSBp bmNyZWFzaW5nbHkNCj4gPiBtYW5kYXRpbmcgc2VjdXJlIGNvbW11bmljYXRpb24gdGVjaG5vbG9n eSByZXF1aXJlbWVudHMgaW4gdmVoaWNsZXMuDQo+ID4gRW1lcmdlbmN5IGFwcGxpY2F0aW9ucyBm b3IgaW5zdHJ1bWVudGVkIGFtYnVsYW5jZXMgY2FycnkgbWFueSBiZW5lZml0cw0KPiA+IGJvdGgg dG8gdGhlIHVzZXJzIGFuZCB0byBzb2NpZXR5IGluIGdlbmVyYWwuICBGb3IgdGhlc2UgcmVhc29u cywgYQ0KPiA+IHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtIG9mIGVzdGFibGlzaGluZyBJUCBwYXRo cyBiZXR3ZWVuIG5lYXJieSBtb3ZpbmcNCj4gPiBuZXR3b3JrcyB3aWxsIGJlIHJlc2lsaWVudCB0 byB0aHJlYXRzIHN1Y2ggYXMgZWF2ZXNkcm9wcGluZy4NCj4gPg0KPiA+IE1vdmluZyBuZXR3b3Jr IHRvIG5lYXJieSBtb3Zpbmcgb3IgZml4ZWQgbmV0d29yayBjb21tdW5pY2F0aW9ucyBtYXkNCj4g PiBpbnZvbHZlIHZhcmlvdXMga2luZHMgb2YgbGluayBsYXllcnM6IDgwMi4xMS1PQ0IgKE91dHNp ZGUgdGhlIENvbnRleHQNCj4gPiBvZiBhIEJhc2ljIFNlcnZpY2UgU2V0KSwgODAyLjE1LjQgd2l0 aCA2bG93cGFuLCA4MDIuMTFhZCwgVkxDIChWaXNpYmxlDQo+ID4gTGlnaHQgQ29tbXVuaWNhdGlv bnMpLCBJckRBLCBMVEUtRCwgTFAtV0FOLiAgT25lIG9mIHRoZSBtb3N0IHVzZWQgbGluaw0KPiA+ IGxheWVycyBmb3IgdmVoaWN1bGFyIG5ldHdvcmtzIGlzIElFRUUgODAyLjExLU9DQiwgYXMgYSBi YXNpcyBmb3IgRFNSQy4NCj4gPiBIb3dldmVyLCBJUHY2IG9uIDgwMi4xMS1PQ0IgaXMgbm90IHll dCBkZWZpbmVkLg0KPiA+DQo+ID4gVGhlIGdyb3VwIHdpbGwgb25seSB3b3JrIG9uIElQdjYgc29s dXRpb25zLg0KPiA+DQo+ID4gVGhlIGdyb3VwIHdpbGwgbGV2ZXJhZ2Ugb24gdGVjaG5vbG9naWVz IGZvciBJbnRlcm5ldCBvZiBUaGluZ3MgKElvVCkNCj4gPiB3aGljaCBhcmUgZGV2ZWxvcGVkIGlu IG90aGVyIElFVEYgZWZmb3J0czogNmxvLCBMUC1XQU4sIFQyVC4NCj4gPiBDby1leGlzdGVuY2Ug d2l0aCB0ZWNobmlxdWVzIG9mIGluZnJhc3RydWN0dXJlIG1vYmlsaXR5IG1hbmFnZW1lbnQNCj4g PiB3aWxsIGJlIGNvb3JkaW5hdGVkIHdpdGggdGhlIERNTSBXb3JraW5nIEdyb3VwLg0KPiA+DQo+ ID4gVGhlIFNET3MgaW50ZXJlc3RlZCBpbiB0aGlzIHdvcmsgYXJlOiBJU08vVEMyMDQsIEVUU0kg VEMgSVRTLCAzR1BQLA0KPiA+IE5IVFNBIGFuZCBtb3JlLg0KPiA+DQo+ID4gVGhpcyBncm91cCB3 aWxsIG5vdCB3b3JrIG9uIFYyViBvciBWMkkgdXNlLWNhc2VzIHdoZXJlIElQIGlzIG5vdA0KPiA+ IHdlbGwtc3VpdGVkLg0KPiA+DQo+ID4gSWYgdGhlIGdyb3VwIGlzIHN1Y2Nlc3NmdWwgaW4gZGVz aWduaW5nIGEgc2ltcGxlIDEtSVAtaG9wIHNvbHV0aW9uIGZvcg0KPiA+IFYyVi9WMkkvSTJWLCBh bmQgaWYgZGVwbG95bWVudHMgcHJvdmUgdXNlZnVsLCBpbiByZWFzb25hYmxlIHRpbWUsIHRoZW4N Cj4gPiBmdXR1cmUgZXh0ZW5zaW9ucyBmb3Igbi1JUC1ob3AgVjJWMkkgbWF5IGJlIGNvbnNpZGVy ZWQuDQo+ID4NCj4gPiBXb3JrIGl0ZW1zDQo+ID4gMS4gIlByb2JsZW0gc3RhdGVtZW50IGZvciBJ UCBpbiBWMlYgYW5kIFYySSINCj4gPiAgICAgaW5jbHVkaW5nICJJUCBhZGRyZXNzaW5nIGFyY2hp dGVjdHVyZSBmb3IgVjJWIGFuZCBWMkkiDQo+ID4gICAgIGFuZCBpbmNsdWRpbmcgIkdhcCBBbmFs eXNpczogSVAgcHJvdG9jb2xzIHN1aXRlZCBhbmQgZ2FwcyINCj4gPiAgICAgYW5kIGluY2x1ZGlu ZyAiVXNlLWNhc2VzIGZvciBJUCBpbiBWMlYgYW5kIFYySSBtb3ZpbmcgbmV0d29yaw0KPiA+ICAg ICBUbyBuZWFyYnkgbW92aW5nIG9yIGZpeGVkIG5ldHdvcmsiDQo+ID4NCj4gPiAyLiAiVGhyZWF0 IEFuYWx5c2lzIGZvciBJUCBwcmVmaXggZXhjaGFuZ2VzIGluIFYyViBhbmQgVjJJDQo+ID4gICAg IENvbnRleHQiDQo+ID4NCj4gPiAzLiAiSVAgb3ZlciBEU1JDICg4MDIuMTEtT0NCKSIgdHlwaWNh bCBJUC1vdmVyLWZvbyBkb2N1bWVudCwNCj4gPiAgICAgaW5jbHVkaW5nIGNvbm5lY3Rpdml0eSBp biBmYXN0IGFuZCBhc3ltbWV0cmljIGNvbmRpdGlvbnMsDQo+ID4gICAgIENvdmVyYWdlIGFyZWEg dnMgc3BlZWQgZGlhZ3JhbXMsIGJlbG93LUlQIGNvbmdlc3Rpb24NCj4gPiAgICAgbWFuYWdlbWVu dC4NCj4gPg0KPiA+IDQuICJMaXN0IG9mIHBhcGVycyBhbmQgX3Byb2R1Y3RzXyB1c2luZyBJUCBp biBWMlYgYW5kIFYySSINCj4gPg0KPiA+IDUuICJTb2x1dGlvbiBmb3IgZGlyZWN0IGNvbW11bmlj YXRpb24gYmV0d2VlbiBtb3ZpbmcgbmV0d29ya3MiDQo+ID4NCj4gPiBHb2FscyBhbmQgbWlsZXN0 b25lcw0KPiA+IE9jdCAyMDE2IC0gc3VibWl0IOKAnFByb2JsZW0gU3RhdGVtZW504oCdIHRvIFdH DQo+ID4gT2N0IDIwMTYgLSBzdWJtaXQg4oCcTGlzdCBvZiBwYXBlcnMgYW5kIHByb2R1Y3Rz4oCd IHRvIFdHDQo+ID4gRmViIDIwMTcgLSBzdWJtaXQg4oCcVGhyZWF0IEFuYWx5c2lz4oCdIHRvIFdH DQo+ID4gRmViIDIwMTcgLSBzdWJtaXQg4oCcSVAgb3ZlciBEU1JDICg4MDIuMTEtT0NCKeKAnSB0 byBXRw0KPiA+IEp1biAyMDE3IC0gc3VibWl0IOKAnFNvbHV0aW9uIGZvciBkaXJlY3Rpb24gY29t bXVuaWNhdGlvbiBiZXR3ZWVuDQo+ID4gICAgICAgICAgICAgICAgICAgICBtb3ZpbmcgbmV0d29y a3PigJ0gdG8gV0cNCj4gPiBPY3QgMjAxNyAtIHN0YXJ0IHN1Ym1pdHRpbmcgdG8gSUVTRw0KPiA+ DQoNCg== From nobody Wed Apr 27 20:12:41 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DB512D590 for ; Wed, 27 Apr 2016 20:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnvvXXfImp5L for ; Wed, 27 Apr 2016 20:12:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7356812D54E for ; Wed, 27 Apr 2016 20:12:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNL19124; Thu, 28 Apr 2016 03:12:33 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 28 Apr 2016 04:12:32 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.235]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Thu, 28 Apr 2016 11:12:13 +0800 From: "Liushucheng (Will)" To: "its@ietf.org" Thread-Topic: [its] ITS Charter Discussion Thread-Index: AdGg+AbiqPN3VXR7SGC94SC9eWWbPg== Date: Thu, 28 Apr 2016 03:12:12 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.84] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB896E7A70SZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.57217FA3.0064, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.235, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ce25b09444edbccad970d457c2920883 Archived-At: Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 03:12:40 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB896E7A70SZXEMA509MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQoNCkFzIGFuIGNvbnRyaWJ1dG9yIGluIGJvdGggSUVURiBpcHY2IHJlbGF0ZWQg V0dzIGFuZCBFVFNJIElTRyBJUDYsIGFzIHdlbGwgYXMgYSBwcmV2aW91cyByZXNlYXJjaGVyIGlu IElPVC4gSeKAmW0gcHJldHR5IGludGVyZXN0ZWQgaW4gdGhlIHBvaW50IGJlbG93IGFuZCB3b3Vs ZCBsaWtlIHRvIHNlZSB0aGlzIFdHIGZvcm1lZCB0byBzb2x2ZSByZWxhdGVkIGlzc3Vlcy4NCj4g LSBXaHkgaXMgSVB2NiBuZWVkZWQ/DQo+ICAgIOKAlCBFeHBsYWluIHdoeSBzb21lIHRyYWZmaWMg d2lsbCBub3QgdXNlIElQdjYNCj4gICAg4oCUIEV4cGxhaW4gd2h5IG90aGVyIHRyYWZmaWMgd2ls bCB1c2UgSVB2Ng0KDQpSZWdhcmRzLA0KV2lsbCAoU2h1Y2hlbmcgTElVKQ0KDQotLS0tLS0tLS0t IEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206IFJ1c3MgSG91c2xleSA8aG91c2xl eUB2aWdpbHNlYy5jb208bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tPj4NCkRhdGU6IDIwMTYt MDQtMjUgMjA6NTkgR01UKzA4OjAwDQpTdWJqZWN0OiBbaXRzXSBJVFMgQ2hhcnRlciBEaXNjdXNz aW9uDQpUbzogaXRzQGlldGYub3JnPG1haWx0bzppdHNAaWV0Zi5vcmc+DQoNCg0KDQpDYXJsb3Mg YW5kIEkgaGFkIGEgdGVsZXBob25lIGNvbnZlcnNhdGlvbiB3aXRoIG91ciBBcmVhIERpcmVjdG9y IGZvciB0aGlzIGdyb3VwLCBTdXJlc2ggS3Jpc2huYW4uICBUaGUgcmVzdWx0IG9mIHRoZSBkaXNj dXNzaW9uIHdhcyBzb21lIHByZXR0eSBjbGVhciBhbmQgcHJhZ21hdGljIHN1Z2dlc3Rpb25zIGFi b3V0IHRoZSBjaGFydGVyLg0KDQpUaGUgc3VnZ2VzdGlvbiBpcyB0aGF0IHRoZSBJVFMgV0cgaGF2 ZSBvbmx5IHR3byBkZWxpdmVyYWJsZXMgaW4gdGhlIGluaXRpYWwgY2hhcnRlci4gIE9uY2UgdGhl c2UgdHdvIGRvY3VtZW50cyBhcmUgZGVsaXZlcmVkIHRvIHRoZSBJRVNHLCB0aGVuIHRoZSBncm91 cCBjYW4gcmVjaGFydGVyIHRvIHRhY2tsZSBvdGhlciB0aGluZ3MuDQoNCkFuIEluZm9ybWF0aW9u YWwgUkZDIHRoYXQgY292ZXJzOg0KIC0gV2hhdCBpcyBJVFM/DQogICAg4oCUIEV4cGxhaW4gVjJW LCBWMkksIGFuZCBzbyBvbg0KIC0gV2h5IGlzIElQdjYgbmVlZGVkPw0KICAgIOKAlCBFeHBsYWlu IHdoeSBzb21lIHRyYWZmaWMgd2lsbCBub3QgdXNlIElQdjYNCiAgICDigJQgRXhwbGFpbiB3aHkg b3RoZXIgdHJhZmZpYyB3aWxsIHVzZSBJUHY2DQogLSBQcm9ibGVtIHN0YXRlbWVudA0KIC0gVXNl LWNhc2VzDQogLSBTZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KIC0gUHJpdmFjeSBjb25zaWRlcmF0 aW9ucw0KDQpBIFN0YW5kYXJkcy1UcmFjayBSRkMgdGhhdCBjb3ZlcnM6DQogLSBJUHY2IG92ZXIg RFNSQw0KDQpSdXNzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KaXRzIG1haWxpbmcgbGlzdA0KaXRzQGlldGYub3JnPG1haWx0bzppdHNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KDQoNCg0K --_000_C9B5F12337F6F841B35C404CF0554ACB896E7A70SZXEMA509MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQpoMw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoi 5qCH6aKYIDMgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJ Zm9udC1zaXplOjEzLjVwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi4zQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5qCH6aKY IDMgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6Iuagh+mi mCAzIjsNCglmb250LWZhbWlseTrlrovkvZM7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpzcGFuLmdk DQoJe21zby1zdHlsZS1uYW1lOmdkO30NCnNwYW4uZ28NCgl7bXNvLXN0eWxlLW5hbWU6Z287fQ0K c3Bhbi5nMw0KCXttc28tc3R5bGUtbmFtZTpnMzt9DQpzcGFuLnQta3QNCgl7bXNvLXN0eWxlLW5h bWU6dC1rdDt9DQpzcGFuLmhiDQoJe21zby1zdHlsZS1uYW1lOmhiO30NCnNwYW4uaW0NCgl7bXNv LXN0eWxlLW5hbWU6aW07fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkw LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEZvbGtzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcyBh biBjb250cmlidXRvciBpbiBib3RoIElFVEYgaXB2NiByZWxhdGVkIFdHcyBhbmQgRVRTSSBJU0cg SVA2LCBhcyB3ZWxsIGFzIGEgcHJldmlvdXMgcmVzZWFyY2hlciBpbiBJT1QuIEnigJltIHByZXR0 eSBpbnRlcmVzdGVkIGluIHRoZSBwb2ludCBiZWxvdw0KIGFuZCB3b3VsZCBsaWtlIHRvIHNlZSB0 aGlzIFdHIGZvcm1lZCB0byBzb2x2ZSByZWxhdGVkIGlzc3Vlcy4gPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsmbmJzcDst IFdoeSBpcyBJUHY2IG5lZWRlZD88YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyA8L3NwYW4+4oCUPHNw YW4gbGFuZz0iRU4tVVMiPiBFeHBsYWluIHdoeSBzb21lIHRyYWZmaWMgd2lsbCBub3QgdXNlIElQ djY8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyA8L3NwYW4+4oCUPHNwYW4gbGFuZz0iRU4tVVMiPiBF eHBsYWluIHdoeSBvdGhlciB0cmFmZmljIHdpbGwgdXNlIElQdjY8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWdu Omp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaWxsIChTaHVjaGVuZyBMSVUpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS0tLS0tLSBGb3J3YXJkZWQg bWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogPGI+UnVzcyBIb3VzbGV5PC9iPiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+aG91c2xl eUB2aWdpbHNlYy5jb208L2E+Jmd0Ozxicj4NCkRhdGU6IDIwMTYtMDQtMjUgMjA6NTkgR01UJiM0 MzswODowMDxicj4NClN1YmplY3Q6IFtpdHNdIElUUyBDaGFydGVyIERpc2N1c3Npb248YnI+DQpU bzogPGEgaHJlZj0ibWFpbHRvOml0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPml0c0BpZXRm Lm9yZzwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpDYXJsb3MgYW5kIEkgaGFkIGEgdGVsZXBo b25lIGNvbnZlcnNhdGlvbiB3aXRoIG91ciBBcmVhIERpcmVjdG9yIGZvciB0aGlzIGdyb3VwLCBT dXJlc2ggS3Jpc2huYW4uJm5ic3A7IFRoZSByZXN1bHQgb2YgdGhlIGRpc2N1c3Npb24gd2FzIHNv bWUgcHJldHR5IGNsZWFyIGFuZCBwcmFnbWF0aWMgc3VnZ2VzdGlvbnMgYWJvdXQgdGhlIGNoYXJ0 ZXIuPGJyPg0KPGJyPg0KVGhlIHN1Z2dlc3Rpb24gaXMgdGhhdCB0aGUgSVRTIFdHIGhhdmUgb25s eSB0d28gZGVsaXZlcmFibGVzIGluIHRoZSBpbml0aWFsIGNoYXJ0ZXIuJm5ic3A7IE9uY2UgdGhl c2UgdHdvIGRvY3VtZW50cyBhcmUgZGVsaXZlcmVkIHRvIHRoZSBJRVNHLCB0aGVuIHRoZSBncm91 cCBjYW4gcmVjaGFydGVyIHRvIHRhY2tsZSBvdGhlciB0aGluZ3MuPGJyPg0KPGJyPg0KQW4gSW5m b3JtYXRpb25hbCBSRkMgdGhhdCBjb3ZlcnM6PGJyPg0KJm5ic3A7LSBXaGF0IGlzIElUUz88YnI+ DQombmJzcDsgJm5ic3A7IOKAlCBFeHBsYWluIFYyViwgVjJJLCBhbmQgc28gb248YnI+DQombmJz cDstIFdoeSBpcyBJUHY2IG5lZWRlZD88YnI+DQombmJzcDsgJm5ic3A7IOKAlCBFeHBsYWluIHdo eSBzb21lIHRyYWZmaWMgd2lsbCBub3QgdXNlIElQdjY8YnI+DQombmJzcDsgJm5ic3A7IOKAlCBF eHBsYWluIHdoeSBvdGhlciB0cmFmZmljIHdpbGwgdXNlIElQdjY8YnI+DQombmJzcDstIFByb2Js ZW0gc3RhdGVtZW50PGJyPg0KJm5ic3A7LSBVc2UtY2FzZXM8YnI+DQombmJzcDstIFNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zPGJyPg0KJm5ic3A7LSBQcml2YWN5IGNvbnNpZGVyYXRpb25zPGJyPg0K PGJyPg0KQSBTdGFuZGFyZHMtVHJhY2sgUkZDIHRoYXQgY292ZXJzOjxicj4NCiZuYnNwOy0gSVB2 NiBvdmVyIERTUkM8YnI+DQo8YnI+DQpSdXNzPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQppdHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOml0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPml0c0BpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRz PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjQxLjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_C9B5F12337F6F841B35C404CF0554ACB896E7A70SZXEMA509MBSchi_-- From nobody Thu Apr 28 10:44:06 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC21712D8A2 for ; Thu, 28 Apr 2016 10:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.716 X-Spam-Level: X-Spam-Status: No, score=-3.716 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5BHaleB6Vhx for ; Thu, 28 Apr 2016 10:44:01 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id D3BA212D864 for ; Thu, 28 Apr 2016 10:44:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Wn05sfA3p5uh3IK4OKeoqAoXvhR4ycJMcsdLDtzBxMBwEwbKkhjTFSOBQ+sRHEZN; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.67]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1avpyb-00015O-4R; Thu, 28 Apr 2016 13:43:45 -0400 To: Russ Housley , its@ietf.org References: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> From: Charlie Perkins Message-ID: Date: Thu, 28 Apr 2016 10:43:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7e3a9ead01dda23401ff3f6d4cc3f3ab6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 17:44:03 -0000 Hello folks, I think this outline for a charter is reasonable. The informational RFC as proposed has a very broad scope, so it would need to be envisioned more as a survey article but aimed at supporting a problem statement. Perhaps there could be two Informational RFCs: One Informational RFC that covers: - What is ITS? Explain V2V, V2I, and so on (including terminology) - 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 Another Informational RFC that covers: - Problem statement - Security considerations - Privacy considerations The security and privacy considerations are themselves closely related, and crucial to the problem statement. I think the general problem area is very important and that the IETF has a great deal to offer. This is especially true given current efforts towards self-driving cars, which seem very likely to place urgent demands on networking protocols. I don't have deployment experience or any immediate plans for implementation, but I do also work with IEEE 802 Wireless and I think that will provide a useful alternative perspective. Regards, Charlie P. On 4/25/2016 5:59 AM, Russ Housley wrote: > Carlos and I had a telephone conversation with our Area Director for this group, Suresh Krishnan. The result of the discussion was some pretty clear and pragmatic suggestions about the charter. > > The suggestion is that the ITS WG have only two deliverables in the initial charter. Once these two documents are delivered to the IESG, then the group can recharter to tackle other things. > > An Informational RFC that covers: > - What is ITS? > Explain V2V, V2I, and so on > - Why is IPv6 needed? > Explain why some traffic will not use IPv6 > Explain why other traffic will use IPv6 > - Problem statement > - Use-cases > - Security considerations > - Privacy considerations > > A Standards-Track RFC that covers: > - IPv6 over DSRC > > Russ > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Thu Apr 28 11:07:11 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3658012D8EC for ; Thu, 28 Apr 2016 11:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbM1o7XzSaQm for ; Thu, 28 Apr 2016 11:06:53 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410ED12B047 for ; Thu, 28 Apr 2016 11:06:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3SI6lSx017213; Thu, 28 Apr 2016 20:06:47 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4850F20566A; Thu, 28 Apr 2016 20:08:28 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E1EEF2082EC; Thu, 28 Apr 2016 20:08:26 +0200 (CEST) Received: from [132.166.84.3] ([132.166.84.3]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3SI6jCN000740; Thu, 28 Apr 2016 20:06:46 +0200 To: "Templin, Fred L" References: <571E06FF.9060404@gmail.com> <06cb15e70fe04a07abe10678600daf8a@XCH15-05-05.nw.nos.boeing.com> <571F26A9.80409@gmail.com> <6c5b616460dc4853b254fbd5645dff0b@XCH15-05-05.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <57225135.2040109@gmail.com> Date: Thu, 28 Apr 2016 20:06:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <6c5b616460dc4853b254fbd5645dff0b@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 18:06:59 -0000 Hi Fred, This is very tempting. We know we must make technology that is applied in as many settings as possible. TCP works as much in my office PC as in that plane's server. However, at this time we have not yet identified L-DACS, AeroMACS nor what is Iridium NEXT going to use next. It's the first time we hear about them. I suppose L-DACS is very different than 802.11p. I am tempted to believe that at this time we keep the air suggestion below as a very good perspective. We will need to ask the chairs. Maybe when we're done with IP-over-DSRC and V2I/V2V documents then we contemplate re-charter and study L-DACS more. (maybe until then we'll have cheap L-DACS cards, free L-DACS linux kernel drivers, and wireshark dissectors for L-DACS) (and are L-DACS, VHF, AeroMACS below IP directly between planes, or is it something else between planes that may need IP) Yours, Alex Le 28/04/2016 00:37, Templin, Fred L a écrit : > Hi Alex, > > Here is some proposed text for the charter. Please let me know if > this can be accommodated. > > Thanks - Fred > --- > The International Civil Aviation Organization (ICAO) is designing the > Aeronautical Telecommunications Network for Internet Protocol > Services (ATN-IPS) which will be based on IPv6 from its inception. > IPv6 will run over various aviation data links including VHF data link, > L-DACS, AeroMACS and several varieties of SATCOM (e.g., Inmarsat > SwiftBroadBand, Iridium NEXT, etc.). Similarly, other aviation entities > are considering air traffic management services for Unmanned Air > Systems (UAS) as UAS proliferation within the global airspace > continues. Air-to-air and air-to-ground IPv6-based communications > are in scope for both manned and unmanned aviation. > >> -----Original Message----- >> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] >> Sent: Tuesday, April 26, 2016 1:28 AM >> To: Templin, Fred L >> Cc: its@ietf.org >> Subject: Re: [its] latest charter text >> >> Le 25/04/2016 17:30, Templin, Fred L a écrit : >>> Hi Alex, >>> >>> Will there be work items covering civil aviation and unmanned air system >>> use cases? >> >> Hi Fred, >> >> The aviation use-case was expressed at the mic during the BoF as well. >> >> In my understanding, a use-case involving IP moving networks in planes, >> or in unmanned air systems, do make sense. Because it is similar to >> drones docked on automobiles, which have been demonstrated often. >> >> However, the IESG suggestion is to focus now on ITS (V2V/V2I) and IPv6 >> over DSRC. >> >> For "later" (if successful with the above): >> - are there use-cases of civil aviation and unmanned air systems which >> involve DSRC; >> - is civil aviation considering IPv6 in use-cases of Plane-to-Ground or >> Plane-to-Plane communications. >> - what is the name of links that are specific to civil aviation and >> unmanned air systems and has IPv6 been run on it. >> >> Alex >> >> >>> >>> Thanks - Fred >>> >>> *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre Petrescu >>> *Sent:* Monday, April 25, 2016 5:01 AM >>> *To:* its@ietf.org >>> *Subject:* [its] latest charter text >>> >>> ITSers, >>> >>> You will find below the latest charter text. >>> >>> It includes changes issued from discussions with Dick. >>> >>> Alex >>> -------------------------------------------------------------------- >>> Intelligent Transportation Systems (its) >>> >>> Chairs: >>> Russ Housley >>> Carlos Pignataro >>> >>> Assigned Area Director: >>> Suresh Krishnan >>> >>> Mailing list >>> Address: its@ietf.org >>> 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 based on 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. >>> >>> In general, this group is concerned with situations involving moving >>> network to nearby moving, or fixed, network communications (V2V, V2I, >>> I2V). For example: a moving network in a vehicle communicating to >>> another moving network in a nearby vehicle (for C-ACC, Platooning, or >>> at an incident scene); a personal area network carried by a user and >>> connecting to an in-house fixed network (homenet); an in-car networked >>> device receiving messages from a road-side display when passing by, >>> wagon-to-wagon range extension in a train; train-to-intersection >>> signalling. In these loop-free 1-IP-hop topologies there is a problem >>> of establishing IP paths quickly and reliably. >>> >>> Improved safety is an immediate result of hyper-connectivity of >>> vehicles; as such public authorities worldwide are increasingly >>> mandating secure communication technology requirements in vehicles. >>> Emergency applications for instrumented ambulances carry many benefits >>> both to the users and to society in general. For these reasons, a >>> solution to the problem of establishing IP paths between nearby moving >>> networks will be resilient to threats such as eavesdropping. >>> >>> 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. >>> >>> 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. >>> >>> If the group is successful in designing a simple 1-IP-hop solution for >>> V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then >>> future extensions for n-IP-hop V2V2I may be considered. >>> >>> Work items >>> 1. "Problem statement for IP in V2V and V2I" >>> including "IP addressing architecture for V2V and V2I" >>> and including "Gap Analysis: IP protocols suited and gaps" >>> and including "Use-cases for IP in V2V and V2I moving network >>> To nearby moving or fixed network" >>> >>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I >>> Context" >>> >>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document, >>> including connectivity in fast and asymmetric conditions, >>> Coverage area vs speed diagrams, below-IP congestion >>> management. >>> >>> 4. "List of papers and _products_ using IP in V2V and V2I" >>> >>> 5. "Solution for direct communication between moving networks" >>> >>> Goals and milestones >>> Oct 2016 - submit “Problem Statement” to WG >>> Oct 2016 - submit “List of papers and products” to WG >>> Feb 2017 - submit “Threat Analysis” to WG >>> Feb 2017 - submit “IP over DSRC (802.11-OCB)” to WG >>> Jun 2017 - submit “Solution for direction communication between >>> moving networks” to WG >>> Oct 2017 - start submitting to IESG >>> > From nobody Thu Apr 28 12:28:58 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58FA12D883 for ; Thu, 28 Apr 2016 12:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cjmng0ZmKhEB for ; Thu, 28 Apr 2016 12:28:54 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED27412D87A for ; Thu, 28 Apr 2016 12:28:53 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id y69so37614564pfb.1 for ; Thu, 28 Apr 2016 12:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=xof/u2mbxzEZ0yKOH7B0JbdZC21oG+gwDWO88ygRKVY=; b=w7ivr8FtwEGJKXiTXIbEBd3g77jl4gXtJrTVy/WQjd/kMEs0D+Vd3FKV4q4bFbInnl MLAMfpcEsJ2uuO1f0bo651msvICWzE4LBn+sx29yejpxOQDOdg72n51P3crpwgJ9Sphi D3GMs4xLnANBfTFPPLGLO7tBZu+IJhxVwQcQML3cWcNaTwH0AjGciX8eJjvRmDyixOtG ti/HidZ/YV1TbUuHcr4H8WlRgINtqpRxkSVhvOS0LNL5nsTstBu/7I62L4/UCrZ2+79+ G9WdTYz0k3iUZQiMaW3/WwXQqA95bEx7QgWrHN6xqTy8F1k2JUmmXVlKxWoAoGav3QkY nSRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=xof/u2mbxzEZ0yKOH7B0JbdZC21oG+gwDWO88ygRKVY=; b=YupzUlSkLFNqP2GsAd0GlFUedyFw4H0LiJ7EwSvCvlAHit6sqLkIBpAcVWvvxPF+NA v9OUtXnMmgShQTBxp4ZwiYUGLGrjZOylqQkYGnkHknMAuBFQY7mfekpsZdBW/5X6tN6W 3S48YFM1pIB/vY5ntPZelBTsa7jgi0AVxnbnY7opGVWk43t3LeDnAMJKkNpEJ1D/TWMD ShAopCtpLJNAU2RquyBwYUJC0wJLkbIKCIzyoJhWTHq5819YYiS3imk+o+22LJL185/z JkV9ns5CfCImAdDpgCf/eq7ELE/xVlQd9xGFxXz+PxbKM6HldwYnt6jIDdYv+2HApf7H K5Lw== X-Gm-Message-State: AOPr4FV+2kMPohMErC+lPeyr8UdL2++81FpjO1U135bi9PG+SIJNFHdQNGA5Ovj+J6hfsQ== X-Received: by 10.98.66.145 with SMTP id h17mr4763140pfd.100.1461871733509; Thu, 28 Apr 2016 12:28:53 -0700 (PDT) Received: from localhost.localdomain (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by smtp.gmail.com with ESMTPSA id 127sm17083581pfe.72.2016.04.28.12.28.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Apr 2016 12:28:52 -0700 (PDT) Message-ID: <1461871731.10373.198.camel@gmail.com> From: Rex Buddenberg To: Alexandre Petrescu , "Templin, Fred L" Date: Thu, 28 Apr 2016 12:28:51 -0700 In-Reply-To: <57225135.2040109@gmail.com> References: <571E06FF.9060404@gmail.com> <06cb15e70fe04a07abe10678600daf8a@XCH15-05-05.nw.nos.boeing.com> <571F26A9.80409@gmail.com> <6c5b616460dc4853b254fbd5645dff0b@XCH15-05-05.nw.nos.boeing.com> <57225135.2040109@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 19:28:57 -0000 Alex,  Fred gets a big +1.  Get the tunnel vision off. reasoning within: On Thu, 2016-04-28 at 20:06 +0200, Alexandre Petrescu wrote: > Hi Fred, > > This is very tempting. > > We know we must make technology that is applied in as many settings > as  > possible.  Aircraft are mobile platforms.  Automobiles are mobile platforms.   Indeed there are reasons for interoperability between them.  For example, a USCG helicopter with a casualty that it is med-evacing is functioning as an ambulance.  When it lands, the casualty is transferred to another ambulance, this mobile platform drives on the highways instead of flying, but the necessary vehicle-to-internet function is the same.   >  TCP works as much in my office PC as in that plane's server. slightly different subject -- beyond use case (but within scope). Some of the obsolescences of TCP get worse in any radio environment (timeouts, lack of early open, and inability to multicast).    > > However, at this time we have not yet identified L-DACS, AeroMACS > nor  > what is Iridium NEXT going to use next.  If they are routable networks, you don't need to.  (and if they're not, you can't) >  It's the first time we hear  > about them.  I suppose L-DACS is very different than 802.11p. A routable network can interconnect routers and that's what we need.  The specifics of these different radio-WANs are unimportant as long as they have the right interface at top of layer 2.   If a drone and an airliner are trying to occupy the same air space (one on the news last week in UK -- collision) they need to communicate with each other.  Expecting a transAtlantic airliner and a helicopter drone to have the same radio network is unrealistic.  What we need is that they both be routable networks so they can communicate with each other.  Singling up on a single radio network technology is exactly what we don't want to do and exactly what IP gets us away from. (There are a small handful of characteristics that differentiate a radio network from a wired one.  But all radio networks share them:   - shared medium -- radio.  Wired network plumbing is most often point-point (e.g. fiber).  This is blessing and curse: 1) the payoff to multicast increases and 2) the radio-WAN needs a MAC (DWDM, for example, doesn't).   - physics-limited capacity.  At about four orders of magnitude less than wired.  Further, the capacity is prorated across all the subscribers in the network segment.  ) > > I am tempted to believe that at this time we keep the air suggestion  > below as a very good perspective.  We will need to ask the chairs. > > Maybe when we're done with IP-over-DSRC and V2I/V2V documents then > we  > contemplate re-charter and study L-DACS more. > > (maybe until then we'll have cheap L-DACS cards, free L-DACS linux  > kernel drivers, and wireshark dissectors for L-DACS) > > (and are L-DACS, VHF, AeroMACS below IP directly between planes, or > is  > it something else between planes that may need IP) > The FAA has been mincing around the need to communicate between various entities (not just air traffic control) on the ground and aircraft, both on the ground and aloft.  ... for at least a quarter century.  They're still defaulting to voice radio (which unmanned aircraft can't do), English language and flight levels in feet.  1) the aircrraft sector needs, 2) interoperability between aircraft and other mobile platforms is a requirement. > Yours, > > Alex > > Le 28/04/2016 00:37, Templin, Fred L a écrit : > > > > Hi Alex, > > > > Here is some proposed text for the charter. Please let me know if > > this can be accommodated. > > > > Thanks - Fred > > --- > > The International Civil Aviation Organization (ICAO) is designing > > the > > Aeronautical Telecommunications Network for Internet Protocol > > Services (ATN-IPS) which will be based on IPv6 from its inception. > > IPv6 will run over various aviation data links including VHF data > > link, > > L-DACS, AeroMACS and several varieties of SATCOM (e.g., Inmarsat > > SwiftBroadBand, Iridium NEXT, etc.). Similarly, other aviation > > entities > > are considering air traffic management services for Unmanned Air > > Systems (UAS) as UAS proliferation within the global airspace > > continues. Air-to-air and air-to-ground IPv6-based communications > > are in scope for both manned and unmanned aviation. > > > > > > > > -----Original Message----- > > > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > > > Sent: Tuesday, April 26, 2016 1:28 AM > > > To: Templin, Fred L > > > Cc: its@ietf.org > > > Subject: Re: [its] latest charter text > > > > > > Le 25/04/2016 17:30, Templin, Fred L a écrit : > > > > > > > > Hi Alex, > > > > > > > > Will there be work items covering civil aviation and unmanned > > > > air system > > > > use cases? > > > Hi Fred, > > > > > > The aviation use-case was expressed at the mic during the BoF as > > > well. > > > > > > In my understanding, a use-case involving IP moving networks in > > > planes, > > > or in unmanned air systems, do make sense.  Because it is similar > > > to > > > drones docked on automobiles, which have been demonstrated often. > > > > > > However, the IESG suggestion is to focus now on ITS (V2V/V2I) and > > > IPv6 > > > over DSRC. > > > > > > For "later" (if successful with the above): > > > - are there use-cases of civil aviation and unmanned air systems > > > which > > >     involve DSRC; > > > - is civil aviation considering IPv6 in use-cases of Plane-to- > > > Ground or > > >     Plane-to-Plane communications. > > > - what is the name of links that are specific to civil aviation > > > and > > >     unmanned air systems and has IPv6 been run on it. > > > > > > Alex > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of > > > > *Alexandre Petrescu > > > > *Sent:* Monday, April 25, 2016 5:01 AM > > > > *To:* its@ietf.org > > > > *Subject:* [its] latest charter text > > > > > > > > ITSers, > > > > > > > > You will find below the latest charter text. > > > > > > > > It includes changes issued from discussions with Dick. > > > > > > > > Alex > > > > ------------------------------------------------------------- > > > > ------- > > > > Intelligent Transportation Systems (its) > > > > > > > > Chairs: > > > >      Russ Housley > > > >      Carlos Pignataro > > > > > > > > Assigned Area Director: > > > >      Suresh Krishnan > > > > > > > > Mailing list > > > >      Address: its@ietf.org > > > >      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 based on 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. > > > > > > > > In general, this group is concerned with situations involving > > > > moving > > > > network to nearby moving, or fixed, network communications > > > > (V2V, V2I, > > > > I2V).  For example: a moving network in a vehicle communicating > > > > to > > > > another moving network in a nearby vehicle (for C-ACC, > > > > Platooning, or > > > > at an incident scene); a personal area network carried by a > > > > user and > > > > connecting to an in-house fixed network (homenet); an in-car > > > > networked > > > > device receiving messages from a road-side display when passing > > > > by, > > > > wagon-to-wagon range extension in a train; train-to- > > > > intersection > > > > signalling.  In these loop-free 1-IP-hop topologies there is a > > > > problem > > > > of establishing IP paths quickly and reliably. > > > > > > > > Improved safety is an immediate result of hyper-connectivity of > > > > vehicles; as such public authorities worldwide are increasingly > > > > mandating secure communication technology requirements in > > > > vehicles. > > > > Emergency applications for instrumented ambulances carry many > > > > benefits > > > > both to the users and to society in general.  For these > > > > reasons, a > > > > solution to the problem of establishing IP paths between nearby > > > > moving > > > > networks will be resilient to threats such as eavesdropping. > > > > > > > > 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. > > > > > > > > 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. > > > > > > > > If the group is successful in designing a simple 1-IP-hop > > > > solution for > > > > V2V/V2I/I2V, and if deployments prove useful, in reasonable > > > > time, then > > > > future extensions for n-IP-hop V2V2I may be considered. > > > > > > > > Work items > > > > 1. "Problem statement for IP in V2V and V2I" > > > >      including "IP addressing architecture for V2V and V2I" > > > >      and including "Gap Analysis: IP protocols suited and gaps" > > > >      and including "Use-cases for IP in V2V and V2I moving > > > > network > > > >      To nearby moving or fixed network" > > > > > > > > 2. "Threat Analysis for IP prefix exchanges in V2V and V2I > > > >      Context" > > > > > > > > 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document, > > > >      including connectivity in fast and asymmetric conditions, > > > >      Coverage area vs speed diagrams, below-IP congestion > > > >      management. > > > > > > > > 4. "List of papers and _products_ using IP in V2V and V2I" > > > > > > > > 5. "Solution for direct communication between moving networks" > > > > > > > > Goals and milestones > > > > Oct 2016 - submit “Problem Statement” to WG > > > > Oct 2016 - submit “List of papers and products” to WG > > > > Feb 2017 - submit “Threat Analysis” to WG > > > > Feb 2017 - submit “IP over DSRC (802.11-OCB)” to WG > > > > Jun 2017 - submit “Solution for direction communication between > > > >                      moving networks” to WG > > > > Oct 2017 - start submitting to IESG > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Thu Apr 28 12:37:07 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFB312D8F7 for ; Thu, 28 Apr 2016 12:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJwsFFpIPE79 for ; Thu, 28 Apr 2016 12:37:04 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CD012D967 for ; Thu, 28 Apr 2016 12:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3006; q=dns/txt; s=iport; t=1461872217; x=1463081817; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0AjwMPeL97qHH7gT0dQRR3FFCcfSShCugg24/S5obfY=; b=EkoC30Ufb0lWTRafaV2SAulbqx0HLSETOfN1wG76cnBQ7TlCp8ugaA/G tW141Qv6m8J4Zcnemz0S1trWsn6ZQpu7wwM4sViVHkkfhEhQl6wVZKfWg 7XQXA04T+sEiSYS0Bq3EHdp9G2L27JlXnrfG8Mgo8INIDXqIQMBthv6iq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgC7ZSJX/49dJa1egzhTfQa5WgENg?= =?us-ascii?q?XYXC4VtAoEsOBQBAQEBAQEBZSeEQgEBBAEBARVWBBcCAQgOBAYuJwsXDgIEARK?= =?us-ascii?q?IFQMSDsN4AQEBAQEBAQEBAQEBAQEBAQEBFASGIYNJgQKCQYdSBZgQAY4WjxGPL?= =?us-ascii?q?wEeAQFCg2tshml/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,548,1454976000"; d="scan'208";a="267454263" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2016 19:36:56 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u3SJauN9030817 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 19:36:56 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 14:36:55 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 14:36:55 -0500 From: "Sri Gundavelli (sgundave)" To: Charlie Perkins , Russ Housley , "its@ietf.org" Thread-Topic: [its] ITS Charter Discussion Thread-Index: AQHRnvJN9zxCDhzlgEqUNSJBYueuNZ+gAO6A//+qSoA= Date: Thu, 28 Apr 2016 19:36:55 +0000 Message-ID: References: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.219] Content-Type: text/plain; charset="Windows-1252" Content-ID: <452BA59677D5AB47B3208891DAAE8BB5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 19:37:06 -0000 I=B9ve similar feedback. This proposed charter sounds reasonable to me. This is an important problem area and the timing is just perfect given the current industry efforts around self driving cars. IETF can push adoption of IETF protocols into these architecture and a focussed WG can really help in that aspect. Sri On 4/28/16, 10:43 AM, "its on behalf of Charlie Perkins" wrote: >Hello folks, > >I think this outline for a charter is reasonable. The informational RFC >as proposed has a very broad scope, so it would need to be envisioned >more as a survey article but aimed at supporting a problem statement. >Perhaps there could be two Informational RFCs: > >One Informational RFC that covers: > - What is ITS? > =8B Explain V2V, V2I, and so on (including terminology) > - Why is IPv6 needed? > =8B Explain why some traffic will not use IPv6 > =8B Explain why other traffic will use IPv6 > - Use-cases, illustrating the expected areas for initial focus > - Informative references, relationship with other SDOs > > >Another Informational RFC that covers: > - Problem statement > - Security considerations > - Privacy considerations > > >The security and privacy considerations are themselves closely related, >and crucial to the problem statement. > >I think the general problem area is very important and that the IETF has >a great deal to offer. This is especially true given current efforts >towards self-driving cars, which seem very likely to place urgent >demands on networking protocols. I don't have deployment experience or >any immediate plans for implementation, but I do also work with IEEE 802 >Wireless and I think that will provide a useful alternative perspective. > >Regards, >Charlie P. > >On 4/25/2016 5:59 AM, Russ Housley wrote: >> Carlos and I had a telephone conversation with our Area Director for >>this group, Suresh Krishnan. The result of the discussion was some >>pretty clear and pragmatic suggestions about the charter. >> >> The suggestion is that the ITS WG have only two deliverables in the >>initial charter. Once these two documents are delivered to the IESG, >>then the group can recharter to tackle other things. >> >> An Informational RFC that covers: >> - What is ITS? >> =8B Explain V2V, V2I, and so on >> - Why is IPv6 needed? >> =8B Explain why some traffic will not use IPv6 >> =8B Explain why other traffic will use IPv6 >> - Problem statement >> - Use-cases >> - Security considerations >> - Privacy considerations >> >> A Standards-Track RFC that covers: >> - IPv6 over DSRC >> >> Russ >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > >_______________________________________________ >its mailing list >its@ietf.org >https://www.ietf.org/mailman/listinfo/its From nobody Thu Apr 28 14:23:43 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583ED12D573 for ; Thu, 28 Apr 2016 14:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjRGMUtxIj0P for ; Thu, 28 Apr 2016 14:23:40 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9539212D0A6 for ; Thu, 28 Apr 2016 14:23:39 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id n129so4964223wmn.1 for ; Thu, 28 Apr 2016 14:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=MNrSAkWN79M4YPZLiU8QECMp+lEnUqSPHz7eIVQ127k=; b=o3ZLUTUa8qV0ZtZkGoPUrDp2wRh2hnbsxwdHRmQjci7VeTMMTe3UKyTq94bG+3Urx3 brRDGLfeIA6129XiWNKafn1MkuWpTjLZBMi7GsG2Ea0vB6YFnc6Zbr2YsZ9gYl1a1sn5 7eN/h32VwT8y28ldT764B6Yz2SMCoeMmTN1EtAs48KbCkgSuIzM1ESwpa66A6T+IsDu5 bS6UnkDgsS8KueNzMNl3/9t9XnLNpi9IWXE/HKCOExC/B80k8AozIaBbd2DzChH78kKZ /Ff5rZyeFecqbD7VbmvwjDw6ZLuw5hOrTfuED03JY+v+ddGyhIcPkOKoiq1Sh9OcbHLm KLdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=MNrSAkWN79M4YPZLiU8QECMp+lEnUqSPHz7eIVQ127k=; b=FQSLY2aSbbftr0iipX6B9xjvA0OtOc+03lS0Mq+DQkIy7UFkvLDN3P1MNX/DViVP8t w+yrOr3DBD/o6kWCrH8Fv3dPAA3eLZWDOM9kxIMilwX+gx3C9oBbGyEBjGXVc4Qk0AGB uHX0dJ0+laq6ybpDyy48XlH7wf5hpEd4CRHYUQA5bppgRcVtCjNMz2pi2B5j/OjRnjgs Q4s80YSYDptndof32XrM6JDOt1iNCJtZF/iiRbr8x5pRbtABsVTZuotZYzCs4vYLoOuH 8cZ528hISXcayRhjXpwttoyEJXoimRSil1kR2hZX/N+56Ssmy93013HQC0WdufAElAB6 sWmQ== X-Gm-Message-State: AOPr4FXAk3f+XEZOvAWa5HIh3Fg+Zt9Vv6UnJnnV8ty2qOHK9ISV1e6jwYRnCwhq4ykTvZIzU3Xd9qCR7tsJtA== MIME-Version: 1.0 X-Received: by 10.194.90.76 with SMTP id bu12mr17672524wjb.79.1461878618063; Thu, 28 Apr 2016 14:23:38 -0700 (PDT) Received: by 10.28.13.84 with HTTP; Thu, 28 Apr 2016 14:23:37 -0700 (PDT) In-Reply-To: References: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> Date: Thu, 28 Apr 2016 22:23:37 +0100 Message-ID: From: Nabil Benamar To: "Sri Gundavelli (sgundave)" Content-Type: multipart/alternative; boundary=047d7bf0d2c4bc0de0053192231a Archived-At: Cc: Charlie Perkins , Russ Housley , "its@ietf.org" Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 21:23:42 -0000 --047d7bf0d2c4bc0de0053192231a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, It's has been a while since we have started to exchange ideas in this mailing list ( as a non-WG list) and I think that the charter is good for the formation of ITS as a WG. I'm also interested in working on V2I and V2V aspects. Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Thu, Apr 28, 2016 at 8:36 PM, Sri Gundavelli (sgundave) < sgundave@cisco.com> wrote: > I=C2=B9ve similar feedback. This proposed charter sounds reasonable to me= . > This is an important problem area and the timing is just perfect given th= e > current industry efforts around self driving cars. IETF can push adoption > of IETF protocols into these architecture and a focussed WG can really > help in that aspect. > > > > Sri > > > > On 4/28/16, 10:43 AM, "its on behalf of Charlie Perkins" > wrote: > > >Hello folks, > > > >I think this outline for a charter is reasonable. The informational RFC > >as proposed has a very broad scope, so it would need to be envisioned > >more as a survey article but aimed at supporting a problem statement. > >Perhaps there could be two Informational RFCs: > > > >One Informational RFC that covers: > > - What is ITS? > > =E2=80=B9 Explain V2V, V2I, and so on (including terminology) > > - Why is IPv6 needed? > > =E2=80=B9 Explain why some traffic will not use IPv6 > > =E2=80=B9 Explain why other traffic will use IPv6 > > - Use-cases, illustrating the expected areas for initial focus > > - Informative references, relationship with other SDOs > > > > > >Another Informational RFC that covers: > > - Problem statement > > - Security considerations > > - Privacy considerations > > > > > >The security and privacy considerations are themselves closely related, > >and crucial to the problem statement. > > > >I think the general problem area is very important and that the IETF has > >a great deal to offer. This is especially true given current efforts > >towards self-driving cars, which seem very likely to place urgent > >demands on networking protocols. I don't have deployment experience or > >any immediate plans for implementation, but I do also work with IEEE 802 > >Wireless and I think that will provide a useful alternative perspective. > > > >Regards, > >Charlie P. > > > >On 4/25/2016 5:59 AM, Russ Housley wrote: > >> Carlos and I had a telephone conversation with our Area Director for > >>this group, Suresh Krishnan. The result of the discussion was some > >>pretty clear and pragmatic suggestions about the charter. > >> > >> The suggestion is that the ITS WG have only two deliverables in the > >>initial charter. Once these two documents are delivered to the IESG, > >>then the group can recharter to tackle other things. > >> > >> An Informational RFC that covers: > >> - What is ITS? > >> =E2=80=B9 Explain V2V, V2I, and so on > >> - Why is IPv6 needed? > >> =E2=80=B9 Explain why some traffic will not use IPv6 > >> =E2=80=B9 Explain why other traffic will use IPv6 > >> - Problem statement > >> - Use-cases > >> - Security considerations > >> - Privacy considerations > >> > >> A Standards-Track RFC that covers: > >> - IPv6 over DSRC > >> > >> Russ > >> _______________________________________________ > >> its mailing list > >> its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > >> > > > >_______________________________________________ > >its mailing list > >its@ietf.org > >https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --047d7bf0d2c4bc0de0053192231a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

It's has been a while since we = have started to exchange ideas in this mailing list ( as a non-WG list) and= I think that the charter is good for the formation of ITS as a WG.=C2=A0
I'm also interested in working on V2I and = V2V aspects.


On Thu, Apr 28, 2016 at 8:36 PM, Sri Gundave= lli (sgundave) <sgundave@cisco.com> wrote:
I=C2=B9ve similar feedback. This proposed charter sounds = reasonable to me.
This is an important problem area and the timing is just perfect given the<= br> current industry efforts around self driving cars. IETF can push adoption of IETF protocols into these architecture and a focussed WG can really
help in that aspect.



Sri



On 4/28/16, 10:43 AM, "its on behalf of Charlie Perkins"
<its-bounces@ietf.org on behalf of charles.perkins@earthlink.net> wrote:

>Hello folks,
>
>I think this outline for a charter is reasonable.=C2=A0 The information= al RFC
>as proposed has a very broad scope, so it would need to be envisioned >more as a survey article but aimed at supporting a problem statement. >Perhaps there could be two Informational RFCs:
>
>One Informational RFC that covers:
>=C2=A0 - What is ITS?
>=C2=A0 =C2=A0 =C2=A0=E2=80=B9 Explain V2V, V2I, and so on (including te= rminology)
>=C2=A0 - Why is IPv6 needed?
>=C2=A0 =C2=A0 =C2=A0=E2=80=B9 Explain why some traffic will not use IPv= 6
>=C2=A0 =C2=A0 =C2=A0=E2=80=B9 Explain why other traffic will use IPv6 >=C2=A0 - Use-cases, illustrating the expected areas for initial focus >=C2=A0 - Informative references, relationship with other SDOs
>
>
>Another Informational RFC that covers:
>=C2=A0 - Problem statement
>=C2=A0 - Security considerations
>=C2=A0 - Privacy considerations
>
>
>The security and privacy considerations are themselves closely related,=
>and crucial to the problem statement.
>
>I think the general problem area is very important and that the IETF ha= s
>a great deal to offer. This is especially true given current efforts >towards self-driving cars, which seem very likely to place urgent
>demands on networking protocols. I don't have deployment experience= or
>any immediate plans for implementation, but I do also work with IEEE 80= 2
>Wireless and I think that will provide a useful alternative perspective= .
>
>Regards,
>Charlie P.
>
>On 4/25/2016 5:59 AM, Russ Housley wrote:
>> Carlos and I had a telephone conversation with our Area Director f= or
>>this group, Suresh Krishnan.=C2=A0 The result of the discussion was= some
>>pretty clear and pragmatic suggestions about the charter.
>>
>> The suggestion is that the ITS WG have only two deliverables in th= e
>>initial charter.=C2=A0 Once these two documents are delivered to th= e IESG,
>>then the group can recharter to tackle other things.
>>
>> An Informational RFC that covers:
>>=C2=A0 =C2=A0- What is ITS?
>>=C2=A0 =C2=A0 =C2=A0 =E2=80=B9 Explain V2V, V2I, and so on
>>=C2=A0 =C2=A0- Why is IPv6 needed?
>>=C2=A0 =C2=A0 =C2=A0 =E2=80=B9 Explain why some traffic will not us= e IPv6
>>=C2=A0 =C2=A0 =C2=A0 =E2=80=B9 Explain why other traffic will use I= Pv6
>>=C2=A0 =C2=A0- Problem statement
>>=C2=A0 =C2=A0- Use-cases
>>=C2=A0 =C2=A0- Security considerations
>>=C2=A0 =C2=A0- Privacy considerations
>>
>> A Standards-Track RFC that covers:
>>=C2=A0 =C2=A0- IPv6 over DSRC
>>
>> Russ
>> _______________________________________________
>> its mailing list
>> its@ietf.org
>> https://www.ietf.org/mailman/listinfo/its
>>
>
>_______________________________________________
>its mailing list
>its@ietf.org
>https://www.ietf.org/mailman/listinfo/its

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

--047d7bf0d2c4bc0de0053192231a-- From nobody Fri Apr 29 09:26:00 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676AD12D1BB for ; Fri, 29 Apr 2016 09:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnVF-QBpx9bc for ; Fri, 29 Apr 2016 09:25:55 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2E312D0B8 for ; Fri, 29 Apr 2016 09:25:55 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id 206so50230127pfu.0 for ; Fri, 29 Apr 2016 09:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=p1CVxuZWND1YnQNQAslvxeJFgpjft/bdlQnfAYlW4nE=; b=OPQ+SptsapcDC8DKSmwfvlhEI2k50p27/Zu/Bezy3VnYfq239bUjBPPtF1e9+jPSNb dmn5wfK3jSL94vAw3VmlKtrQgdeaQZDOvUZp/rzxb3yuTFQ2MVgpVMK9OV+hGPK455I8 rNS47vzjj505H5KRZN6jo42MF6SfgAm02TlCYuAXFQBOsJhEu5nlO9PdEivA4zxaqwfL 05AHT0iswuB7sVcRihR7AN5TUZYLeZkaMpy890CRqhCK8yTSRoKSf3/d9nUhTrMEXuLs ATacEpjCc/DDkzYmJz+3pChzkxzbdRMD0b796Y3q0dcsTYQ38fJ8ZgSznU4EZ+QMUhN+ XcHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=p1CVxuZWND1YnQNQAslvxeJFgpjft/bdlQnfAYlW4nE=; b=BCIjcv5aPu5MRxvaRsl8gxoOxqnW6LLc+jlcYHGUpZ3D2Gt45jM7NPEv5EGhRbnNN9 C9JHszQVUePYh7awEWRZFBZsZndGWoDBzu3ppVKISrbFZ4LUYUA4eckkDZtl0kPt3A1i CHtZtuJZf/qQNtQekRJQxohGUXzzFgwQEN4vvRu7rZhC9Kmb0Amg6ODmZpwuvMpk9JA+ N7oJKzKxSpV8LWkuDlz1+6ZQna+xPTj+bXZqVicEUkgbt+BSxHdNRt7xeR3JhAx1awsC IkOZUyd0Az8JW2/79RwxE1rxnSFQBVJfwd4VtN4FE9SgiFUKQSLFE1P7Y3vvu29OO0CR rAHw== X-Gm-Message-State: AOPr4FW49wqq2uotzPQhqSEAk4QYaVLD6jcTSI0x+zhv8derUnb4t+C3XwpnLskR9Kts9Q== X-Received: by 10.98.33.207 with SMTP id o76mr30204667pfj.80.1461947154702; Fri, 29 Apr 2016 09:25:54 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id 87sm24541111pfq.93.2016.04.29.09.25.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2016 09:25:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: <8385.1461611347@obiwan.sandelman.ca> Date: Fri, 29 Apr 2016 09:25:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> <8385.1461611347@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Russ Housley , its@ietf.org Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 16:25:57 -0000 I like and support the charter as well. Simple is better and keeps = focus. Thanks, Dino > On Apr 25, 2016, at 12:09 PM, Michael Richardson = wrote: >=20 >=20 > Russ Housley wrote: >> Carlos and I had a telephone conversation with our Area Director for >> this group, Suresh Krishnan. The result of the discussion was some >> pretty clear and pragmatic suggestions about the charter. >=20 >> The suggestion is that the ITS WG have only two deliverables in the >> initial charter. Once these two documents are delivered to the IESG, >> then the group can recharter to tackle other things. >=20 > This charter sounds reasonable to me. > Do we have enough participation from non-IETF ITS-types to actually = get this > done? (I mean, other than Alex P) >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Fri Apr 29 11:22:00 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4946112D1BB for ; Fri, 29 Apr 2016 11:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEHwt_jiV4Gx for ; Fri, 29 Apr 2016 11:21:56 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF05E12D6A5 for ; Fri, 29 Apr 2016 11:21:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u3TIM5K7030640; Fri, 29 Apr 2016 11:22:05 -0700 Received: from XCH15-05-03.nw.nos.boeing.com (xch15-05-03.nw.nos.boeing.com [137.137.100.66]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u3TIM0Jv030620 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 29 Apr 2016 11:22:00 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-03.nw.nos.boeing.com (2002:8989:6442::8989:6442) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 29 Apr 2016 11:21:49 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 29 Apr 2016 11:21:49 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , "its@ietf.org" Thread-Topic: [its] latest charter text Thread-Index: AQHRn7wxD0zPM4Y86k2Lvn9a/gJsy5+hSApQ Date: Fri, 29 Apr 2016 18:21:49 +0000 Message-ID: References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> In-Reply-To: <571F6758.4050402@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 18:21:57 -0000 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. Thanks - Fred From nobody Fri Apr 29 11:43:31 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EED512D6F6 for ; Fri, 29 Apr 2016 11:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IMZc6BW0wPw for ; Fri, 29 Apr 2016 11:43:27 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5771A12D4FB for ; Fri, 29 Apr 2016 11:43:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u3TIha8Y024921; Fri, 29 Apr 2016 11:43:36 -0700 Received: from XCH15-05-01.nw.nos.boeing.com (xch15-05-01.nw.nos.boeing.com [137.137.100.58]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u3TIhXpU024906 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 29 Apr 2016 11:43:34 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-01.nw.nos.boeing.com (2002:8989:643a::8989:643a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 29 Apr 2016 11:43:23 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 29 Apr 2016 11:43:23 -0700 From: "Templin, Fred L" To: Russ Housley , "its@ietf.org" Thread-Topic: [its] ITS Charter Discussion Thread-Index: AQHRnvJOJQuKeX0iSEOgfW4n5wNLXJ+hTo7w Date: Fri, 29 Apr 2016 18:43:23 +0000 Message-ID: <97474893d4e445fda9035372296fab20@XCH15-05-05.nw.nos.boeing.com> References: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> In-Reply-To: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 18:43:29 -0000 Hi Russ, I would like to see the following added to the charter text: > 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. AERO is in advanced stages of development and has been discussed in the DMM working group among other IETF working groups. There is a proof of concept implementation, with work ongoing to develop production code. It is an IPv6 mobility management and route optimization solution specifically geared toward aeronautical applications but also applicable to any manner of vehicular communications. Please let me know if this addition can be accommodated. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Monday, April 25, 2016 5:59 AM > To: its@ietf.org > Subject: [its] ITS Charter Discussion >=20 >=20 > Carlos and I had a telephone conversation with our Area Director for this= group, Suresh Krishnan. The result of the discussion was > some pretty clear and pragmatic suggestions about the charter. >=20 > The suggestion is that the ITS WG have only two deliverables in the initi= al charter. Once these two documents are delivered to the > IESG, then the group can recharter to tackle other things. >=20 > An Informational RFC that covers: > - What is ITS? > - Explain V2V, V2I, and so on > - Why is IPv6 needed? > - Explain why some traffic will not use IPv6 > - Explain why other traffic will use IPv6 > - Problem statement > - Use-cases > - Security considerations > - Privacy considerations >=20 > A Standards-Track RFC that covers: > - IPv6 over DSRC >=20 > Russ > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Fri Apr 29 15:15:58 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6E212B034 for ; Fri, 29 Apr 2016 15:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJOLI7EkADWI for ; Fri, 29 Apr 2016 15:15:54 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id BD2DE12B015 for ; Fri, 29 Apr 2016 15:15:54 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id F274DF2404B; Fri, 29 Apr 2016 18:15:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id sYCQEO2S7oLe; Fri, 29 Apr 2016 17:59:41 -0400 (EDT) Received: from [172.20.1.174] (c-73-99-75-174.hsd1.va.comcast.net [73.99.75.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 58C33F24036; Fri, 29 Apr 2016 18:15:43 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <97474893d4e445fda9035372296fab20@XCH15-05-05.nw.nos.boeing.com> Date: Fri, 29 Apr 2016 18:15:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F9B28DE-6145-409D-B41E-52790AC3B191@vigilsec.com> References: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> <97474893d4e445fda9035372296fab20@XCH15-05-05.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 22:15:57 -0000 Fred: I do not have a huge objection is being expanded if the people that know = about AERO are going to engage. If they are here, they have been = silent. Russ On Apr 29, 2016, at 2:43 PM, Templin, Fred L = wrote: > Hi Russ, >=20 > I would like to see the following added to the charter text: >=20 >> Co-existence with techniques of infrastructure mobility management = will >> be coordinated with the DMM Working Group and with LISP Working = Group. >=20 > Add to this: >=20 > Other infrastructure mobility management solutions such as AERO will > also be considered. >=20 > AERO is in advanced stages of development and has been discussed in > the DMM working group among other IETF working groups. There is a > proof of concept implementation, with work ongoing to develop = production > code. It is an IPv6 mobility management and route optimization = solution > specifically geared toward aeronautical applications but also = applicable > to any manner of vehicular communications. >=20 > Please let me know if this addition can be accommodated. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Russ Housley >> Sent: Monday, April 25, 2016 5:59 AM >> To: its@ietf.org >> Subject: [its] ITS Charter Discussion >>=20 >>=20 >> Carlos and I had a telephone conversation with our Area Director for = this group, Suresh Krishnan. The result of the discussion was >> some pretty clear and pragmatic suggestions about the charter. >>=20 >> The suggestion is that the ITS WG have only two deliverables in the = initial charter. Once these two documents are delivered to the >> IESG, then the group can recharter to tackle other things. >>=20 >> An Informational RFC that covers: >> - What is ITS? >> - Explain V2V, V2I, and so on >> - Why is IPv6 needed? >> - Explain why some traffic will not use IPv6 >> - Explain why other traffic will use IPv6 >> - Problem statement >> - Use-cases >> - Security considerations >> - Privacy considerations >>=20 >> A Standards-Track RFC that covers: >> - IPv6 over DSRC >>=20 >> Russ >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >=20 >=20