Hi ITS Colleagues,

Title: Pr= oblem Statement for Vehicle-to-Infrastructure Networking

I-D: dra= ft-jeong-its-v2i-problem-statement-00

Link: https://tools.i= etf.org/html/draft-jeong-its-v2i-problem-statement-00

Abstract

=C2=A0 =C2=A0This document specifies the problem= statement for IPv6-based vehicle-

=C2=A0 =C2=A0to-infrastructure= networking.=C2=A0 Dedicated Short-Range Communications

=C2=A0 = =C2=A0(DSRC) is standardized as IEEE 802.11p for the wireless media access<= /div>

=C2=A0 =C2=A0in vehicular networks.=C2=A0 This document addresses= the extension of IPv6

=C2=A0 =C2=A0as the network layer protocol= in vehicular networks and is focused on

=C2=A0 =C2=A0the network= ing issues in one-hop communication between a Road-Side

=C2=A0 = =C2=A0Unit (RSU) and vehicle.=C2=A0 The RSU is connected to the Internet an= d

=C2=A0 =C2=A0allows vehicles to have the Internet access if con= nected.=C2=A0 The major

=C2=A0 =C2=A0issues of including IPv6 in = vehicular networks are neighbor discovery

=C2=A0 =C2=A0protocol, = stateless address autoconfiguration, and DNS configuration

=C2=A0= =C2=A0for the Internet connectivity over DSRC.=C2=A0 Also, when the vehicl= e and

=C2=A0 =C2=A0the RSU have an internal network, respectively= , the document

=C2=A0 =C2=A0discusses the issues of internetworki= ng between the vehicle's

=C2=A0 =C2=A0internal network and th= e RSU's internal network.

If you have comments= or questions, please let me know.

Thanks.

Best Regards,

Paul

--=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 Pr= ofessor
Department of Software
Sungkyunkwan 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

--94eb2c0c088cc897a4052bd18ae6-- From nobody Wed Feb 17 04:21:55 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674DC1B3697 for ; Wed, 17 Feb 2016 04:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 Elh0ACQ7mj8X for ; Wed, 17 Feb 2016 04:21:50 -0800 (PST) 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 479AC1ACE02 for ; Wed, 17 Feb 2016 04:21:50 -0800 (PST) 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 u1HCLlbe020322; Wed, 17 Feb 2016 13:21:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7A8B42077C3; Wed, 17 Feb 2016 13:30:14 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6D6CF20342F; Wed, 17 Feb 2016 13:30:14 +0100 (CET) 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 u1HCLlce024827; Wed, 17 Feb 2016 13:21:47 +0100 To: "Mr. Jaehoon Paul Jeong" References: From: Alexandre Petrescu Message-ID: <56C465DB.8060305@gmail.com> Date: Wed, 17 Feb 2016 13:21:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.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] Comments for a New Draft of Problem Statement for V2I Networking X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 12:21:53 -0000 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 �crit : > 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 contain 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 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 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 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 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 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 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 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 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 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 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 -- =========================== 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 Wed Feb 17 10:36:15 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE411A8905 for ; Wed, 17 Feb 2016 10:36:13 -0800 (PST) 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 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 kSRZLAs5GNiH for ; Wed, 17 Feb 2016 10:36:09 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id BEAE61A1A28 for ; Wed, 17 Feb 2016 10:36:08 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 59640F9C013; Wed, 17 Feb 2016 13:36:08 -0500 (EST) 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 gRYTkD9ycYBz; Wed, 17 Feb 2016 13:34:59 -0500 (EST) Received: from [192.168.2.104] (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 4604AF9C01C; Wed, 17 Feb 2016 13:36:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-3-685596059 From: Russ Housley In-Reply-To: <56C1D0AB.3020006@gmail.com> Date: Wed, 17 Feb 2016 13:36:05 -0500 Message-Id: <8B07B35E-3FE8-4B1E-9017-7A2E34B320F3@vigilsec.com> References: <56C1D0AB.3020006@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.1085) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] Updated charter - please comment X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 18:36:13 -0000 --Apple-Mail-3-685596059 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alex: Below are my comments on the proposed charter text. Russ > = ----------------------------------------------------------------------- >=20 > ITS (name to change) > Charter > February 15th, 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 protocols for establishing > direct and secure connectivity between moving networks. >=20 > Moving Network to Moving Network Communications > ----------------------------------------------- > The group is concerned with all situations involving moving network to > 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. Entertainment apps enhancing comfort, reliable data > exchanges for road safety, and automated driving, are commonly seen as Editorial: s/automated driving, are/automated driving are/ > winning sale arguments for automobiles to hit the roads from now to > year 2020. Emergency apps for new instrumented ambulances carry many > benefits both to the users and to society in general. I think that the "winning sales arguments" is not needed here. Instead, = I think it would be valuable to say that these features are coming, and that the = safety features are expected to become required. >=20 > Why IP? > ------- > Whereas the Vehicle-to-Internet technologies are considered completed > and deployed in automobiles currently on the roads (e.g. car tethering > through driver's cellular smartphone, live traffic data displayed on > the dashboard, - use of NAT/DHCP and potentially Mobile IP), the > Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are > still in an infancy stage: primitive link-specific data exchanges are > limited to a non-harmonized set of applications, such as ETSI's > CAM/DENM presence signalling; worse, some link-specific messages > exhibit behaviour assimilated to IP behaviour but the systems are > incompatible with the Internet without involving specific gatewaying. > The industry needs to employ IP data exchanges between vehicles, and > between vehicles and the immediate infrastructure, rather than > link-specific exchanges, in order to benefit from advantages such as > (1) short delays, (2) fast forwarding through short paths of dumb > routers (2) ease of reusing of a huge number of a desktop Internet > applications in a vehicular environment (extend the Internet to mobile > platforms). I think this paragraph take too long to get to the main point, which is why IP is a goog thing in this environment. I suggest: 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 avoid 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 (1) short delays, (2) fast forwarding through short paths of routers, (3) ease of reuse of existing Internet applications in a vehicular environment. >=20 > Moving network to moving network communications involve link layers Add "nearby" here. I think it is important to the scope. > such as: 802.11 OCB, 802.15.4 with 6lowpan, 802.11ac, VLC (Visible > Light Communications), IrDA, LTE-D. Only the IP protocols are capable s/802.11 OCB/802.11p OCB (Outside the Context of a BSS)/ > 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 moving network communications are of two kinds: IP routing Add "nearby" here. I think it is important to the scope. > 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). My understanding from the phone call was that we were going to focus on = the 1-hop protocols in this proposed working group, but leverage work from other = groups for the n-hop situation. I think we need to say something here about the duration of some of the = communications. a vehicle traveling at 80 Km/h is not going to have communications with = a roadside device for very long. >=20 > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to moving network Add "nearby" here. I think it is important to the scope. > 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 moving network applications Add "nearby" here. I think it is important to the scope. > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the > 1-hop IP moving network to 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 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 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 version of the IP protocol is IPv6 (witness 10% IPv6 penetration > as of early 2016, mobile operators evolving to IPv6-only, government > IPv6 push, IPv4 exhaust at RIRs); this acommodates the current > generation of Internet protocols. For backwards compatibility, IPv4 > may be considered as well, but not exclusively. Link-local IPv6 > addresses will be used. This it too long. Just say that the groups will only work on IPv6 = solutions. >=20 > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to 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 moving network communications > - Problem Statement for moving network to moving network = communications > - Security and Privacy Requirements for moving network to > moving network communications > - Problem Statement for moving network to infrastructure network > communications, including DNS > - Potentially new protocol, or protocol extensions for establishing IP > paths for 1-hop moving network to moving network communications. > With MIB and security. > - IPv6-over foo, where foo is pertinent for moving network to moving > network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) >=20 > Timeline > -------- > - >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail-3-685596059 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii =20 =20

= -----------------------------------------------------------------------
        =      ITS (name to change)
            =        Charter
            = February 15th, 2016
        http://ietf.org/mailman/list= info/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/ma= ilman/listinfo/its
   Archive:
   ht= tp://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 protocols for establishing
direct and secure connectivity between moving networks.

Moving Network to Moving Network Communications
-----------------------------------------------
The group is concerned with all situations involving moving network to
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. Entertainment apps enhancing comfort, reliable = data
exchanges for road safety, and automated driving, are commonly seen as

Editorial: = s/automated driving, are/automated driving = are/

Hi Alex,

Thanks for your valuable comments.

I will address your comments on 01 version.

Thanks.

Best Regards,

Paul

On Wed, Fe= b 17, 2016 at 9:21 PM, Alexandre Petrescu <alexandre.petrescu@g= mail.com> wrote:

Hello Pa= ul,

Thanks a lot for this draft.=C2=A0 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/draf= t-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 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.=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 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 t= o 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?<= br>
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 name
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 networks&quo= t;:

Problems are a prefix discovery and prefix exchange.=C2=A0 The prefix
discovery is defined as how routers in a mobile network discover
prefixes in the mobile network.=C2=A0 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 with
the prefixes inside that moving network.=C2=A0 If so, then there can be no<= br> 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".= =C2=A0 These
parameters, including the IP prefix of the other network, are listed in
draft-petrescu-its-problem-01 section 3.1 "Discovery Sub-Problem"= .=C2=A0 It
would be good to use same terminology for this discovery.

This section discusses IP addressing for V2I networking.=C2=A0 There 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 would= be appropriate to mention "Unique Local Addresses" (ULAs) which = can somehow play the role that seems to be needed here.=C2=A0 I suggest to = substitute ULA for site-local addresses.

The former approach is
=C2=A0 =C2=A0usually used by Mobile Ad Hoc Networks (MANET) for a separate = multi-
=C2=A0 =C2=A0link subnet.

MANET has a certain meaning at IETF: it's the WG MANET.=C2=A0 I dont th= ink there is any MANET draft that recommends ULAs (but maybe they recommend= site-locals?).=C2=A0 Maybe ask the MANET WG what is the MANET IP Addressin= g Architecture (do they use ULAs?=C2=A0 do they use GUA - globals?).=C2=A0 = 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.=C2=A0 IP Mobility Support

=C2=A0 =C2=A0This section discusses an IP mobility support in V2I networkin= g.=C2=A0 In
=C2=A0 =C2=A0a single subnet per RSU, vehicles keep crossing the communicat= ion
=C2=A0 =C2=A0coverages of adjacent RSUs.=C2=A0 During this crossing, TCP/UD= P sessions
=C2=A0 =C2=A0can be maintained through IP mobility support, such as Mobile = IPv6
=C2=A0 =C2=A0[RFC6275].=C2=A0 Since vehicles move fast along roadways, this= high speed
=C2=A0 =C2=A0should be configured for a parameter configuration in Mobile I= Pv6.

=C2=A0 =C2=A0To support the mobility of a vehicle's mobile network, Net= work
=C2=A0 =C2=A0Mobility (NEMO) protocol can be used [RFC3963].=C2=A0 Like Mob= ile IPv6,
=C2=A0 =C2=A0the high speed of vehicles should be considered for a paramete= r
=C2=A0 =C2=A0configuration 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=A0the RSU infra-node a tunnel is established between the MR and = its
=C2=A0 =C2=A0Home Agent in the TCC (Traffic Control Center).=C2=A0 If a nod= e inside
=C2=A0 =C2=A0the moving network (not the MR) needs to exchange data with a = node
=C2=A0 =C2=A0within the RSU infra-node network then that communication must=
=C2=A0 =C2=A0go through the Home Agent.=C2=A0 The delays on the path to the= HA may be
=C2=A0 =C2=A0too high for the reactivity needed between a vehicle and an RS= U, or
=C2=A0 =C2=A0the path can even be blocked.=C2=A0 For this reason it is nece= ssary to
=C2=A0 =C2=A0accommodate direct communications (skip the HA) between a node= in
=C2=A0 =C2=A0the moving network and a node in the RSU infra-node network.= =C2=A0 This
=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=A0infra-node network may lead to modifying the addressing archit= ecture
=C2=A0 =C2=A0in the moving network.=C2=A0 This can become a problem to the = use of
=C2=A0 =C2=A0Mobile IP, because Mobile IP relies on the addressing architec= ture
=C2=A0 =C2=A0controlled by the Home Agent.=C2=A0 This problem should be sol= ved as well.

In section 11 Security Considerations:

11.=C2=A0 Security Considerations

=C2=A0 =C2=A0The security is very important in vehicular networks for V2I =C2=A0 =C2=A0networking.=C2=A0 Only valid vehicles should be allowed to use= V2I
=C2=A0 =C2=A0networking in vehicular networks.=C2=A0 VIN and a user certifi= cate can be
=C2=A0 =C2=A0used to authenticate a vehicle and the user.

=C2=A0 =C2=A0This document shares all the security issues of the neighbor =C2=A0 =C2=A0discovery protocol.=C2=A0 This document can get benefits from = secure
=C2=A0 =C2=A0neighbor discovery (SEND) [RFC3971]

Recent works in security for vehicular networks mention two additional thin= gs that are worth considering:

1. the use of TLS certificates for vehicle communications
=C2=A0 =C2=A0draft-lonc-tls-certieee1609-01

2. privacy considerations: a new ETSI activity may consider privacy
=C2=A0 =C2=A0aspects of identifier generation in vehicular communications.<= br>
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
<mailto:jaeh= oon.paul@gmail.com>, pauljeong@skku.edu
<mailto:pauljeon= g@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

=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

--001a114081f62dbf06052c82b3cc-- From nobody Wed Feb 24 03:58:25 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4563C1A916A for ; Wed, 24 Feb 2016 03:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 kBvhJOI4WTo8 for ; Wed, 24 Feb 2016 03:58:16 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::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 90CE01A9163 for ; Wed, 24 Feb 2016 03:58:16 -0800 (PST) Received: by mail-yk0-x22c.google.com with SMTP id z7so6541795yka.3 for ; Wed, 24 Feb 2016 03:58:16 -0800 (PST) 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:content-type; bh=x7J5Yf82huCELJL1LurWIwrlKK5z92rqEJYrAerXvpE=; b=sK0ZvbjvP2SvaMg1jvmBf3DLr8Ynt4bk+kazgyoJJsIjzhVHNKk87g7n/nHGZVhadG 6PvH4AOTm7DdnVhcS8d1+ZITxz5JRPcJDRyP/RMIkCcogZgkYFATpM52KL2e0JunkdtR Y47d1rS6FF+K9La3YlDw78SvcMCmIlngFblc1aCzyCFjqEN4ZmVhZaG7cgYL+StwXRyL a7EFDP6uVicjmN4I+TqXSgEauJMZ2Coy/kTmEPg6uU+pB90ssy3LCldiVNJUNcDhENPn GcPX9PIAIt/rmkbj9SSkunh+8mHUKJ9osHSd+fAz5FEK1qke4RHgX4NVIJm9tDLYMlxa 5BLQ== 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:content-type; bh=x7J5Yf82huCELJL1LurWIwrlKK5z92rqEJYrAerXvpE=; b=Zaid/8jLfusbWa6o4nDtf9YrTQjgdNzxUP2AH0ola3j7H/SFzr1PMYtibG0vYf56tI b3jj/XykFErYWztFKABttC/KM2trjtsc4aZ7l1g7LmCzyMLuClF5D9akYaUG+tFWqG0E GhhPD2VQ/N+BIc406NYYaFjMHFcIuMPY/PbZGCiyYOcO10JrP9f/H+zdEREp4F2q6qKc d6ybvV0hbGHwvyc+kZhYMptAYywEtZQKhKwkffz/mW9FqWnee+d1jGqwmW9o47y4m9HU fkddxcAJAuU8G+hBE+9iU63opv16CGfmyP7xkjCVbYQqsiRKZfu5ExSK+0q55zL25aFo H8cA== X-Gm-Message-State: AG10YOR7AGJI9KGpFAFgMuL2Js/ovkeEgm+rz0r3FI5M//A+Sx3zmKIPmToY6FCmwV+bB9jD0ENFZxWOqwkXHQ== X-Received: by 10.37.64.198 with SMTP id n189mr19413357yba.124.1456315095827; Wed, 24 Feb 2016 03:58:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.83.87 with HTTP; Wed, 24 Feb 2016 03:57:46 -0800 (PST) In-Reply-To: References: <56C465DB.8060305@gmail.com> From: "Mr. Jaehoon Paul Jeong" Date: Wed, 24 Feb 2016 20:57:46 +0900 Message-ID: To: dickroy@alum.mit.edu Content-Type: multipart/alternative; boundary=001a11c07046f7e920052c82c76c Archived-At: Cc: "Dr. Hans-Joachim Fischer" , Alexandre Petrescu , Thierry Ernst , knut.evensen@q-free.com, its@ietf.org Subject: Re: [its] Comments for a New Draft of Problem Statement for V2I Networking X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 11:58:21 -0000 --001a11c07046f7e920052c82c76c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 networki= ng > 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 cou= ld > 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 V2= I > > 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 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 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 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 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 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 mult= i- > > > 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 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 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 session= s > > > can be maintained through IP mobility support, such as Mobile IPv6 > > > [RFC6275]. Since vehicles move fast along roadways, this high spe= ed > > > 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 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 prefixe= s. > > > > 2. A new method of connecting the moving network directly to the RSU > > infra-node network may lead to modifying the addressing architectur= e > > 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 wel= l. > > > > > > 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 > > > > > > > > --=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 --001a11c07046f7e920052c82c76c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Richard,

I will check the IOS standards related to = ITS, which are pointed by you.

I agree with you th= at you need to use well-known terminology for our ITS work.

<= /div>

For 802.11p, as I know, both industry and academia are considerin= g it as=C2=A0

Dedicated Short-Range Communications (DSRC) for veh= icular networking.=C2=A0

Thanks.

Best Regards,

Paul

On Thu, Feb 18, 2016 at 6:2= 4 AM, Richard Roy <dickroy@alum.mit.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.ed= u
> > <mailto:pauljeong@skku.e= du> 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
> >
>

--
=

=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 Pr= ofessor
Department of Software
Sungkyunkwan University
Office: +82= -31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku= .edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeo= ng.php

--001a11c07046f7e920052c82c76c-- From nobody Wed Feb 24 04:02:17 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5F21A870F for ; Wed, 24 Feb 2016 04:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 vNS-JSR7x8oV for ; Wed, 24 Feb 2016 04:02:12 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 A1A411A6FCF for ; Wed, 24 Feb 2016 04:02:12 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id u9so6645815ykd.1 for ; Wed, 24 Feb 2016 04:02:12 -0800 (PST) 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:content-type; bh=ho6yTEEuFnkad139QyEBUXoGk+y8wVkYBTt2fEfPICs=; b=Q8GgteQZqBA2hEGeO24Fa8ZvojfZmrgx9fuanrGDFKVgnJHOzYaUQJYYJ5I63/mUPG 5giae8JO7o+EONBo5cv8FA4/70ha2J7NXLMvmsMrs2kmMGN3BvZSQFWAAk4o+SaP8JpV x665TvyiEKXYgbXKdE2zK4p3/SP/QAgBqN2hwN44pZWpstbBbpwjNqfsuNfmgp/1HMV4 OyJ+c2ZCYgKA/8pd/muZpsfOKJCyQ1EbOAqQCwsAW5+k28laOKu0rOkWALi1vkUn6TCT Y0nKPhncbp1Biv3KJheR5R7JXe7vje3bMdUOkOTsao3Ic4fs/K2vbmxCL9Y1ziKsyn3F wTbw== 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:content-type; bh=ho6yTEEuFnkad139QyEBUXoGk+y8wVkYBTt2fEfPICs=; b=Va69ZuVUPcCF5pXn32beLHsqX79nyLx8kV+JMxmhEjKjhsjxZUqCqbNstY/rGtHN5L YmuwjXqjgNoXfXBYDzsgMfFE1Nk4W+W+01IDZtN36E0wlz1v77QNNfJbNf9aTrB+1nSI A4ahCzGJUo5JaGI3TGxRnqmzNLzFCEAdzgBLTWpf+HWTABidwjaT/CBBF5sVCXr+vAhc pT+I7ojvCgBuM00zTeIqpE2NQ+hbDCqZjqYefy+I+brwN8311RmWORCVUU0oHDTDAuJ5 3hOIDScm6CmQvHFXfOfspwTWc+jRyxJhpuQHE9u1nabWM/vHJvHbbscZkT+WbFb+rXrS BraA== X-Gm-Message-State: AG10YOTheZEmoIaMg4+P7cRninv8xaw9aFljyeNU3NuX16gmOwVyUGgqIXKqtGs8HYyIZyOOjp3hb8fq1kI/sg== X-Received: by 10.37.20.195 with SMTP id 186mr20664213ybu.60.1456315331913; Wed, 24 Feb 2016 04:02:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.83.87 with HTTP; Wed, 24 Feb 2016 04:01:42 -0800 (PST) In-Reply-To: <56C86620.7010403@gmail.com> References: <56C86620.7010403@gmail.com> From: "Mr. Jaehoon Paul Jeong" Date: Wed, 24 Feb 2016 21:01:42 +0900 Message-ID: To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a113e79880a2f86052c82d6df Archived-At: Cc: "its@ietf.org" Subject: Re: [its] BoF request filed X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 12:02:14 -0000 --001a113e79880a2f86052c82d6df Content-Type: text/plain; charset=UTF-8 Alex, Thanks for your coordination for the ITS work. Best Regards, Paul On Sat, Feb 20, 2016 at 10:12 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Hello, > > We have successfully filed the BoF request right before the deadline. We > have received much help at the last minute from several people. > > Let's cross fingers. Response expected in one week time. > > You can follow it live on the following wiki, search "Intelligent": > http://trac.tools.ietf.org/bof/trac/ > > Alex > > _______________________________________________ > 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 --001a113e79880a2f86052c82d6df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Alex,

Thanks for your coordination for the ITS work.

Best Regards,

Paul

On Sat, Feb 20, 2016 at 10:= 12 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com>= wrote:

=20 =20 =20
Hello,

We have successfully filed the BoF request right before the deadline.=C2=A0 We have received much help at the last minute from several people.

Let's cross fingers.=C2=A0 Response expected in one week time.
You can follow it live on the following wiki, search "Intelligent":
ht= tp://trac.tools.ietf.org/bof/trac/

Alex

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

--001a113e79880a2f86052c82d6df-- From nobody Wed Feb 24 04:37:59 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E54B1ACEC7 for ; Wed, 24 Feb 2016 04:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.655 X-Spam-Level: X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] autolearn=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 x2Mon1Aji24B for ; Wed, 24 Feb 2016 04:37:53 -0800 (PST) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id 93EB41ACEC2 for ; Wed, 24 Feb 2016 04:37:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,493,1449529200"; d="scan'208,217";a="3259596" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 24 Feb 2016 13:37:51 +0100 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 3FA90FEB; Wed, 24 Feb 2016 13:37:51 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Mr. Jaehoon Paul Jeong'" , References: <56C465DB.8060305@gmail.com> In-Reply-To: Date: Wed, 24 Feb 2016 13:37:51 +0100 Organization: EURECOM Message-ID: <02d101d16f00$2cd0ce60$86726b20$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D2_01D16F08.8E978050" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFzT+DvIvjip/RmG3QLJovW1+NWXgG39Lv6ArLj7KYCC/MYO5/Dp/eQ Content-Language: en-us Archived-At: Cc: "'Dr. Hans-Joachim Fischer'" , 'Alexandre Petrescu' , 'Thierry Ernst' , knut.evensen@q-free.com, its@ietf.org Subject: Re: [its] Comments for a New Draft of Problem Statement for V2I Networking X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 12:37:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D2_01D16F08.8E978050 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Paul, =20 I follow what Dick mentioned=E2=80=A6the strength of IP is to be above = the underlying technology, so specifying a IPv6 draft specifically for a = technology might be restrictive.=20 =20 What counts is the link specification (unicast, broadcast, multi-cast), = and its properties (delay, short link duration, fast link = establishment=E2=80=A6), whatever is the technology that will fulfill = this(I like the string and tin can though J )=E2=80=A6 =20 And as a matter of fact, if you move away from the very protected = =E2=80=98safety-related=E2=80=99 band, where BSM/CAM are transmitted = (which does not seem to be your target), you reach the BRAN spectrum, = and here, it is the new technology Wild West=E2=80=A6a lot of = technologies will be there for connected vehicles and ITS=E2=80=A6DSRC = probably, but also WiFi ac (and ax) as well as LTE-D LAA will surely be = using these bands to connect vehicles to infrastructure and to each = other=E2=80=A6. =20 Cheers, =20 J=C3=A9r=C3=B4me =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Mr. Jaehoon Paul = Jeong Sent: Wednesday 24 February 2016 12:58 To: dickroy@alum.mit.edu Cc: Dr. Hans-Joachim Fischer; Alexandre Petrescu; Thierry Ernst; = knut.evensen@q-free.com; its@ietf.org Subject: Re: [its] Comments for a New Draft of Problem Statement for V2I = Networking =20 Hi Richard, I will check the IOS standards related to ITS, which are pointed by you. =20 I agree with you that you need to use well-known terminology for our ITS = work. =20 For 802.11p, as I know, both industry and academia are considering it as = Dedicated Short-Range Communications (DSRC) for vehicular networking.=20 =20 Thanks. =20 Best Regards, Paul =20 =20 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-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 contain > 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 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 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 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 = 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 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 = 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 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 = 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 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 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 > > > =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_02D2_01D16F08.8E978050 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Paul,

I follow what Dick mentioned=E2=80=A6the strength of IP is to be = above the underlying technology, so specifying a IPv6 draft specifically = for a technology might be restrictive.

What counts is the link specification (unicast, broadcast, = multi-cast), =C2=A0and its properties (delay, short link duration, fast = link establishment=E2=80=A6), whatever is the technology that will = fulfill this(I like the string and tin can though J )=E2=80=A6

And as a matter of fact, if you move away from the very protected = =E2=80=98safety-related=E2=80=99 band, where BSM/CAM are transmitted = (which does not seem to be your target), you reach the BRAN spectrum, = and here, it is the new technology Wild West=E2=80=A6a lot of = technologies will be there for connected vehicles and ITS=E2=80=A6DSRC = probably, but also WiFi ac (and ax) as well as LTE-D LAA will surely be = using these bands to connect vehicles to infrastructure and to each = other=E2=80=A6.

Cheers,

J=C3=A9r=C3=B4me

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of Mr. Jaehoon Paul = Jeong
Sent: Wednesday 24 February 2016 12:58
To: = dickroy@alum.mit.edu
Cc: Dr. Hans-Joachim Fischer; Alexandre = Petrescu; Thierry Ernst; knut.evensen@q-free.com; = its@ietf.org
Subject: Re: [its] Comments for a New Draft of = Problem Statement for V2I Networking

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 <dickroy@alum.mit.edu> 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-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 contain
> 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 = 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 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 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 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 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 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 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 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 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 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
>= > <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
> = >
>

-- =

=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_02D2_01D16F08.8E978050-- From nobody Thu Feb 25 06:04:41 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0151ACD86 for ; Thu, 25 Feb 2016 06:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 jS3J5DybKmbb for ; Thu, 25 Feb 2016 06:04:31 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0061.outbound.protection.outlook.com [104.47.0.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4481ACD97 for ; Thu, 25 Feb 2016 06:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irtsystemx.onmicrosoft.com; s=selector1-irtsystemx-fr0i; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9mT6B+f4v7ds4pJ2FnpCT4pskiOug3hLVuB06Xb0kRs=; b=MGNjYbQg4k2n0Bf9vPG2MMc9UYY4oirSpvRykn7ITjCdrocvidmubh+zOp3U3fF7aatLXd3UtKawSrepaXYkmeVP0D0kJByKu/7B1NYJBu/ZJexHU24Wm32DXQs+8OBlNrnpugGdQNq6aS2wD0wln59t4tu7CE+9pdfcfP/Nbjo= Received: from AM4PR0401MB1876.eurprd04.prod.outlook.com (10.166.130.138) by AM4PR0401MB1874.eurprd04.prod.outlook.com (10.166.130.136) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 25 Feb 2016 14:04:26 +0000 Received: from AM4PR0401MB1876.eurprd04.prod.outlook.com ([10.166.130.138]) by AM4PR0401MB1876.eurprd04.prod.outlook.com ([10.166.130.138]) with mapi id 15.01.0409.024; Thu, 25 Feb 2016 14:04:26 +0000 From: Arnaud KAISER To: Alexandre Petrescu , "its@ietf.org" Thread-Topic: [its] Updated charter (small correction) Thread-Index: AQHRa0NwwXKQC30CH0y8NSnOsRLYVJ88zD0g Date: Thu, 25 Feb 2016 14:04:25 +0000 Message-ID: References: <56C75EEA.6010506@gmail.com> In-Reply-To: <56C75EEA.6010506@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=irt-systemx.fr; x-originating-ip: [192.93.124.97] x-microsoft-exchange-diagnostics: 1; AM4PR0401MB1874; 5:Kf/VqloDKfAoRwEuHEQGP3YH2clgqEPTNbtoj51W88/qo50BPKrMp6hCVDMXa4hZAwdj8StIkbRH1TP27m+yKNvTHzsVLmG0/NDlDRlPyDvzxQ+SE9sbymgAJNqnhsudcLBzdXgdS09x3n3s4PmYag==; 24:gF4KhE2kq3TKA7R/GmcFIZeFoHYo/8kcphsandqpML+PPuAGJYNWy/aKSYLmyx/4a23OR/TtnTUNLdHvr+uYc4YLuqkx9flzBcLY3u3jMHQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR0401MB1874; x-ms-office365-filtering-correlation-id: 7e4b1fef-33ca-4331-a886-08d33dec9213 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415293)(102615271)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM4PR0401MB1874; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0401MB1874; x-forefront-prvs: 08635C03D4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(45074003)(586003)(102836003)(16236675004)(17760045003)(15395725005)(3846002)(6116002)(66066001)(33656002)(790700001)(1096002)(19625215002)(15650500001)(1220700001)(19617315012)(5004730100002)(5008740100001)(19300405004)(19273905006)(5002640100001)(2900100001)(2906002)(2950100001)(10710500007)(2501003)(5003600100002)(77096005)(19580395003)(74316001)(92566002)(19627595001)(10400500002)(74482002)(19580405001)(15975445007)(107886002)(5001960100002)(5001770100001)(122556002)(18206015028)(87936001)(40100003)(106116001)(2420400007)(7110500001)(11100500001)(76576001)(54356999)(86362001)(76176999)(189998001)(99936001)(50986999)(7099028)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0401MB1874; H:AM4PR0401MB1876.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_AM4PR0401MB18762059436391B91BD38D98DBA60AM4PR0401MB1876_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: irt-systemx.fr X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2016 14:04:25.9991 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: efbb4c7c-8ac1-416d-bf30-791be86aad0b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0401MB1874 Archived-At: Subject: Re: [its] Updated charter (small correction) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 14:04:39 -0000 --_004_AM4PR0401MB18762059436391B91BD38D98DBA60AM4PR0401MB1876_ Content-Type: multipart/alternative; boundary="_000_AM4PR0401MB18762059436391B91BD38D98DBA60AM4PR0401MB1876_" --_000_AM4PR0401MB18762059436391B91BD38D98DBA60AM4PR0401MB1876_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBJVFNlcnMsDQoNCkNvbmNlcm5pbmcgcHJpdmFjeSBhc3BlY3RzIGluIElUUywgSSB3b3Vs ZCBsaWtlIHRvIGluZm9ybSB5b3UgdGhhdCBFVFNJIFdHNSAoc2VjdXJpdHkgYW5kIHByaXZhY3kg V0cpIHN0YXJ0ZWQgYSB3b3JrIGl0ZW0gcmVsYXRlZCB0byBwcml2YWN5LiBNb3JlIHByZWNpc2Vs eSwgdGhlIFdJIGZvY3VzIG9uIHBzZXVkb255bSBjaGFuZ2Ugc3RyYXRlZ2llcy4gUHNldWRvbnlt cyBhcmUgdXNlZCBieSBJVFMgc3RhdGlvbnMgKHZlaGljbGVzLCByb2Fkc2lkZSB1bml0cywgZXRj LikgdG8gaWRlbnRpZnkgZWFjaCBvdGhlciB3aXRob3V0IHJldmVhbGluZyB0aGVpciB0cnVlIGlk ZW50aXR5LiBUaGlzIHRvIHByb3RlY3QgcHJpdmF0ZSBkYXRhIGFuZCBhbHNvIHRvIGF2b2lkIGF0 dGFja3MgbGlrZSB0cmFja2luZyBvZiB2ZWhpY2xlcyBmb3IgZXhhbXBsZS4NCg0KVGhpcyBhc3Bl Y3QgbWF5IGJlIGludGVyZXN0aW5nIHRvIHN0dWR5IGluIHRoZSBjb250ZXh0IG9mIElQdjYgbW92 aW5nIG5ldHdvcmtzLg0KDQpbY2lkOmltYWdlMDAxLnBuZ0AwMUQxNkZEQi4xNzc2RDYwMF0NCg0K RHIuIEFybmF1ZCBLYWlzZXINClJlc2VhcmNoIEVuZ2luZWVyDQpJbnN0aXR1dCBkZSBSZWNoZXJj aGUgVGVjaG5vbG9naXF1ZSBTeXN0ZW1YDQo4LCBBdmVudWUgZGUgbGEgVmF1dmUNCjkxMTIwIFBh bGFpc2VhdSDigJMgRlJBTkNFDQoNCg0KDQpEZSA6IGl0cyBbbWFpbHRvOml0cy1ib3VuY2VzQGll dGYub3JnXSBEZSBsYSBwYXJ0IGRlIEFsZXhhbmRyZSBQZXRyZXNjdQ0KRW52b3nDqSA6IHZlbmRy ZWRpIDE5IGbDqXZyaWVyIDIwMTYgMTk6MjkNCsOAIDogaXRzQGlldGYub3JnDQpPYmpldCA6IFtp dHNdIFVwZGF0ZWQgY2hhcnRlciAoc21hbGwgY29ycmVjdGlvbikNCg0KVXBkYXRlZCBjaGFydGVy IHRvIHJlZmVyIHRvIGluIHRoZSBCb0YgcmVxdWVzdC4NCg0KQWxleA0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAg ICAgICAgICAgIElUUyAobmFtZSB0byBjaGFuZ2UpDQogICAgICAgICAgICAgICAgICAgQ2hhcnRl cg0KICAgICAgICAgICAgIEZlYnJ1YXJ5IDE5dGgsIDIwMTYNCiAgICAgICAgIGh0dHA6Ly9pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KDQoNCkludGVsbGlnZW50IFRyYW5zcG9ydGF0aW9u IFN5c3RlbXMgKGl0cykNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CkN1cnJlbnQgU3RhdHVzOiBXRyBmb3JtaW5nDQoNCkNoYWlyczoNCiAgIFRCRA0KDQpBc3NpZ25l ZCBBcmVhIERpcmVjdG9yOg0KICAgVEJEDQoNCk1haWxpbmcgbGlzdA0KICAgQWRkcmVzczogaXRz QGlldGYub3JnPG1haWx0bzppdHNAaWV0Zi5vcmc+DQogICBUbyBTdWJzY3JpYmU6IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQogICBBcmNoaXZlOg0KICAgaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2l0cy9jdXJyZW50L21haWxsaXN0Lmh0bWwN Cg0KQWRkaXRpb25hbCB3ZWIgcGFnZQ0KICAgVEJEDQoNCkNoYXJ0ZXI6DQoNCkdvYWwNCi0tLS0N ClRoZSBnb2FsIG9mIHRoaXMgZ3JvdXAgaXMgdG8gc3RhbmRhcmRpemUgSVAgcHJvdG9jb2xzIGZv ciBlc3RhYmxpc2hpbmcNCmRpcmVjdCBhbmQgc2VjdXJlIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIG1v dmluZyBuZXR3b3Jrcy4NCg0KTW92aW5nIE5ldHdvcmsgdG8gTmVhcmJ5IE1vdmluZyBOZXR3b3Jr IENvbW11bmljYXRpb25zDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClRoZSBncm91cCBpcyBjb25jZXJuZWQgd2l0aCBhbGwgc2l0dWF0aW9u cyBpbnZvbHZpbmcgbW92aW5nIG5ldHdvcmsgdG8NCm5lYXJieSBtb3ZpbmcgbmV0d29yayBjb21t dW5pY2F0aW9ucy4gIEZvciBleGFtcGxlOiB2ZWhpY2xlLXRvLXZlaGljbGUNCmNvbW11bmljYXRp b25zLCBub21hZGljIHVzZXIgd2VhcmluZyBhIFBBTiBhbmQgY29tbXVuaWNhdGluZyB0byBhDQpo b21lbmV0LCB2ZWhpY2xlLXRvLWluZnJhc3RydWN0dXJlIGNvbW11bmljYXRpb25zLCB3YWdvbi10 by13YWdvbiBpbiBhDQp0cmFpbiwgb3IgdHJhaW4tdG8taW50ZXJzZWN0aW9uIHNpZ25hbGxpbmcu DQoNCkV4YW1wbGUgZnJvbSB0aGUgYXV0b21vYmlsZSBjb21tdW5pY2F0aW9ucyBzcGFjZQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBdXRvbW9iaWxl cyBhbmQgdmVoaWNsZXMgb2YgYWxsIHR5cGVzIGFyZSBpbmNyZWFzaW5nbHkgY29ubmVjdGVkIHRv DQp0aGUgSW50ZXJuZXQuICBFbnRlcnRhaW5tZW50IGFwcHMgZW5oYW5jaW5nIGNvbWZvcnQsIHJl bGlhYmxlIGRhdGENCmV4Y2hhbmdlcyBmb3Igcm9hZCBzYWZldHksIGFuZCBhdXRvbWF0ZWQgZHJp dmluZyBhcmUgZmVhdHVyZXMgY29taW5nDQppbiBhdXRvbW9iaWxlcyB0byBoaXQgdGhlIHJvYWRz IGZyb20gbm93IHRvIHllYXIgMjAyMC4gIEhpZ2hsaWdodGluZw0KaW5jcmVhc2VkIHNhZmV0eSBh cyBhbiBpbW1lZGlhdGUgcmVzdWx0IG9mIGh5cGVyLWNvbm5lY3Rpdml0eSBhcHBsaWVkDQp0byB2 ZWhpY2xlcywgcHVibGljIGF1dGhvcml0aWVzIHdvcmxkd2lkZSBhcmUgaW5jcmVhc2luZ2x5IG1h bmRhdGluZw0KY29tbXVuaWNhdGlvbiB0ZWNobm9sb2d5IHJlcXVpcmVtZW50cyBpbiB2ZWhpY2xl cy4NCg0KRW1lcmdlbmN5IGFwcHMgZm9yIG5ldyBpbnN0cnVtZW50ZWQgYW1idWxhbmNlcyBjYXJy eSBtYW55IGJlbmVmaXRzDQpib3RoIHRvIHRoZSB1c2VycyBhbmQgdG8gc29jaWV0eSBpbiBnZW5l cmFsLg0KDQpXaHkgSVA/DQotLS0tLS0tDQpUb2RheSwgdGhlcmUgYXJlIHNldmVyYWwgZGVwbG95 ZWQgVmVoaWNsZS10by1JbnRlcm5ldCB0ZWNobm9sb2dpZXMsDQppbmNsdWRpbmcgY2FyIHRldGhl cmluZyB0aHJvdWdoIGRyaXZlcidzIGNlbGx1bGFyIHNtYXJ0cGhvbmUuDQpIb3dldmVyLCBWZWhp Y2xlLXRvLVZlaGljbGUgYW5kIFZlaGljbGUtdG8tSW5mcmFzdHJ1Y3R1cmUNCmNvbW11bmljYXRp b25zIGFyZSBzdGlsbCBiZWluZyBkZXZlbG9wZWQuICBUbyBpbXByb3ZlIG9uIGEgc2l0dWF0aW9u DQpvZiBsaW5rLXNwZWNpZmljIGRhdGEgZXhjaGFuZ2VzLCBhbmQgZW5hYmxlIGluZGVwZW5kZW50 IGFwcGxpY2F0aW9uDQpzZXRzIHRvIHNoYXJlIHRoZSBzYW1lIGxpbmtzLCBJUCBkYXRhIGV4Y2hh bmdlcyBhcmUgbmVlZGVkLiAgRW5hYmxpbmcNCklQIGNvbW11bmljYXRpb24gYmV0d2VlbiB2ZWhp Y2xlcyAoVjJWKSwgYW5kIGJldHdlZW4gdmVoaWNsZXMgYW5kIHRoZQ0KaW1tZWRpYXRlIGluZnJh c3RydWN0dXJlIChWMkkpLCB3aWxsIHByb3ZpZGUgKDApIGFiaWxpdHkgdG8gcmVhY2ggdGhlDQpy ZXN0IG9mIHRoZSB3b3JsZCBvbiB0aGUgSW50ZXJuZXQgKDEpIHNob3J0IGFuZCBkZXRlcm1pbmlz dGljIGRlbGF5cywNCigyKSBmYXN0IGZvcndhcmRpbmcgdGhyb3VnaCBzY2FsYWJsZSBwYXRocyBv ZiByb3V0ZXJzLCAoMykgZWFzZSBvZg0KcmV1c2Ugb2YgZXhpc3RpbmcgSW50ZXJuZXQgYXBwbGlj YXRpb25zIGluIGEgdmVoaWN1bGFyIGVudmlyb25tZW50Lg0KDQpNb3ZpbmcgbmV0d29yayB0byBu ZWFyYnkgbW92aW5nIG5ldHdvcmsgY29tbXVuaWNhdGlvbnMgaW52b2x2ZSBsaW5rDQpsYXllcnMg c3VjaCBhczogODAyLjExcCBPQ0IgKE91dHNpZGUgdGhlIENvbnRleHQgb2YgYSBCYXNpYyBTZXJ2 aWNlDQpTZXQpLCA4MDIuMTUuNCB3aXRoIDZsb3dwYW4sIDgwMi4xMWFjLCBWTEMgKFZpc2libGUg TGlnaHQNCkNvbW11bmljYXRpb25zKSwgSXJEQSwgTFRFLUQuICBPbmx5IHRoZSBJUCBwcm90b2Nv bHMgYXJlIGNhcGFibGUgb2YNCnJ1bm5pbmcgb24gZWFjaCBvZiB0aGVzZSBsaW5rcyBhbmQgZXN0 YWJsaXNoIElQIHBhdGhzIGFjcm9zcyB0aGVtIGluDQphbiBpbnRlcm9wZXJhYmxlIG1hbm5lci4N Cg0KU2NlbmFyaW9zPw0KLS0tLS0tLS0tLQ0KVGhlcmUgYXJlIGEgZmV3IHNjZW5hcmlvcyBleGhp Yml0aW5nIHRoZSBuZWVkIHRvIGNvbW11bmljYXRlIGZyb20gb25lDQptb3ZpbmcgbmV0d29yayB0 byBhbm90aGVyIG5lYXJieSBtb3ZpbmcgbmV0d29yay4NCg0KSW4gdGhlIGF1dG9tb2JpbGUgc3Bh Y2UsIHRoZSBDb29wZXJhdGl2ZSBBZGFwdGl2ZSBDcnVpc2UgQ29udHJvbCBhbmQNClBsYXRvb25p bmcgZmVhdHVyZXMgY29uc2lkZXIgdGhhdCB2ZWhpY2xlcyBjbG9zZSB0byBlYWNoIG90aGVyDQpl eGNoYW5nZSBkYXRhIGRlc2NyaWJpbmcgdGhlaXIga2luZW1hdGljIHN0YXR1cy4gIEF0IHRoZSBj cm9zcy1yb2FkcywNCnRoZSBtb3ZpbmcgbmV0d29yayBpbnNpZGUgYSB2ZWhpY2xlIGV4Y2hhbmdl cyBkYXRhIHdpdGggdGhlIG1vdmluZw0KbmV0d29yayBpbiB0aGUgcmVkLWxpZ2h0IHBvbGUuDQoN ClNldmVyYWwgcHVibGljIHNhZmV0eSBzY2VuYXJpb3MgaW52b2x2ZSBtb3ZpbmcgbmV0d29ya3Mu ICBEaXN0aW5jdA0Kb3JnYW5pemF0aW9ucyBkZXBsb3kgZGlmZmVyZW50IG1vdmluZyBuZXR3b3Jr cyAoaW4tdmVoaWNsZSwgb24tcGVyc29uKQ0KYXQgYW4gaW5jaWRlbnQgc2NlbmUuICBUaGVzZSBu ZXR3b3JrcyBuZWVkIHRvIGludGVyb3BlcmF0ZSBpbiBvcmRlciB0bw0KbW9yZSBlZmZlY3RpdmVs eSB1bmRlcnN0YW5kIGFuZCBkZWFsIHdpdGggdGhlIGluY2lkZW50IHNjZW5lLg0KDQpJbiBjb25u ZWN0ZWQgcmFpbCBzY2VuYXJpb3MgdGhlIG1vdmluZyBuZXR3b3JrIGRlcGxveWVkIGluIHRyYWlu cw0KY29tbXVuaWNhdGUgd2l0aCBvdGhlciBtb3ZpbmcgbmV0d29ya3MgYXQgdGhlIGNyb3NzLXBv aW50cy4NCg0KV2hhdCBraW5kIG9mIHNvbHV0aW9ucz8NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpUaGUgY3VycmVudCB0ZWNobmljYWwgc29sdXRpb25zIGNvbnNpZGVyZWQgdG8gYWNoaWV2ZSBt b3ZpbmcgbmV0d29yaw0KdG8gbmVhcmJ5IG1vdmluZyBuZXR3b3JrIGNvbW11bmljYXRpb25zIGFy ZSBvZiB0d28ga2luZHM6IElQIHJvdXRpbmcNCnByb3RvY29scyBmb3Igbi1ob3AgcGF0aCBtYW5h Z2VtZW50IGFuZCAxLWhvcCBsaW5rLXNjb3BlZCBJUCBwcm90b2NvbA0KZW5oYW5jZW1lbnRzLiAg VGhlIDEtaG9wIGxpbmstc2NvcGVkIHByb3RvY29scyBpbmNsdWRlIHRoZSBwcm90b2NvbHMNCmZv ciByb3V0ZSBlc3RhYmxpc2htZW50IGludm9sdmluZyBJQ01QIFJvdXRlciBBZHZlcnRpc2VtZW50 cy4gIFRoZQ0Kbi1ob3AgcGF0aCBtYW5hZ2VtZW50IHByb3RvY29scyBpbmNsdWRlIG4taG9wIHBh dGggZXN0YWJsaXNobWVudA0KcHJvdG9jb2xzIChlLmcuIEJhYmVsLCBPU1BGKSBhbmQgbi1ob3Ag cGF0aCBzZWFyY2ggcHJvdG9jb2xzIChtb3N0DQpub3RhYmx5IEFPRFYgYW5kIGRlcml2YXRlcyku DQoNCkluIHRoaXMgcHJvcG9zZWQgV29ya2luZyBHcm91cCB0aGUgZm9jdXMgaXMgb24gMS1ob3Ag cHJvdG9jb2xzLCBhbmQNCmxldmVyYWdlIGZyb20gb3RoZXIgV29ya2luZyBHcm91cHMgZm9yIHRo ZSBuLWhvcCBzaXR1YXRpb25zLg0KDQpJbiBzb21lIG9mIHRoZSBtb3ZpbmcgbmV0d29yayBhcHBs aWNhdGlvbnMgdGhlIHdpbmRvdyBvZiBvcHBvcnR1bml0eQ0KZm9yIGV4Y2hhbmdpbmcgZGF0YSB3 aXRoIHRoZSBpbW1lZGlhdGUgaW5mcmFzdHJ1Y3R1cmUgbWF5IGJlIHZlcnkNCnNob3J0LiAgRm9y IGV4YW1wbGUsIGEgY2FyIGRyaXZpbmcgbmVhciBhIHJvYWQtc2lkZSB1bml0IG1heSBoYXZlIG9u bHkNCjVzIHRvIGV4Y2hhbmdlIHdpdGggdGhhdCBSU1UgKGRlcGVuZGluZyBvbiBzcGVlZCwgUlNV IHJhbmdlIGFuZA0KbnVtYmVyKS4gKGVwaGVtZXJhbCBjb25uZWN0aW9ucykuDQoNCldoYXQga2lu ZCBvZiByZXF1aXJlbWVudHM/DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhlIHJlcXVp cmVtZW50cyBmb3IgbWVjaGFuaXNtcyBmb3IgbW92aW5nIG5ldHdvcmsgdG8gbmVhcmJ5IG1vdmlu Zw0KbmV0d29yayBjb21tdW5pY2F0aW9ucyBhcmUgZm9jdXNpbmcgb24gbG93IGRlbGF5cyBvZiB0 aGUgZGF0YSBwYXRocywNCnJlZHVjZWQgbnVtYmVyIG9mIG1lc3NhZ2VzIGZvciBwYXRoIGVzdGFi bGlzaG1lbnQsIGFwcGxpY2F0aW9uDQpmcmllbmRseSwgcmVzaWxpZW5jZSB0byBhdHRhY2tzLCBj b21wYXRpYmlsaXR5IHdpdGggREhDUCBhbmQgTW9iaWxlDQpJUC4NCg0KSW4gYWRkaXRpb24sIHNv bWUgbW92aW5nIG5ldHdvcmsgdG8gbmVhcmJ5IG1vdmluZyBuZXR3b3JrIGFwcGxpY2F0aW9ucw0K aW52b2x2ZSBJUCBtdWx0aWNhc3QgbWVjaGFuaXNtcyAoZS5nLiB2aXJ0dWFsIHNpcmVuKTsgdGh1 cyBDLUFDQyB0aGUNCjEtaG9wIElQIG1vdmluZyBuZXR3b3JrIHRvIG5lYXJieSBtb3ZpbmcgbmV0 b3dyayBtZWNoYW5pc21zIHdpbGwgbmVlZA0KdG8gZ3JhY2VmdWxseSBzdXBwb3J0IElQIG11bHRp Y2FzdC4NCg0KRHVlIHRvIHRoZSBpbmhlcmVudCBjaGFyYWN0ZXJpc3RpY3Mgb2Ygc2FmZXR5LXJl bGF0ZWQgY29tbXVuaWNhdGlvbnMsDQphbGwgbmV3IG1vdmluZyBuZXR3b3JrIHRvIG5lYXJieSBt b3ZpbmcgbmV0d29yayBtZWNoYW5pc21zIG11c3QgYWZmb3JkDQphdXRoZW50aWNpdHkgYW5kIGNv bmZpZGVudGlhbGl0eSB3aGVyZSBuZWNlc3NhcnkuICBEeW5hbWljYWxseQ0KZXN0YWJsaXNoaW5n IGVwaGVtZXJhbCBjb21tdW5pY2F0aW9uIHBhdGhzIGJldHdlZW4gYXV0b21vYmlsZXMgaW4NCnB1 YmxpYyBhcmVhcyBtdXN0IG9mZmVyIHByaXZhY3kgc2FmZWd1YXJkcyBmb3IgdGhlIGVuZCB1c2Vy cw0KKHBhc3NlbmdlcnMpLg0KDQpFc3RhYmxpc2hpbmcgMS1ob3AgSVAgVjJWIHBhdGhzIG11c3Qg bm90IGJyZWFrIHRoZSBleGlzdGluZyBvbi1ib2FyZA0KcHJvdG9jb2xzIGFuZCBhcHBsaWNhdGlv bnMgd2hpY2ggY29tbXVuaWNhdGUgd2l0aCB0aGUgSW50ZXJuZXQsDQpwb3NzaWJseSB2aWEgbXVs dGlwbGUgcmFkaW9zLg0KDQpJbiBhIG1vdmluZyBuZXR3b3JrIGRlcGxveWVkIGluIGFuIGF1dG9t b2JpbGUsIHR5cGljYWxseSBvbmUgZXhpdA0KcG9pbnQgY29ubmVjdHMgdGhlIG1vdmluZyBuZXR3 b3JrIHRvIG90aGVyIG1vdmluZyBuZXR3b3Jrcy4gIEhvd2V2ZXIsDQppbiBhIG1vcmUgZ2VuZXJh bCBtYW5uZXIgKGFuZCB0byBzdXBwb3J0IHJlbGlhYmlsaXR5KSBhbnkgbmV3DQptZWNoYW5pc20g b2YgbW92aW5nIG5ldHdvcmsgdG8gbmVhcmJ5IG1vdmluZyBuZXR3b3JrIGNvbW11bmljYXRpb25z DQpzaG91bGQgc3VwcG9ydCBtdWx0aS1ob21pbmc6IG9uZSByb3V0ZXIgdG8gdXNlIG11bHRpcGxl IGludGVyZmFjZXMNCnRvd2FyZHMgb3V0c2lkZSB0aGUgbW92aW5nIG5ldHdvcmssIG9yIG11bHRp cGxlIHJvdXRlcnMuDQoNCkN1cnJlbnQgdmVyc2lvbiBvZiBJbnRlcm5ldCBwcm90b2NvbHMNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoZSBncm91cCB3aWxsIG9ubHkg d29yayBvbiBJUHY2IHNvbHV0aW9ucy4NCg0KV2hhdCBTRE9zIG1heSBuZWVkIHRoaXMgd29yaz8N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGUgcmVxdWlyZW1lbnRzIGFuZCBzdGFu ZGFyZHMgZm9yIG1vdmluZyBuZXR3b3JrIHRvIG5lYXJieSBtb3ZpbmcNCm5ldHdvcmsgY29tbXVu aWNhdGlvbnMsIG9mdGVuIGludm9sdmluZyBJUHY2LCBhbmQgbm92ZWwgVjJWIGFuZA0KVjJJbmZy YSBjb25jZXB0cywgYXJlIGRldmVsb3BlZCBtYWlubHkgYXQgSVNPIFRDMjA0ICJJbnRlbGxpZ2Vu dA0KVHJhbnNwb3J0IFN5c3RlbXMiLCAzR1BQLCBFVFNJLCBOSFRTQSBhbmQgSUVFRS4gIEZvcg0K VmVoaWNsZS10by1JbnRlcm5ldCBjb21tdW5pY2F0aW9ucywgM0dQUCBMVEUgYW5kIG90aGVyIGNl bGx1bGFyDQp0ZWNobm9sb2dpZXMgcmVwcmVzZW50IHRoZSBsb25nLXJhbmdlIGNvbm5lY3Rpdml0 eSBtZXRob2Q7IGZvcg0KVmVoaWNsZS10by1WZWhpY2xlIGNvbW11bmljYXRpb25zLCBMVEUgRGly ZWN0IGlzIGN1cnJlbnRseSBzcGVjaWZpZWQsDQphcyB3ZWxsIGFzIE9DQiBtb2RlIG9mIElFRUUg ODAyLjExLiAgU2V2ZXJhbCB1c2UtY2FzZXMgZXhoaWJpdCBhIG5lZWQNCmZvciBJUHY2IGRhdGEg ZXhjaGFuZ2VzIGJldHdlZW4gdmVoaWNsZXM6IEVUU0kncyBDb29wZXJhdGl2ZSBBZGFwdGl2ZQ0K Q3J1aXNlIENvbnRyb2wgYW5kIFBsYXRvb25pbmcuICBUaGUgSUVFRSBkZXZlbG9wZWQgYSBwb3B1 bGFyIGxpbmsgZm9yDQpzaG9ydC1yYW5nZSBjb21tdW5pY2F0aW9ucyAtIElFRUUgODAyLjExcCAi V0FWRSIuICBUaGUgTkhUU0Egd3JvdGUgYQ0Kc2V0IG9mIHJlcXVpcmVtZW50cyBmb3IgVjJWIGNv bW11bmljYXRpb25zLg0KDQpXb3JrIEl0ZW1zDQotLS0tLS0tLS0tDQotIHVzZS1jYXNlcyBmb3Ig bW92aW5nIG5ldHdvcmsgdG8gbmVhcmJ5IG1vdmluZyBuZXR3b3JrIGNvbW11bmljYXRpb25zDQot IFByb2JsZW0gU3RhdGVtZW50IGZvciBtb3ZpbmcgbmV0d29yayB0byBuZWFyYnkgbW92aW5nIG5l dHdvcmsgY29tbXVuaWNhdGlvbnMNCi0gU2VjdXJpdHkgYW5kIFByaXZhY3kgUmVxdWlyZW1lbnRz IGZvciBtb3ZpbmcgbmV0d29yayB0bw0KICBuZWFyYnkgbW92aW5nIG5ldHdvcmsgY29tbXVuaWNh dGlvbnMNCi0gUHJvYmxlbSBTdGF0ZW1lbnQgZm9yIG1vdmluZyBuZXR3b3JrIHRvIGluZnJhc3Ry dWN0dXJlIG5ldHdvcmsNCiAgY29tbXVuaWNhdGlvbnMsIGluY2x1ZGluZyBETlMNCi0gUG90ZW50 aWFsbHkgbmV3IHByb3RvY29sLCBvciBwcm90b2NvbCBleHRlbnNpb25zIGZvciBlc3RhYmxpc2hp bmcgSVANCiAgcGF0aHMgZm9yIDEtaG9wIG1vdmluZyBuZXR3b3JrIHRvIG5lYXJieSBtb3Zpbmcg bmV0d29yayBjb21tdW5pY2F0aW9ucy4NCiAgV2l0aCBNSUIgYW5kIHNlY3VyaXR5Lg0KLSBJUHY2 LW92ZXIgZm9vLCB3aGVyZSBmb28gaXMgcGVydGluZW50IGZvciBtb3ZpbmcgbmV0d29yayB0byBu ZWFyYnkNCiAgbW92aW5nIG5ldHdvcmsgY29tbXVuaWNhdGlvbnMgKGUuZy4gODAyLjExIE9DQiwg VkxDLCBMVEUtRCwgODAyLjExYWQpDQoNClRpbWVsaW5lDQotLS0tLS0tLQ0KLQ0K --_000_AM4PR0401MB18762059436391B91BD38D98DBA60AM4PR0401MB1876_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9 IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkRlYXIgSVRTZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Q29uY2VybmluZyBwcml2YWN5IGFzcGVjdHMgaW4gSVRTLCBJIHdvdWxk IGxpa2UgdG8gaW5mb3JtIHlvdSB0aGF0IEVUU0kgV0c1IChzZWN1cml0eSBhbmQgcHJpdmFjeSBX Rykgc3RhcnRlZCBhIHdvcmsgaXRlbSByZWxhdGVkIHRvIHByaXZhY3kuIE1vcmUgcHJlY2lzZWx5 LA0KIHRoZSBXSSBmb2N1cyBvbiBwc2V1ZG9ueW0gY2hhbmdlIHN0cmF0ZWdpZXMuIFBzZXVkb255 bXMgYXJlIHVzZWQgYnkgSVRTIHN0YXRpb25zICh2ZWhpY2xlcywgcm9hZHNpZGUgdW5pdHMsIGV0 Yy4pIHRvIGlkZW50aWZ5IGVhY2ggb3RoZXIgd2l0aG91dCByZXZlYWxpbmcgdGhlaXIgdHJ1ZSBp ZGVudGl0eS4gVGhpcyB0byBwcm90ZWN0IHByaXZhdGUgZGF0YSBhbmQgYWxzbyB0byBhdm9pZCBh dHRhY2tzIGxpa2UgdHJhY2tpbmcgb2YgdmVoaWNsZXMNCiBmb3IgZXhhbXBsZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgYXNwZWN0IG1heSBiZSBpbnRl cmVzdGluZyB0byBzdHVkeSBpbiB0aGUgY29udGV4dCBvZiBJUHY2IG1vdmluZyBuZXR3b3Jrcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjx0 YWJsZSBjbGFzcz0iTXNvVGFibGVHcmlkIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxs cGFkZGluZz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpjb2xsYXBzZTtib3JkZXI6bm9uZSI+ DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9IjE5OCIgc3R5bGU9IndpZHRoOjE0OC42cHQ7cGFk ZGluZzowY20gNS40cHQgMGNtIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJy aWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48aW1nIHdpZHRoPSIxODAiIGhlaWdodD0iOTAiIGlkPSJJbWFnZV94MDAyMF8yIiBzcmM9 ImNpZDppbWFnZTAwMS5wbmdAMDFEMTZGREIuMTc3NkQ2MDAiIGFsdD0iY2lkOmltYWdlMDAxLnBu Z0AwMUQxNkZEQi4xNzc2RDYwMCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3 aWR0aD0iMzIyIiBzdHlsZT0id2lkdGg6MjQxLjI1cHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUu NHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+RHIuIEFybmF1ZCBLYWlzZXI8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj NzY3MTcxIj5SZXNlYXJjaCBFbmdpbmVlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc2NzE3MSI+SW5z dGl0dXQgZGUgUmVjaGVyY2hlIFRlY2hub2xvZ2lxdWUgU3lzdGVtWDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6Izc2NzE3MSI+OCwgQXZlbnVlIGRlIGxhIFZhdXZlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzY3 MTcxIj45MTEyMCBQYWxhaXNlYXUg4oCTIEZSQU5DRTwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IGl0cyBbbWFpbHRvOml0cy1i b3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gQWxleGFuZHJlIFBldHJlc2N1 PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IHZlbmRyZWRpIDE5IGbDqXZyaWVyIDIwMTYgMTk6 Mjk8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IGl0c0BpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7 OjwvYj4gW2l0c10gVXBkYXRlZCBjaGFydGVyIChzbWFsbCBjb3JyZWN0aW9uKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlVwZGF0ZWQgY2hhcnRlciB0byByZWZlciB0byBpbiB0 aGUgQm9GIHJlcXVlc3QuPGJyPg0KPGJyPg0KQWxleDxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBJVFMgKG5hbWUgdG8gY2hhbmdlKTxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDaGFydGVyPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEZlYnJ1YXJ5IDE5dGgsIDIwMTY8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5odHRwOi8vaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHM8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PGJyPg0KPGJyPg0KPGJyPg0KSW50ZWxsaWdlbnQgVHJhbnNwb3J0YXRpb24gU3lzdGVtcyAo aXRzKTxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpD dXJyZW50IFN0YXR1czogV0cgZm9ybWluZzxicj4NCjxicj4NCkNoYWlyczo8YnI+DQombmJzcDsm bmJzcDsgVEJEPGJyPg0KPGJyPg0KQXNzaWduZWQgQXJlYSBEaXJlY3Rvcjo8YnI+DQombmJzcDsm bmJzcDsgVEJEPGJyPg0KPGJyPg0KTWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7Jm5ic3A7IEFkZHJl c3M6IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86aXRzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPml0c0BpZXRmLm9yZzwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQom bmJzcDsmbmJzcDsgVG8gU3Vic2NyaWJlOiA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pdHM8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PGJyPg0KJm5ic3A7Jm5ic3A7IEFyY2hpdmU6PGJyPg0KJm5ic3A7Jm5ic3A7IDwv c3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaXRzL2N1 cnJlbnQvbWFpbGxpc3QuaHRtbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaXRzL2N1 cnJlbnQvbWFpbGxpc3QuaHRtbDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8YnI+DQpBZGRpdGlvbmFsIHdlYiBwYWdlPGJy Pg0KJm5ic3A7Jm5ic3A7IFRCRDxicj4NCjxicj4NCkNoYXJ0ZXI6PGJyPg0KPGJyPg0KR29hbDxi cj4NCi0tLS08YnI+DQpUaGUgZ29hbCBvZiB0aGlzIGdyb3VwIGlzIHRvIHN0YW5kYXJkaXplIElQ IHByb3RvY29scyBmb3IgZXN0YWJsaXNoaW5nPGJyPg0KZGlyZWN0IGFuZCBzZWN1cmUgY29ubmVj dGl2aXR5IGJldHdlZW4gbW92aW5nIG5ldHdvcmtzLjxicj4NCjxicj4NCk1vdmluZyBOZXR3b3Jr IHRvIE5lYXJieSBNb3ZpbmcgTmV0d29yayBDb21tdW5pY2F0aW9uczxicj4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClRoZSBncm91 cCBpcyBjb25jZXJuZWQgd2l0aCBhbGwgc2l0dWF0aW9ucyBpbnZvbHZpbmcgbW92aW5nIG5ldHdv cmsgdG88YnI+DQpuZWFyYnkgbW92aW5nIG5ldHdvcmsgY29tbXVuaWNhdGlvbnMuJm5ic3A7IEZv ciBleGFtcGxlOiB2ZWhpY2xlLXRvLXZlaGljbGU8YnI+DQpjb21tdW5pY2F0aW9ucywgbm9tYWRp YyB1c2VyIHdlYXJpbmcgYSBQQU4gYW5kIGNvbW11bmljYXRpbmcgdG8gYTxicj4NCmhvbWVuZXQs IHZlaGljbGUtdG8taW5mcmFzdHJ1Y3R1cmUgY29tbXVuaWNhdGlvbnMsIHdhZ29uLXRvLXdhZ29u IGluIGE8YnI+DQp0cmFpbiwgb3IgdHJhaW4tdG8taW50ZXJzZWN0aW9uIHNpZ25hbGxpbmcuPGJy Pg0KPGJyPg0KRXhhbXBsZSBmcm9tIHRoZSBhdXRvbW9iaWxlIGNvbW11bmljYXRpb25zIHNwYWNl PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJy Pg0KQXV0b21vYmlsZXMgYW5kIHZlaGljbGVzIG9mIGFsbCB0eXBlcyBhcmUgaW5jcmVhc2luZ2x5 IGNvbm5lY3RlZCB0bzxicj4NCnRoZSBJbnRlcm5ldC4mbmJzcDsgRW50ZXJ0YWlubWVudCBhcHBz IGVuaGFuY2luZyBjb21mb3J0LCByZWxpYWJsZSBkYXRhPGJyPg0KZXhjaGFuZ2VzIGZvciByb2Fk IHNhZmV0eSwgYW5kIGF1dG9tYXRlZCBkcml2aW5nIGFyZSBmZWF0dXJlcyBjb21pbmc8YnI+DQpp biBhdXRvbW9iaWxlcyB0byBoaXQgdGhlIHJvYWRzIGZyb20gbm93IHRvIHllYXIgMjAyMC4mbmJz cDsgSGlnaGxpZ2h0aW5nPGJyPg0KaW5jcmVhc2VkIHNhZmV0eSBhcyBhbiBpbW1lZGlhdGUgcmVz dWx0IG9mIGh5cGVyLWNvbm5lY3Rpdml0eSBhcHBsaWVkPGJyPg0KdG8gdmVoaWNsZXMsIHB1Ymxp YyBhdXRob3JpdGllcyB3b3JsZHdpZGUgYXJlIGluY3JlYXNpbmdseSBtYW5kYXRpbmc8YnI+DQpj b21tdW5pY2F0aW9uIHRlY2hub2xvZ3kgcmVxdWlyZW1lbnRzIGluIHZlaGljbGVzLjxicj4NCjxi cj4NCkVtZXJnZW5jeSBhcHBzIGZvciBuZXcgaW5zdHJ1bWVudGVkIGFtYnVsYW5jZXMgY2Fycnkg bWFueSBiZW5lZml0czxicj4NCmJvdGggdG8gdGhlIHVzZXJzIGFuZCB0byBzb2NpZXR5IGluIGdl bmVyYWwuPGJyPg0KPGJyPg0KV2h5IElQPzxicj4NCi0tLS0tLS08YnI+DQpUb2RheSwgdGhlcmUg YXJlIHNldmVyYWwgZGVwbG95ZWQgVmVoaWNsZS10by1JbnRlcm5ldCB0ZWNobm9sb2dpZXMsPGJy Pg0KaW5jbHVkaW5nIGNhciB0ZXRoZXJpbmcgdGhyb3VnaCBkcml2ZXIncyBjZWxsdWxhciBzbWFy dHBob25lLjxicj4NCkhvd2V2ZXIsIFZlaGljbGUtdG8tVmVoaWNsZSBhbmQgVmVoaWNsZS10by1J bmZyYXN0cnVjdHVyZTxicj4NCmNvbW11bmljYXRpb25zIGFyZSBzdGlsbCBiZWluZyBkZXZlbG9w ZWQuJm5ic3A7IFRvIGltcHJvdmUgb24gYSBzaXR1YXRpb248YnI+DQpvZiBsaW5rLXNwZWNpZmlj IGRhdGEgZXhjaGFuZ2VzLCBhbmQgZW5hYmxlIGluZGVwZW5kZW50IGFwcGxpY2F0aW9uPGJyPg0K c2V0cyB0byBzaGFyZSB0aGUgc2FtZSBsaW5rcywgSVAgZGF0YSBleGNoYW5nZXMgYXJlIG5lZWRl ZC4mbmJzcDsgRW5hYmxpbmc8YnI+DQpJUCBjb21tdW5pY2F0aW9uIGJldHdlZW4gdmVoaWNsZXMg KFYyViksIGFuZCBiZXR3ZWVuIHZlaGljbGVzIGFuZCB0aGU8YnI+DQppbW1lZGlhdGUgaW5mcmFz dHJ1Y3R1cmUgKFYySSksIHdpbGwgcHJvdmlkZSAoMCkgYWJpbGl0eSB0byByZWFjaCB0aGU8YnI+ DQpyZXN0IG9mIHRoZSB3b3JsZCBvbiB0aGUgSW50ZXJuZXQgKDEpIHNob3J0IGFuZCBkZXRlcm1p bmlzdGljIGRlbGF5cyw8YnI+DQooMikgZmFzdCBmb3J3YXJkaW5nIHRocm91Z2ggc2NhbGFibGUg cGF0aHMgb2Ygcm91dGVycywgKDMpIGVhc2Ugb2Y8YnI+DQpyZXVzZSBvZiBleGlzdGluZyBJbnRl cm5ldCBhcHBsaWNhdGlvbnMgaW4gYSB2ZWhpY3VsYXIgZW52aXJvbm1lbnQuPGJyPg0KPGJyPg0K TW92aW5nIG5ldHdvcmsgdG8gbmVhcmJ5IG1vdmluZyBuZXR3b3JrIGNvbW11bmljYXRpb25zIGlu dm9sdmUgbGluazxicj4NCmxheWVycyBzdWNoIGFzOiA4MDIuMTFwIE9DQiAoT3V0c2lkZSB0aGUg Q29udGV4dCBvZiBhIEJhc2ljIFNlcnZpY2U8YnI+DQpTZXQpLCA4MDIuMTUuNCB3aXRoIDZsb3dw YW4sIDgwMi4xMWFjLCBWTEMgKFZpc2libGUgTGlnaHQ8YnI+DQpDb21tdW5pY2F0aW9ucyksIEly REEsIExURS1ELiZuYnNwOyBPbmx5IHRoZSBJUCBwcm90b2NvbHMgYXJlIGNhcGFibGUgb2Y8YnI+ DQpydW5uaW5nIG9uIGVhY2ggb2YgdGhlc2UgbGlua3MgYW5kIGVzdGFibGlzaCBJUCBwYXRocyBh Y3Jvc3MgdGhlbSBpbjxicj4NCmFuIGludGVyb3BlcmFibGUgbWFubmVyLjxicj4NCjxicj4NClNj ZW5hcmlvcz88YnI+DQotLS0tLS0tLS0tPGJyPg0KVGhlcmUgYXJlIGEgZmV3IHNjZW5hcmlvcyBl eGhpYml0aW5nIHRoZSBuZWVkIHRvIGNvbW11bmljYXRlIGZyb20gb25lPGJyPg0KbW92aW5nIG5l dHdvcmsgdG8gYW5vdGhlciBuZWFyYnkgbW92aW5nIG5ldHdvcmsuPGJyPg0KPGJyPg0KSW4gdGhl IGF1dG9tb2JpbGUgc3BhY2UsIHRoZSBDb29wZXJhdGl2ZSBBZGFwdGl2ZSBDcnVpc2UgQ29udHJv bCBhbmQ8YnI+DQpQbGF0b29uaW5nIGZlYXR1cmVzIGNvbnNpZGVyIHRoYXQgdmVoaWNsZXMgY2xv c2UgdG8gZWFjaCBvdGhlcjxicj4NCmV4Y2hhbmdlIGRhdGEgZGVzY3JpYmluZyB0aGVpciBraW5l bWF0aWMgc3RhdHVzLiZuYnNwOyBBdCB0aGUgY3Jvc3Mtcm9hZHMsPGJyPg0KdGhlIG1vdmluZyBu ZXR3b3JrIGluc2lkZSBhIHZlaGljbGUgZXhjaGFuZ2VzIGRhdGEgd2l0aCB0aGUgbW92aW5nPGJy Pg0KbmV0d29yayBpbiB0aGUgcmVkLWxpZ2h0IHBvbGUuPGJyPg0KPGJyPg0KU2V2ZXJhbCBwdWJs aWMgc2FmZXR5IHNjZW5hcmlvcyBpbnZvbHZlIG1vdmluZyBuZXR3b3Jrcy4mbmJzcDsgRGlzdGlu Y3Q8YnI+DQpvcmdhbml6YXRpb25zIGRlcGxveSBkaWZmZXJlbnQgbW92aW5nIG5ldHdvcmtzIChp bi12ZWhpY2xlLCBvbi1wZXJzb24pPGJyPg0KYXQgYW4gaW5jaWRlbnQgc2NlbmUuJm5ic3A7IFRo ZXNlIG5ldHdvcmtzIG5lZWQgdG8gaW50ZXJvcGVyYXRlIGluIG9yZGVyIHRvPGJyPg0KbW9yZSBl ZmZlY3RpdmVseSB1bmRlcnN0YW5kIGFuZCBkZWFsIHdpdGggdGhlIGluY2lkZW50IHNjZW5lLjxi cj4NCjxicj4NCkluIGNvbm5lY3RlZCByYWlsIHNjZW5hcmlvcyB0aGUgbW92aW5nIG5ldHdvcmsg ZGVwbG95ZWQgaW4gdHJhaW5zPGJyPg0KY29tbXVuaWNhdGUgd2l0aCBvdGhlciBtb3ZpbmcgbmV0 d29ya3MgYXQgdGhlIGNyb3NzLXBvaW50cy48YnI+DQo8YnI+DQpXaGF0IGtpbmQgb2Ygc29sdXRp b25zPzxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KVGhlIGN1cnJlbnQgdGVjaG5p Y2FsIHNvbHV0aW9ucyBjb25zaWRlcmVkIHRvIGFjaGlldmUgbW92aW5nIG5ldHdvcms8YnI+DQp0 byBuZWFyYnkgbW92aW5nIG5ldHdvcmsgY29tbXVuaWNhdGlvbnMgYXJlIG9mIHR3byBraW5kczog SVAgcm91dGluZzxicj4NCnByb3RvY29scyBmb3Igbi1ob3AgcGF0aCBtYW5hZ2VtZW50IGFuZCAx LWhvcCBsaW5rLXNjb3BlZCBJUCBwcm90b2NvbDxicj4NCmVuaGFuY2VtZW50cy4mbmJzcDsgVGhl IDEtaG9wIGxpbmstc2NvcGVkIHByb3RvY29scyBpbmNsdWRlIHRoZSBwcm90b2NvbHM8YnI+DQpm b3Igcm91dGUgZXN0YWJsaXNobWVudCBpbnZvbHZpbmcgSUNNUCBSb3V0ZXIgQWR2ZXJ0aXNlbWVu dHMuJm5ic3A7IFRoZTxicj4NCm4taG9wIHBhdGggbWFuYWdlbWVudCBwcm90b2NvbHMgaW5jbHVk ZSBuLWhvcCBwYXRoIGVzdGFibGlzaG1lbnQ8YnI+DQpwcm90b2NvbHMgKGUuZy4gQmFiZWwsIE9T UEYpIGFuZCBuLWhvcCBwYXRoIHNlYXJjaCBwcm90b2NvbHMgKG1vc3Q8YnI+DQpub3RhYmx5IEFP RFYgYW5kIGRlcml2YXRlcykuPGJyPg0KPGJyPg0KSW4gdGhpcyBwcm9wb3NlZCBXb3JraW5nIEdy b3VwIHRoZSBmb2N1cyBpcyBvbiAxLWhvcCBwcm90b2NvbHMsIGFuZDxicj4NCmxldmVyYWdlIGZy b20gb3RoZXIgV29ya2luZyBHcm91cHMgZm9yIHRoZSBuLWhvcCBzaXR1YXRpb25zLjxicj4NCjxi cj4NCkluIHNvbWUgb2YgdGhlIG1vdmluZyBuZXR3b3JrIGFwcGxpY2F0aW9ucyB0aGUgd2luZG93 IG9mIG9wcG9ydHVuaXR5PGJyPg0KZm9yIGV4Y2hhbmdpbmcgZGF0YSB3aXRoIHRoZSBpbW1lZGlh dGUgaW5mcmFzdHJ1Y3R1cmUgbWF5IGJlIHZlcnk8YnI+DQpzaG9ydC4mbmJzcDsgRm9yIGV4YW1w bGUsIGEgY2FyIGRyaXZpbmcgbmVhciBhIHJvYWQtc2lkZSB1bml0IG1heSBoYXZlIG9ubHk8YnI+ DQo1cyB0byBleGNoYW5nZSB3aXRoIHRoYXQgUlNVIChkZXBlbmRpbmcgb24gc3BlZWQsIFJTVSBy YW5nZSBhbmQ8YnI+DQpudW1iZXIpLiAoZXBoZW1lcmFsIGNvbm5lY3Rpb25zKS48YnI+DQo8YnI+ DQpXaGF0IGtpbmQgb2YgcmVxdWlyZW1lbnRzPzxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPg0KVGhlIHJlcXVpcmVtZW50cyBmb3IgbWVjaGFuaXNtcyBmb3IgbW92aW5nIG5ldHdv cmsgdG8gbmVhcmJ5IG1vdmluZzxicj4NCm5ldHdvcmsgY29tbXVuaWNhdGlvbnMgYXJlIGZvY3Vz aW5nIG9uIGxvdyBkZWxheXMgb2YgdGhlIGRhdGEgcGF0aHMsPGJyPg0KcmVkdWNlZCBudW1iZXIg b2YgbWVzc2FnZXMgZm9yIHBhdGggZXN0YWJsaXNobWVudCwgYXBwbGljYXRpb248YnI+DQpmcmll bmRseSwgcmVzaWxpZW5jZSB0byBhdHRhY2tzLCBjb21wYXRpYmlsaXR5IHdpdGggREhDUCBhbmQg TW9iaWxlPGJyPg0KSVAuPGJyPg0KPGJyPg0KSW4gYWRkaXRpb24sIHNvbWUgbW92aW5nIG5ldHdv cmsgdG8gbmVhcmJ5IG1vdmluZyBuZXR3b3JrIGFwcGxpY2F0aW9uczxicj4NCmludm9sdmUgSVAg bXVsdGljYXN0IG1lY2hhbmlzbXMgKGUuZy4gdmlydHVhbCBzaXJlbik7IHRodXMgQy1BQ0MgdGhl PGJyPg0KMS1ob3AgSVAgbW92aW5nIG5ldHdvcmsgdG8gbmVhcmJ5IG1vdmluZyBuZXRvd3JrIG1l Y2hhbmlzbXMgd2lsbCBuZWVkPGJyPg0KdG8gZ3JhY2VmdWxseSBzdXBwb3J0IElQIG11bHRpY2Fz dC48YnI+DQo8YnI+DQpEdWUgdG8gdGhlIGluaGVyZW50IGNoYXJhY3RlcmlzdGljcyBvZiBzYWZl dHktcmVsYXRlZCBjb21tdW5pY2F0aW9ucyw8YnI+DQphbGwgbmV3IG1vdmluZyBuZXR3b3JrIHRv IG5lYXJieSBtb3ZpbmcgbmV0d29yayBtZWNoYW5pc21zIG11c3QgYWZmb3JkPGJyPg0KYXV0aGVu dGljaXR5IGFuZCBjb25maWRlbnRpYWxpdHkgd2hlcmUgbmVjZXNzYXJ5LiZuYnNwOyBEeW5hbWlj YWxseTxicj4NCmVzdGFibGlzaGluZyBlcGhlbWVyYWwgY29tbXVuaWNhdGlvbiBwYXRocyBiZXR3 ZWVuIGF1dG9tb2JpbGVzIGluPGJyPg0KcHVibGljIGFyZWFzIG11c3Qgb2ZmZXIgcHJpdmFjeSBz YWZlZ3VhcmRzIGZvciB0aGUgZW5kIHVzZXJzPGJyPg0KKHBhc3NlbmdlcnMpLjxicj4NCjxicj4N CkVzdGFibGlzaGluZyAxLWhvcCBJUCBWMlYgcGF0aHMgbXVzdCBub3QgYnJlYWsgdGhlIGV4aXN0 aW5nIG9uLWJvYXJkPGJyPg0KcHJvdG9jb2xzIGFuZCBhcHBsaWNhdGlvbnMgd2hpY2ggY29tbXVu aWNhdGUgd2l0aCB0aGUgSW50ZXJuZXQsPGJyPg0KcG9zc2libHkgdmlhIG11bHRpcGxlIHJhZGlv cy48YnI+DQo8YnI+DQpJbiBhIG1vdmluZyBuZXR3b3JrIGRlcGxveWVkIGluIGFuIGF1dG9tb2Jp bGUsIHR5cGljYWxseSBvbmUgZXhpdDxicj4NCnBvaW50IGNvbm5lY3RzIHRoZSBtb3ZpbmcgbmV0 d29yayB0byBvdGhlciBtb3ZpbmcgbmV0d29ya3MuJm5ic3A7IEhvd2V2ZXIsPGJyPg0KaW4gYSBt b3JlIGdlbmVyYWwgbWFubmVyIChhbmQgdG8gc3VwcG9ydCByZWxpYWJpbGl0eSkgYW55IG5ldzxi cj4NCm1lY2hhbmlzbSBvZiBtb3ZpbmcgbmV0d29yayB0byBuZWFyYnkgbW92aW5nIG5ldHdvcmsg Y29tbXVuaWNhdGlvbnM8YnI+DQpzaG91bGQgc3VwcG9ydCBtdWx0aS1ob21pbmc6IG9uZSByb3V0 ZXIgdG8gdXNlIG11bHRpcGxlIGludGVyZmFjZXM8YnI+DQp0b3dhcmRzIG91dHNpZGUgdGhlIG1v dmluZyBuZXR3b3JrLCBvciBtdWx0aXBsZSByb3V0ZXJzLjxicj4NCjxicj4NCkN1cnJlbnQgdmVy c2lvbiBvZiBJbnRlcm5ldCBwcm90b2NvbHM8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KVGhlIGdyb3VwIHdpbGwgb25seSB3b3JrIG9uIElQdjYgc29sdXRp b25zLjxicj4NCjxicj4NCldoYXQgU0RPcyBtYXkgbmVlZCB0aGlzIHdvcms/PGJyPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpUaGUgcmVxdWlyZW1lbnRzIGFuZCBzdGFuZGFy ZHMgZm9yIG1vdmluZyBuZXR3b3JrIHRvIG5lYXJieSBtb3Zpbmc8YnI+DQpuZXR3b3JrIGNvbW11 bmljYXRpb25zLCBvZnRlbiBpbnZvbHZpbmcgSVB2NiwgYW5kIG5vdmVsIFYyViBhbmQ8YnI+DQpW MkluZnJhIGNvbmNlcHRzLCBhcmUgZGV2ZWxvcGVkIG1haW5seSBhdCBJU08gVEMyMDQgJnF1b3Q7 SW50ZWxsaWdlbnQ8YnI+DQpUcmFuc3BvcnQgU3lzdGVtcyZxdW90OywgM0dQUCwgRVRTSSwgTkhU U0EgYW5kIElFRUUuJm5ic3A7IEZvcjxicj4NClZlaGljbGUtdG8tSW50ZXJuZXQgY29tbXVuaWNh dGlvbnMsIDNHUFAgTFRFIGFuZCBvdGhlciBjZWxsdWxhcjxicj4NCnRlY2hub2xvZ2llcyByZXBy ZXNlbnQgdGhlIGxvbmctcmFuZ2UgY29ubmVjdGl2aXR5IG1ldGhvZDsgZm9yPGJyPg0KVmVoaWNs ZS10by1WZWhpY2xlIGNvbW11bmljYXRpb25zLCBMVEUgRGlyZWN0IGlzIGN1cnJlbnRseSBzcGVj aWZpZWQsPGJyPg0KYXMgd2VsbCBhcyBPQ0IgbW9kZSBvZiBJRUVFIDgwMi4xMS4mbmJzcDsgU2V2 ZXJhbCB1c2UtY2FzZXMgZXhoaWJpdCBhIG5lZWQ8YnI+DQpmb3IgSVB2NiBkYXRhIGV4Y2hhbmdl cyBiZXR3ZWVuIHZlaGljbGVzOiBFVFNJJ3MgQ29vcGVyYXRpdmUgQWRhcHRpdmU8YnI+DQpDcnVp c2UgQ29udHJvbCBhbmQgUGxhdG9vbmluZy4mbmJzcDsgVGhlIElFRUUgZGV2ZWxvcGVkIGEgcG9w dWxhciBsaW5rIGZvcjxicj4NCnNob3J0LXJhbmdlIGNvbW11bmljYXRpb25zIC0gSUVFRSA4MDIu MTFwICZxdW90O1dBVkUmcXVvdDsuJm5ic3A7IFRoZSBOSFRTQSB3cm90ZSBhPGJyPg0Kc2V0IG9m IHJlcXVpcmVtZW50cyBmb3IgVjJWIGNvbW11bmljYXRpb25zLjxicj4NCjxicj4NCldvcmsgSXRl bXM8YnI+DQotLS0tLS0tLS0tPGJyPg0KLSB1c2UtY2FzZXMgZm9yIG1vdmluZyBuZXR3b3JrIHRv IG5lYXJieSBtb3ZpbmcgbmV0d29yayBjb21tdW5pY2F0aW9uczxicj4NCi0gUHJvYmxlbSBTdGF0 ZW1lbnQgZm9yIG1vdmluZyBuZXR3b3JrIHRvIG5lYXJieSBtb3ZpbmcgbmV0d29yayBjb21tdW5p Y2F0aW9uczxicj4NCi0gU2VjdXJpdHkgYW5kIFByaXZhY3kgUmVxdWlyZW1lbnRzIGZvciBtb3Zp bmcgbmV0d29yayB0bzxicj4NCiZuYnNwOyBuZWFyYnkgbW92aW5nIG5ldHdvcmsgY29tbXVuaWNh dGlvbnM8YnI+DQotIFByb2JsZW0gU3RhdGVtZW50IGZvciBtb3ZpbmcgbmV0d29yayB0byBpbmZy YXN0cnVjdHVyZSBuZXR3b3JrPGJyPg0KJm5ic3A7IGNvbW11bmljYXRpb25zLCBpbmNsdWRpbmcg RE5TPGJyPg0KLSBQb3RlbnRpYWxseSBuZXcgcHJvdG9jb2wsIG9yIHByb3RvY29sIGV4dGVuc2lv bnMgZm9yIGVzdGFibGlzaGluZyBJUDxicj4NCiZuYnNwOyBwYXRocyBmb3IgMS1ob3AgbW92aW5n IG5ldHdvcmsgdG8gbmVhcmJ5IG1vdmluZyBuZXR3b3JrIGNvbW11bmljYXRpb25zLjxicj4NCiZu YnNwOyBXaXRoIE1JQiBhbmQgc2VjdXJpdHkuPGJyPg0KLSBJUHY2LW92ZXIgZm9vLCB3aGVyZSBm b28gaXMgcGVydGluZW50IGZvciBtb3ZpbmcgbmV0d29yayB0byBuZWFyYnk8YnI+DQombmJzcDsg bW92aW5nIG5ldHdvcmsgY29tbXVuaWNhdGlvbnMgKGUuZy4gODAyLjExIE9DQiwgVkxDLCBMVEUt RCwgODAyLjExYWQpPGJyPg0KPGJyPg0KVGltZWxpbmU8YnI+DQotLS0tLS0tLTxicj4NCi08L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM4PR0401MB18762059436391B91BD38D98DBA60AM4PR0401MB1876_-- --_004_AM4PR0401MB18762059436391B91BD38D98DBA60AM4PR0401MB1876_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=1824; creation-date="Thu, 25 Feb 2016 14:04:25 GMT"; modification-date="Thu, 25 Feb 2016 14:04:25 GMT" Content-ID: Content-Transfer-Encoding: base64 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 --_004_AM4PR0401MB18762059436391B91BD38D98DBA60AM4PR0401MB1876_-- From nobody Fri Feb 26 12:19:27 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2875D1B2F4B; Fri, 26 Feb 2016 11:51:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160226195142.24059.85405.idtracker@ietfa.amsl.com> Date: Fri, 26 Feb 2016 11:51:42 -0800 Archived-At: X-Mailman-Approved-At: Fri, 26 Feb 2016 12:19:26 -0800 Cc: brian@innovationslab.net, its-chairs@ietf.org, its@ietf.org, smccammon@amsl.com Subject: [its] its - New Meeting Session Request for IETF 95 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 19:51:42 -0000 A new meeting session request has just been submitted by Stephanie McCammon, on behalf of the its working group. --------------------------------------------------------- Working Group Name: Intelligent Transportation Systems Area Name: Internet Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: 6lo dmm 6man dhc manet roll rtgarea ospf isis babel lime Special Requests: --------------------------------------------------------- From nobody Mon Feb 29 07:38:38 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B65AA1B338C; Mon, 29 Feb 2016 07:21:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160229152130.8291.41087.idtracker@ietfa.amsl.com> Date: Mon, 29 Feb 2016 07:21:30 -0800 Archived-At: X-Mailman-Approved-At: Mon, 29 Feb 2016 07:38:37 -0800 Cc: brian@innovationslab.net, its-chairs@ietf.org, its@ietf.org, smccammon@amsl.com Subject: [its] its - Update to a Meeting Session Request for IETF 95 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 15:21:30 -0000 An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the its working group. --------------------------------------------------------- Working Group Name: Intelligent Transportation Systems Area Name: Internet Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: 6lo dmm 6man dhc manet roll rtgarea ospf isis babel lime stir saag Special Requests: ---------------------------------------------------------