From nobody Sun May 1 02:03:19 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971E912D1DB for ; Sun, 1 May 2016 02:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1DfEjtxuI0a for ; Sun, 1 May 2016 02:03:16 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5D112B04B for ; Sun, 1 May 2016 02:03:16 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id n63so62673100qkf.0 for ; Sun, 01 May 2016 02:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=eIWIf5QG131o/ZAIjxf4QkAdSfdykwUgj5a5iOvKSTk=; b=M+VLvTjbS0lvfgAf64B72grkWuas3m7Xm8nC/VdFz40V7n304TTqJWy7KvrESMOT+L /3BxPqtg9UqG9Ccw4eSkiXjAIXbBaB9QqSVfu71OWq9vr+4bnW7uMv6dIUnLC0Y70PX3 2MSYoEcOfOpS0OpfMvvajHis8HS7xFvqD3m84fyxibTwgSsM76gq071eanUg5mffOMQp lu3qN3hAURxawN0kOBLWi2ro73LhQhKcOYyjwbNciZY4+auV88eEpeJ5M6skNcCw7WEW 0RNPXOOJuymITc+GUvSydZn7A2xd8sMNH4WyNwNLW9N4vOHO6XDPOuRuB7AR8kWiuQTg 5xfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=eIWIf5QG131o/ZAIjxf4QkAdSfdykwUgj5a5iOvKSTk=; b=Ciy4bF7XM4jV4PJoz0BmlqKOZXnhn86APQ8OFa2FCTDt1ehYoudpMNeEBqhkC6VV8o tMzVUGudJzIMSToF0Bmly3s+NdJG4pYF3ZEhLqW0v8jgQ2nbpOavno2yuLQPgCWrFzsF EdYAp7KPIxvMyTWUK6F4IJxNkgDAG46BjWFBS6o5/Gvqfzuz+4a2BIruwPPEEd3HtVZa mKoPJjLvlo1V5RIWv6vISSTlTrtfuaM7iA0QJuzPOVwO9G7wRq7XjGIonZkHs7JfaifE Rc5pDXGqWBxopXySiv66wH6UXKj6WDyo34hECq5/Xaeji28xu0exq6XjGV7XCI5bHXl2 PXUA== X-Gm-Message-State: AOPr4FU6ZW3t78cYj1B2z0Bs1jCXRWWOyvwS15ax4X37xasa/UiXuOe1uGEFzRFLvJ8JpHnMV0Tbb7xN6Ayd3w== MIME-Version: 1.0 X-Received: by 10.55.78.84 with SMTP id c81mr26480942qkb.85.1462093395431; Sun, 01 May 2016 02:03:15 -0700 (PDT) Received: by 10.140.43.52 with HTTP; Sun, 1 May 2016 02:03:15 -0700 (PDT) In-Reply-To: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> References: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> Date: Sun, 1 May 2016 11:03:15 +0200 Message-ID: From: Abdussalam Baryun To: Russ Housley Content-Type: multipart/alternative; boundary=001a114a838076a9260531c42516 Archived-At: Cc: its Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 09:03:18 -0000 --001a114a838076a9260531c42516 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, I support this charter, AB On Mon, Apr 25, 2016 at 2:59 PM, Russ Housley wrote: > > Carlos and I had a telephone conversation with our Area Director for this > group, Suresh Krishnan. The result of the discussion was some pretty cle= ar > and pragmatic suggestions about the charter. > > The suggestion is that the ITS WG have only two deliverables in the > initial charter. Once these two documents are delivered to the IESG, the= n > the group can recharter to tackle other things. > > An Informational RFC that covers: > - What is ITS? > =E2=80=94 Explain V2V, V2I, and so on > - Why is IPv6 needed? > =E2=80=94 Explain why some traffic will not use IPv6 > =E2=80=94 Explain why other traffic will use IPv6 > - Problem statement > - Use-cases > - Security considerations > - Privacy considerations > > A Standards-Track RFC that covers: > - IPv6 over DSRC > > Russ > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --001a114a838076a9260531c42516 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, I support this charter,

AB

On Mon, Apr 2= 5, 2016 at 2:59 PM, Russ Housley <housley@vigilsec.com> w= rote:

Carlos and I had a telephone conversation with our Area Director for this g= roup, Suresh Krishnan.=C2=A0 The result of the discussion was some pretty c= lear and pragmatic suggestions about the charter.

The suggestion is that the ITS WG have only two deliverables in the initial= charter.=C2=A0 Once these two documents are delivered to the IESG, then th= e group can recharter to tackle other things.

An Informational RFC that covers:
=C2=A0- What is ITS?
=C2=A0 =C2=A0 =E2=80=94 Explain V2V, V2I, and so on
=C2=A0- Why is IPv6 needed?
=C2=A0 =C2=A0 =E2=80=94 Explain why some traffic will not use IPv6
=C2=A0 =C2=A0 =E2=80=94 Explain why other traffic will use IPv6
=C2=A0- Problem statement
=C2=A0- Use-cases
=C2=A0- Security considerations
=C2=A0- Privacy considerations

A Standards-Track RFC that covers:
=C2=A0- IPv6 over DSRC

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

--001a114a838076a9260531c42516-- From nobody Mon May 2 06:40:59 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C512712D09D for ; Mon, 2 May 2016 06:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmUlwFGlXPE2 for ; Mon, 2 May 2016 06:40:56 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDDC12B022 for ; Mon, 2 May 2016 06:40:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u42DeoJa008057; Mon, 2 May 2016 15:40:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 219D6208B97; Mon, 2 May 2016 15:42:36 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0C18A20222F; Mon, 2 May 2016 15:42:36 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u42DenoP022500; Mon, 2 May 2016 15:40:49 +0200 To: "Templin, Fred L" , "its@ietf.org" References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> From: Alexandre Petrescu Message-ID: <572758E1.7020803@gmail.com> Date: Mon, 2 May 2016 15:40:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 13:40:58 -0000 Le 29/04/2016 20:21, Templin, Fred L a écrit : > Hi, I have one other charter text suggestion: > >> Co-existence with techniques of infrastructure mobility management will >> be coordinated with the DMM Working Group and with LISP Working Group. > > Add to this: > > Other infrastructure mobility management solutions such as AERO will > also be considered. Fred, Let's bring that later. Alex > > Thanks - Fred > > From nobody Mon May 2 06:42:38 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B3512D09D for ; Mon, 2 May 2016 06:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZjZYX_PKDvA for ; Mon, 2 May 2016 06:42:34 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB5412B022 for ; Mon, 2 May 2016 06:42:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u42DgWFQ007132 for ; Mon, 2 May 2016 15:42:32 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 21BD3208CE3 for ; Mon, 2 May 2016 15:44:18 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 19141208CB8 for ; Mon, 2 May 2016 15:44:18 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u42DgVnm023803 for ; Mon, 2 May 2016 15:42:31 +0200 To: its@ietf.org References: <04032E3A-EF9D-4EB0-A9CC-DCF4DD0DB1D8@vigilsec.com> From: Alexandre Petrescu Message-ID: <57275947.6080304@gmail.com> Date: Mon, 2 May 2016 15:42:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] ITS Charter Discussion X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 13:42:36 -0000 Charlie, I included this split in the charter text. Alex Le 28/04/2016 19:43, Charlie Perkins a écrit : > Hello folks, > > I think this outline for a charter is reasonable. The informational RFC > as proposed has a very broad scope, so it would need to be envisioned > more as a survey article but aimed at supporting a problem statement. > Perhaps there could be two Informational RFCs: > > One Informational RFC that covers: > - What is ITS? > — Explain V2V, V2I, and so on (including terminology) > - Why is IPv6 needed? > — Explain why some traffic will not use IPv6 > — Explain why other traffic will use IPv6 > - Use-cases, illustrating the expected areas for initial focus > - Informative references, relationship with other SDOs > > > Another Informational RFC that covers: > - Problem statement > - Security considerations > - Privacy considerations > > > The security and privacy considerations are themselves closely related, > and crucial to the problem statement. > > I think the general problem area is very important and that the IETF has > a great deal to offer. This is especially true given current efforts > towards self-driving cars, which seem very likely to place urgent > demands on networking protocols. I don't have deployment experience or > any immediate plans for implementation, but I do also work with IEEE 802 > Wireless and I think that will provide a useful alternative perspective. > > Regards, > Charlie P. > > On 4/25/2016 5:59 AM, Russ Housley wrote: >> Carlos and I had a telephone conversation with our Area Director for >> this group, Suresh Krishnan. The result of the discussion was some >> pretty clear and pragmatic suggestions about the charter. >> >> The suggestion is that the ITS WG have only two deliverables in the >> initial charter. Once these two documents are delivered to the IESG, >> then the group can recharter to tackle other things. >> >> An Informational RFC that covers: >> - What is ITS? >> — Explain V2V, V2I, and so on >> - Why is IPv6 needed? >> — Explain why some traffic will not use IPv6 >> — Explain why other traffic will use IPv6 >> - Problem statement >> - Use-cases >> - Security considerations >> - Privacy considerations >> >> A Standards-Track RFC that covers: >> - IPv6 over DSRC >> >> Russ >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Mon May 2 06:48:41 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C9012B009 for ; Mon, 2 May 2016 06:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCjaK6ULdjVn for ; Mon, 2 May 2016 06:48:37 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C4212D0B2 for ; Mon, 2 May 2016 06:48:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u42DmXGq022470 for ; Mon, 2 May 2016 15:48:33 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DE328208CFB for ; Mon, 2 May 2016 15:50:19 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D555F206D86 for ; Mon, 2 May 2016 15:50:19 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u42DmXsb028767 for ; Mon, 2 May 2016 15:48:33 +0200 To: "its@ietf.org" References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> From: Alexandre Petrescu Message-ID: <57275AB1.5030308@gmail.com> Date: Mon, 2 May 2016 15:48:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <571F6758.4050402@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 13:48:39 -0000 Hi ITSers, The latest charter text is now at http://tools.ietf.org/wg/its/trac Alex Pasted here for convenience: '''Intelligent Transportation Systems (its), Charter''' '''Chairs''' Russ Housley, Carlos Pignataro '''Assigned Area Director''' Suresh Krishnan '''Mailing list''' Address: its@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: http://www.ietf.org/mail-archive/web/its/current/maillist.html '''Additional web page''' TBD '''Charter''' {{{ Automobiles and vehicles of all types are increasingly connected to the Internet. Comfort-enhancing entertainment applications, road safety applications using bidirectional data flows, and connected automated driving are but a few new features expected in automobiles to hit the roads from now to year 2020. Today, there are several deployed Vehicle-to-Internet technologies (V2Internet) that make use of embedded Internet modules, or through driver's cellular smartphone: mirrorlink, carplay, android auto. However, Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I, not to be mistaken with V2Internet) communications are still being developed. In the future, some vehicle communications may not use IP for exchanging safety messages with other vehicles and infrastructure. Other vehicle communications may involve IP-based protocols, especially when multiple applications need to share one data link. This group will work on V2V and V2I use-cases where IP is well-suited as a networking technology, supporting also applications that involve exchanges of safety-related messages between vehicles and infrastructure if necessary. This group will develop IP-based protocols to establish direct and secure connectivity between a vehicle, which is often comprised of moving networks, and other vehicles and stationary systems. Some communications will be extremely short lived, but others will last for many hours or days. Moving network to nearby moving or fixed network communications may involve various kinds of link layers: 802.11-OCB (Outside the Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ad, VLC (Visible Light Communications), IrDA, LTE-D, LP-WAN. One of the most used link layers for vehicular networks is IEEE 802.11-OCB, as a basis for DSRC. However, IPv6 on 802.11-OCB is not yet defined. The group will only work on IPv6 solutions. The group will leverage on technologies for Internet of Things (IoT) which are developed in other IETF efforts: 6lo, LP-WAN, T2T. Co-existence with techniques of infrastructure mobility management will be coordinated with the DMM Working Group and with LISP Working Group. The SDOs interested in this work are: ISO/TC204, ETSI TC ITS, 3GPP, NHTSA and more. This group will not work on V2V or V2I use-cases where IP is not well-suited. It will not work on Delay-Tolerant Networking nor on Information-Centric Networking. If the group is successful in accomplishing its first goals, then it can be rechartered to work on other things (examples include but are not limited to: a 1-hop mechanism of IP prefix exchange between moving networks, an n-hop extension, naming for moving networks; generalization for trains, air, unmanned and space use-cases). }}} '''Work items''' {{{ 1. Informational RFC "ITS General Problem Area" covering: - What is ITS? - Explain V2V, V2I, and related terms - Why is IPv6 needed? - Explain why some traffic will not use IPv6 - Explain why other traffic will use IPv6 - Use-cases, illustrating the expected areas for initial focus - Informative references, relationship with other SDOs 2. Standards Track RFC "IPv6 over DSRC" 3. Informational RFC "Problem Statement" covering: - Problem statement - Security considerations - Privacy considerations }}} '''Goals and milestones''' {{{ Oct 2016 - submit "ITS General Problem Area" to WG Dec 2016 - submit "IPv6 over DSRC" to WG Jun 2017 - submit "ITS General Problem Area" to IESG Jun 2017 - submit "IPv6 over DSRC" to IESG Sep 2017 - submit "Problem Statement" to WG May 2018 - submit "Problem Statement" to IESG }}} From nobody Mon May 2 09:06:17 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5696212B04C for ; Mon, 2 May 2016 09:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1PeSpZvkOdY for ; Mon, 2 May 2016 09:06:14 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3C112B006 for ; Mon, 2 May 2016 09:06:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u42G6NYp030765; Mon, 2 May 2016 09:06:23 -0700 Received: from XCH15-01-05.nw.nos.boeing.com (xch15-01-05.nw.nos.boeing.com [137.137.100.15]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u42G6Ef2030625 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK) for ; Mon, 2 May 2016 09:06:14 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-01-05.nw.nos.boeing.com (2002:8989:640f::8989:640f) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 2 May 2016 09:06:03 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 2 May 2016 09:06:03 -0700 From: "Templin, Fred L" To: "its@ietf.org" Thread-Topic: I-D Action: draft-skeen-6man-ipv6geo-02.txt Thread-Index: AQHRpIvsZ3X8/fRso0azOw/hAprEYJ+lzu3A Date: Mon, 2 May 2016 16:06:03 +0000 Message-ID: References: <20160502160120.15656.58030.idtracker@ietfa.amsl.com> In-Reply-To: <20160502160120.15656.58030.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "Skeen, Brian L" , "King, Edwin E" Subject: [its] FW: I-D Action: draft-skeen-6man-ipv6geo-02.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 16:06:16 -0000 Hello, We have published an update of this draft to include the automotive V2V and V2I use cases per the proposed ITS charter. The idea is to include geolocat= ion information in the headers of IPv6 packets that would be exchanged between vehicles and or vehicle-to-infrastructure. Please review and provide indica= tion as to whether this can be incorporated into the charter. Thanks - Fred fred.l.templin@boeing.com -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Monday, May 02, 2016 9:01 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-skeen-6man-ipv6geo-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Including Geolocation Information in IPv6 Packet = Headers (IPv6 GEO) Authors : Brian Skeen Edwin King Fred L. Templin Filename : draft-skeen-6man-ipv6geo-02.txt Pages : 13 Date : 2016-05-02 Abstract: This document provides a specification for including geolocation information in the headers of IPv6 packets (IPv6 GEO). The information is intended to be included in packets for which the location of the source node is to be conveyed via the network to the destination node or nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-skeen-6man-ipv6geo/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-skeen-6man-ipv6geo-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-skeen-6man-ipv6geo-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue May 3 16:58:45 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D761812DB54 for ; Tue, 3 May 2016 16:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOvkzxd2fZVH for ; Tue, 3 May 2016 16:58:42 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC5312D8C7 for ; Tue, 3 May 2016 16:58:42 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id 77so17261487pfv.2 for ; Tue, 03 May 2016 16:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to; bh=x9Us8sNwBHJx/Lx1Dm9h4ROndzeXxfKyPMXAuEjp1nQ=; b=cEeDOFDRAQUd2XqhIAu+3VK5c2vTorIZthFmX9xglypwX7JnKlxyFcdvg3kYCH0mKy iRG8BLsbxvPfCzK6diXz7tgL3J7cHn7zV4YAW8uUi8j7P0OTyg8QjPptsDR+1ATxYoHE 2YEiDQpvCEkxstavqEe3sWb5NpeN6LWYMEIQuiF+sjn7btX+r/gqF9OHDrAKZ4KfaImD WPBlAw9HF+8RJ/ZoqGfB8y2k87OTuENxvKqOt03cm6BCXkzirEuvTyi37su2rJbycnpk j77pag6S/enICON3bvgH1nEeaxtSbsv7bi/9gK6IE44+PkA2t4EkdAS4MSI+RCp7kykQ LxgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to; bh=x9Us8sNwBHJx/Lx1Dm9h4ROndzeXxfKyPMXAuEjp1nQ=; b=jVqRtbiGj7l2w/OOiwcjiiijgaRIlV2utZcTtIaKahjSXs+rtqqJZSSKEoJzdnYkel 2C/VG5kNluCW0oLJyx9Sqa+Fiq78cCWp7aBtpio3R4pyyDcvEHjEhJ7JfJjzlgJwb/bs yFYIml7ULjuxyyHx69kNyNvxE0EsbII5qwQY5awJEqoHBzmSa367NZFC1pIPrVsLZx3o 3zZst+7sXbohVRrHE2crE8QaLnGmGY20OKH6NgdiVxESxIxy4jT1jtchgR3YOmLCMnkH IFIaf1Sb0Nn7iBQusFMFYlbq+jYgFT24GeCQEDrCkWkJ9rFFQyfJ+so7z81+EBuWgj/V qO/g== X-Gm-Message-State: AOPr4FV/EEw7sc2FFYrIxsFh5O7DlQPp8R1fkpZwoLvE2YazhipAlRXmEh2tuYa0ZFtVJg== X-Received: by 10.98.81.195 with SMTP id f186mr7822090pfb.30.1462319921697; Tue, 03 May 2016 16:58:41 -0700 (PDT) Received: from [192.168.0.103] ([203.230.193.110]) by smtp.gmail.com with ESMTPSA id 8sm778705pfk.69.2016.05.03.16.58.40 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2016 16:58:41 -0700 (PDT) References: <20160427012459.30204.57983.idtracker@ietfa.amsl.com> To: its@ietf.org From: Jong-Hyouk Lee X-Forwarded-Message-Id: <20160427012459.30204.57983.idtracker@ietfa.amsl.com> Message-ID: <57293B2E.3020307@gmail.com> Date: Wed, 4 May 2016 08:58:38 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160427012459.30204.57983.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080702050908050301070502" Archived-At: Subject: [its] Fwd: I-D Action: draft-yan-its-nd-00.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 23:58:45 -0000 This is a multi-part message in MIME format. --------------080702050908050301070502 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit FYI. -------- Forwarded Message -------- Subject: I-D Action: draft-yan-its-nd-00.txt Date: Tue, 26 Apr 2016 18:24:59 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Neighbor discovery to support direct communication in ITS Authors : Zhiwei Yan Jong-Hyouk Lee Filename : draft-yan-its-nd-00.txt Pages : 5 Date : 2016-04-26 Abstract: For C-ACC, Platooning and other typical use cases in ITS, how to establish direct IP communication paths between neighbor vehicles poses "how to discover the neighbors" as the prime issue. In this draft, the issue is analyzed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-yan-its-nd/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-yan-its-nd-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------080702050908050301070502 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit FYI.


-------- Forwarded Message --------
Subject: I-D Action: draft-yan-its-nd-00.txt
Date: Tue, 26 Apr 2016 18:24:59 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : Neighbor discovery to support direct communication in ITS
        Authors         : Zhiwei Yan
                          Jong-Hyouk Lee
	Filename        : draft-yan-its-nd-00.txt
	Pages           : 5
	Date            : 2016-04-26

Abstract:
   For C-ACC, Platooning and other typical use cases in ITS, how to
   establish direct IP communication paths between neighbor vehicles
   poses "how to discover the neighbors" as the prime issue.  In this
   draft, the issue is analyzed.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-yan-its-nd/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-yan-its-nd-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--------------080702050908050301070502-- From nobody Tue May 3 16:59:17 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0974412DC1C for ; Tue, 3 May 2016 16:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbwPc7qXuK-y for ; Tue, 3 May 2016 16:59:13 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 908A012DB54 for ; Tue, 3 May 2016 16:59:13 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 77so17266210pfv.2 for ; Tue, 03 May 2016 16:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to; bh=ZKeWB8nmh93PPVUct/Ky5kqoe9iZOPAcJs8dNaKAnr8=; b=0DsYRpagdCCSSWt3BP1ibxpwVXOmLwhX7vQ00exVsW/8qc6t5xvKOw1pEE1WsVRcI1 AqCkJtmEc7NvWeqeGAzAi213dKz9ohH1p0sKNgl/IZ74Sbe5tiHmI+Le8/m3JDmHBqtI gMb5Za0hCL+zrR2GNxgGcFcdqfLsNhy4fKo0sj5Wj0jZ5zN4ERBq1DL8KLpJwvoiPTd4 4OfaZflHgkXh4iE5gAoxqyXcnWMF0QkvuaEpN8uLsK3w4CpIuisr4GmnOTmnk/ieMULx A3ffiw7b5hKTavF5DAiPw7yIl3NmwYN0h8zgnqL+APPCsL++ZOx+Xt/i75l8OhpmLvrd 9UJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to; bh=ZKeWB8nmh93PPVUct/Ky5kqoe9iZOPAcJs8dNaKAnr8=; b=lpI23pXkrmAdptOJD/2PHivuKuBcaNFHU9dK9EBkdXxC1CAhcrZ0inIvXyEBe2ZZR1 LqK1xxMgsUBWDHAhFxrJvvD/XqGTt4bFPQxXfnDAFVows8kcL8eDMvINCRHnNpKqXmIi 8YhCAw35OVIx6NTLQLjIJHb6vYMpD/VREMTzRkJp0tAxaCm3MwjOZeluRRQpxnHSDcht QwlOItne5tnMpdT4AoFDbJpiOxBSJR+SJ3ivqrAEAzF5WFBF/Du/RIpNksWB20QVkv0J V961jhafr380TYxohrEjQhPoeoqjPNf9gGiQBmHTFrHCDZxH1iN9j86KdEwwqUtW6EC8 15VQ== X-Gm-Message-State: AOPr4FWWiUoCg2RlCQsbMRjPnyj8Gta7zpKNNDCeHSM/I3idEnbwxxlk0/Re/r+2FdM2Qg== X-Received: by 10.98.89.28 with SMTP id n28mr7787062pfb.41.1462319953277; Tue, 03 May 2016 16:59:13 -0700 (PDT) Received: from [192.168.0.103] ([203.230.193.110]) by smtp.gmail.com with ESMTPSA id rw2sm774464pab.30.2016.05.03.16.59.12 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2016 16:59:12 -0700 (PDT) References: <20160427012439.30049.21472.idtracker@ietfa.amsl.com> To: its@ietf.org From: Jong-Hyouk Lee X-Forwarded-Message-Id: <20160427012439.30049.21472.idtracker@ietfa.amsl.com> Message-ID: <57293B4D.9000705@gmail.com> Date: Wed, 4 May 2016 08:59:09 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160427012439.30049.21472.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090302040306050500080001" Archived-At: Subject: [its] Fwd: I-D Action: draft-yan-its-aggregation-00.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 23:59:17 -0000 This is a multi-part message in MIME format. --------------090302040306050500080001 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit FYI. -------- Forwarded Message -------- Subject: I-D Action: draft-yan-its-aggregation-00.txt Date: Tue, 26 Apr 2016 18:24:39 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Data Aggregation in Intelligent Transportation Systems Authors : Zhiwei Yan Jong-Hyouk Lee Filename : draft-yan-its-aggregation-00.txt Pages : 7 Date : 2016-04-26 Abstract: Considering the large-scale but small-sized information exchange in the vehicular information network, this draft aims to outline the requirements to support the data aggregation in ITS, in order to make the information retrieval and dissemination more efficient. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-yan-its-aggregation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-yan-its-aggregation-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------090302040306050500080001 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit FYI.


-------- Forwarded Message --------
Subject: I-D Action: draft-yan-its-aggregation-00.txt
Date: Tue, 26 Apr 2016 18:24:39 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : Requirements for Data Aggregation in Intelligent Transportation Systems
        Authors         : Zhiwei Yan
                          Jong-Hyouk Lee
	Filename        : draft-yan-its-aggregation-00.txt
	Pages           : 7
	Date            : 2016-04-26

Abstract:
   Considering the large-scale but small-sized information exchange in
   the vehicular information network, this draft aims to outline the
   requirements to support the data aggregation in ITS, in order to make
   the information retrieval and dissemination more efficient.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-yan-its-aggregation/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-yan-its-aggregation-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--------------090302040306050500080001-- From nobody Fri May 6 07:38:09 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F4912D616 for ; Fri, 6 May 2016 07:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-XUWznY-JPX for ; Fri, 6 May 2016 07:38:06 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F219B12D61F for ; Fri, 6 May 2016 07:38:05 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id u64so134104206lff.3 for ; Fri, 06 May 2016 07:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=v5DE0jM6MdxN7u6DIDm151DjZb+tCnTX3h0MdtVAfss=; b=tjtyFmmZ0VwFIQaMwUiZeAiVyDaDGznBobMuul2CDnHUeYYw5MhAI8nQQFIF3x7YAP /6STENpuL295CBoH8vCDNe1BIVeik3Pid0C0+/+DUWguOu7E6mr+aBGeZjrFhcmf2XtV 6aQ1VCs3ArK6Gi//eOws+dG538VtEGi9L72yyleIW74QWGpCg4Uz1CneQu8Y2VxmFECe Rq1HDSLHSlaHf9l6xadp/aX9CWNGXMxEzCFTb2IET+16Vl/FFNrP5/2pKYa+p7yvgWmW xhygdKBCRbnFkfiacHm+vq3oFHCRJbPSgfuRPvXHBobfcf2r1xkgyDVB+TpW17SlVmAL 87Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=v5DE0jM6MdxN7u6DIDm151DjZb+tCnTX3h0MdtVAfss=; b=k0VFAf2h7wQ6QO/pZ20tBTu7njv/D2dc5wjFfocIGtz9Qd7tfa9GyqU9DNa78jspCG l1K6Q9MMpLjEhw8qTEw7JHwzeXdZGl9uupD9Xu1en86oxAb30TTzAaRHZQ+BdhAloOXj eVQ7zop/XbtivUL0zQxyoionzGe7NdnVLRcQ8DkdCNTsiiTzXoIzHQkxFRptxPWFrhnN 9jYRcuUiDiipNWhfkRSp0SCag2+p07pYHX2O8GeYdfNd5SLU2KHOg8j61IHKs2QhckkA 3NVB6feww5RuHiWmoZa3xMjU+vHaZWWdOcOpD377RKl6eNqMnepCmg+HN7ess2f6eyor DMiQ== X-Gm-Message-State: AOPr4FXzv2x+GFVJ+eRBP/7qLzhwdbqyK8w/5n9wsh2cXKTqwXoKPA7MMemk0xs2MTjhvClxVt4w7/iTSwC8iA== MIME-Version: 1.0 X-Received: by 10.25.64.212 with SMTP id n203mr10456948lfa.54.1462545484186; Fri, 06 May 2016 07:38:04 -0700 (PDT) Received: by 10.112.167.105 with HTTP; Fri, 6 May 2016 07:38:04 -0700 (PDT) In-Reply-To: <57275AB1.5030308@gmail.com> References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> Date: Fri, 6 May 2016 16:38:04 +0200 Message-ID: From: Michelle Wetterwald To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a113fc26a0d898305322d68e9 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 14:38:08 -0000 --001a113fc26a0d898305322d68e9 Content-Type: text/plain; charset=UTF-8 Hi Alex, all, It is a good idea to restrict to those use cases where IPv6 can be helpful. There are a lot of potential use cases for that and it will avoid creating fragmentation of solutions, as can be seen in other domains. Waiting now for preliminary versions of the informational rfc. We are doing some work at ETSI STF 505 on smart mobility standardization landscape and gap analysis which may be used as a reference. Best regards, Michelle 2016-05-02 15:48 GMT+02:00 Alexandre Petrescu : > Hi ITSers, > > The latest charter text is now at http://tools.ietf.org/wg/its/trac > > Alex > > Pasted here for convenience: > '''Intelligent Transportation Systems (its), Charter''' > > '''Chairs''' > Russ Housley, Carlos Pignataro > > > '''Assigned Area Director''' > Suresh Krishnan > > '''Mailing list''' > Address: its@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/its > Archive: > http://www.ietf.org/mail-archive/web/its/current/maillist.html > > '''Additional web page''' > TBD > > '''Charter''' > {{{ > Automobiles and vehicles of all types are increasingly connected to > the Internet. Comfort-enhancing entertainment applications, road > safety applications using bidirectional data flows, and connected > automated driving are but a few new features expected in automobiles > to hit the roads from now to year 2020. > > Today, there are several deployed Vehicle-to-Internet technologies > (V2Internet) that make use of embedded Internet modules, or through > driver's cellular smartphone: mirrorlink, carplay, android auto. > However, Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I, > not to be mistaken with V2Internet) communications are still being > developed. > > In the future, some vehicle communications may not use IP for > exchanging safety messages with other vehicles and infrastructure. > Other vehicle communications may involve IP-based protocols, > especially when multiple applications need to share one data link. > > This group will work on V2V and V2I use-cases where IP is well-suited > as a networking technology, supporting also applications that involve > exchanges of safety-related messages between vehicles and > infrastructure if necessary. > > This group will develop IP-based protocols to establish direct and > secure connectivity between a vehicle, which is often comprised of > moving networks, and other vehicles and stationary systems. Some > communications will be extremely short lived, but others will last for > many hours or days. > > Moving network to nearby moving or fixed network communications may > involve various kinds of link layers: 802.11-OCB (Outside the Context > of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ad, VLC (Visible > Light Communications), IrDA, LTE-D, LP-WAN. One of the most used link > layers for vehicular networks is IEEE 802.11-OCB, as a basis for DSRC. > However, IPv6 on 802.11-OCB is not yet defined. > > The group will only work on IPv6 solutions. > > The group will leverage on technologies for Internet of Things (IoT) > which are developed in other IETF efforts: 6lo, LP-WAN, T2T. > Co-existence with techniques of infrastructure mobility management > will be coordinated with the DMM Working Group and with LISP Working > Group. > > The SDOs interested in this work are: ISO/TC204, ETSI TC ITS, 3GPP, > NHTSA and more. > > This group will not work on V2V or V2I use-cases where IP is not > well-suited. It will not work on Delay-Tolerant Networking nor on > Information-Centric Networking. > > If the group is successful in accomplishing its first goals, then it > can be rechartered to work on other things (examples include but are > not limited to: a 1-hop mechanism of IP prefix exchange between moving > networks, an n-hop extension, naming for moving networks; > generalization for trains, air, unmanned and space use-cases). > }}} > '''Work items''' > {{{ > 1. Informational RFC "ITS General Problem Area" covering: > - What is ITS? > - Explain V2V, V2I, and related terms > - Why is IPv6 needed? > - Explain why some traffic will not use IPv6 > - Explain why other traffic will use IPv6 > - Use-cases, illustrating the expected areas for initial focus > - Informative references, relationship with other SDOs > > 2. Standards Track RFC "IPv6 over DSRC" > > 3. Informational RFC "Problem Statement" covering: > - Problem statement > - Security considerations > - Privacy considerations > }}} > '''Goals and milestones''' > {{{ > Oct 2016 - submit "ITS General Problem Area" to WG > > Dec 2016 - submit "IPv6 over DSRC" to WG > > Jun 2017 - submit "ITS General Problem Area" to IESG > > Jun 2017 - submit "IPv6 over DSRC" to IESG > > Sep 2017 - submit "Problem Statement" to WG > > May 2018 - submit "Problem Statement" to IESG > > }}} > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > -- Michelle Wetterwald michelle.wetterwald@gmail.com --001a113fc26a0d898305322d68e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alex, all,

It is a good i= dea to restrict to those use cases where IPv6 can be helpful. There are=C2= =A0a lot of potential use cases for that and it will avoid creating fragmen= tation of solutions, as can be seen in other domains. Waiting now for preli= minary versions of the informational rfc. We are doing some work at ETSI ST= F 505 on smart mobility standardization landscape and gap analysis=C2=A0whi= ch may be used as a reference.

Best regards,
=
Michelle


2016-05-02 15:48 GMT+02:00 Alexandre Petrescu <alexandre.petrescu@gmail.com>:
Hi ITSers= ,

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

Alex

Pasted here for convenience:
'''Intelligent Transportation Systems (its), Charter''&= #39;

'''Chairs'''
=C2=A0 =C2=A0Russ Housley, Carlos Pignataro


'''Assigned Area Director'''
=C2=A0 =C2=A0Suresh Krishnan

'''Mailing list'''
=C2=A0 =C2=A0Address: its= @ietf.org
=C2=A0 =C2=A0To Subscribe: https://www.ietf.org/mailman/lis= tinfo/its
=C2=A0 =C2=A0Archive:
=C2=A0 =C2=A0http://www.ietf.org/mail-= archive/web/its/current/maillist.html

'''Additional web page'''
=C2=A0 =C2=A0TBD

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

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

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

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

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

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

The group will only work on IPv6 solutions.

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

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

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

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

2. Standards Track RFC "IPv6 over DSRC"

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

Dec 2016 - submit "IPv6 over DSRC" to WG

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

Jun 2017 - submit "IPv6 over DSRC" to IESG

 Sep 2017 - submit "Problem Statement" to WG

May 2018 - submit "Problem Statement" to IESG

}}}



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



--
Michelle Wetterwald
michelle.w= etterwald@gmail.com
--001a113fc26a0d898305322d68e9-- From nobody Mon May 9 04:15:26 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0899E12D163 for ; Mon, 9 May 2016 04:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.353 X-Spam-Level: X-Spam-Status: No, score=-4.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMqCM-lslm1h for ; Mon, 9 May 2016 04:15:22 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DCD12B031 for ; Mon, 9 May 2016 04:15:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u49BFJc4013512; Mon, 9 May 2016 13:15:19 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 65F9020A4D0; Mon, 9 May 2016 13:17:15 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5864B202526; Mon, 9 May 2016 13:17:15 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u49BFICw030178; Mon, 9 May 2016 13:15:19 +0200 To: Michelle Wetterwald References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> From: Alexandre Petrescu Message-ID: <074e6552-6364-d173-ac4f-1d4d3f954f5f@gmail.com> Date: Mon, 9 May 2016 13:15:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 11:15:25 -0000 Hi Michelle, Le 06/05/2016 à 16:38, Michelle Wetterwald a écrit : > Hi Alex, all, > > It is a good idea to restrict to those use cases where IPv6 can be > helpful. There are a lot of potential use cases for that and it will > avoid creating fragmentation of solutions, as can be seen in other > domains. Waiting now for preliminary versions of the informational > rfc. Do you mean for item 1 "ITS General Problem Area"? Some drafts have been submitted along these lines, and some others are prepared. > We are doing some work at ETSI STF 505 on smart mobility > standardization landscape and gap analysis which may be used as a > reference. Is ETSI STF 505 dealing also with the vehicular communications part of IoT LSPs, like Pilot5? or just smartcities/smartliving? If the former, then we may need to cite ETSI STF 505 documents. Otherwise no. I am asking because the ETSI STF 505 homepage does not seem to mention vehicles such as automobiles, but more smartcities/smartliving. Alex > > Best regards, Michelle > > > 2016-05-02 15:48 GMT+02:00 Alexandre Petrescu > >: > > Hi ITSers, > > The latest charter text is now at http://tools.ietf.org/wg/its/trac > > Alex > > Pasted here for convenience: '''Intelligent Transportation Systems > (its), Charter''' > > '''Chairs''' Russ Housley, Carlos Pignataro > > > '''Assigned Area Director''' Suresh Krishnan > > '''Mailing list''' Address: its@ietf.org To > Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: > http://www.ietf.org/mail-archive/web/its/current/maillist.html > > '''Additional web page''' TBD > > '''Charter''' {{{ Automobiles and vehicles of all types are > increasingly connected to the Internet. Comfort-enhancing > entertainment applications, road safety applications using > bidirectional data flows, and connected automated driving are but a > few new features expected in automobiles to hit the roads from now to > year 2020. > > Today, there are several deployed Vehicle-to-Internet technologies > (V2Internet) that make use of embedded Internet modules, or through > driver's cellular smartphone: mirrorlink, carplay, android auto. > However, Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure > (V2I, not to be mistaken with V2Internet) communications are still > being developed. > > In the future, some vehicle communications may not use IP for > exchanging safety messages with other vehicles and infrastructure. > Other vehicle communications may involve IP-based protocols, > especially when multiple applications need to share one data link. > > This group will work on V2V and V2I use-cases where IP is > well-suited as a networking technology, supporting also applications > that involve exchanges of safety-related messages between vehicles > and infrastructure if necessary. > > This group will develop IP-based protocols to establish direct and > secure connectivity between a vehicle, which is often comprised of > moving networks, and other vehicles and stationary systems. Some > communications will be extremely short lived, but others will last > for many hours or days. > > Moving network to nearby moving or fixed network communications may > involve various kinds of link layers: 802.11-OCB (Outside the > Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ad, VLC > (Visible Light Communications), IrDA, LTE-D, LP-WAN. One of the most > used link layers for vehicular networks is IEEE 802.11-OCB, as a > basis for DSRC. However, IPv6 on 802.11-OCB is not yet defined. > > The group will only work on IPv6 solutions. > > The group will leverage on technologies for Internet of Things (IoT) > which are developed in other IETF efforts: 6lo, LP-WAN, T2T. > Co-existence with techniques of infrastructure mobility management > will be coordinated with the DMM Working Group and with LISP Working > Group. > > The SDOs interested in this work are: ISO/TC204, ETSI TC ITS, 3GPP, > NHTSA and more. > > This group will not work on V2V or V2I use-cases where IP is not > well-suited. It will not work on Delay-Tolerant Networking nor on > Information-Centric Networking. > > If the group is successful in accomplishing its first goals, then it > can be rechartered to work on other things (examples include but are > not limited to: a 1-hop mechanism of IP prefix exchange between > moving networks, an n-hop extension, naming for moving networks; > generalization for trains, air, unmanned and space use-cases). }}} > '''Work items''' {{{ 1. Informational RFC "ITS General Problem Area" > covering: - What is ITS? - Explain V2V, V2I, and related terms - Why > is IPv6 needed? - Explain why some traffic will not use IPv6 - > Explain why other traffic will use IPv6 - Use-cases, illustrating the > expected areas for initial focus - Informative references, > relationship with other SDOs > > 2. Standards Track RFC "IPv6 over DSRC" > > 3. Informational RFC "Problem Statement" covering: - Problem > statement - Security considerations - Privacy considerations }}} > '''Goals and milestones''' {{{ Oct 2016 - submit "ITS General Problem > Area" to WG > > Dec 2016 - submit "IPv6 over DSRC" to WG > > Jun 2017 - submit "ITS General Problem Area" to IESG > > Jun 2017 - submit "IPv6 over DSRC" to IESG > > Sep 2017 - submit "Problem Statement" to WG > > May 2018 - submit "Problem Statement" to IESG > > }}} > > > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > -- Michelle Wetterwald michelle.wetterwald@gmail.com > From nobody Mon May 9 13:11:24 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB7812D0E7 for ; Mon, 9 May 2016 13:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97g0-judznVk for ; Mon, 9 May 2016 13:11:21 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 41D4512D0C4 for ; Mon, 9 May 2016 13:11:21 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id E252CF2401F for ; Mon, 9 May 2016 16:11:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id R4bit1xpKDID for ; Mon, 9 May 2016 15:54:39 -0400 (EDT) Received: from [10.128.112.181] (unknown [207.43.147.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 913E7F24013 for ; Mon, 9 May 2016 16:11:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <9768E8EF-6FA6-4B12-827D-3C1CF5A37FCD@vigilsec.com> Date: Mon, 9 May 2016 16:11:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <259A19B3-8AC8-47EE-A203-4A8D93477826@vigilsec.com> References: <3E7E5AFB-5874-430E-BCBB-95F852773A6C@vigilsec.com> <737CC74B-DB26-4C31-AE21-4B2E51A87BAD@cisco.com> <9768E8EF-6FA6-4B12-827D-3C1CF5A37FCD@vigilsec.com> To: its@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [its] Scheduling an ITS Virtual Interim X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 20:11:23 -0000 If we are going to hold a virtual interim before the end of the month, = then we need to pick the date and time in the next few days. Please take the doodle pool so that the chairs can hove more that their = own calendar information to make a choice. http://doodle.com/poll/zmwc79nuhhadsxiz Russ From nobody Tue May 10 03:57:21 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42D212D11A for ; Tue, 10 May 2016 03:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlTUX4ROU2Lk for ; Tue, 10 May 2016 03:57:17 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2754312B045 for ; Tue, 10 May 2016 03:57:17 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id y84so10365416lfc.0 for ; Tue, 10 May 2016 03:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=30jWUoq4FqvQ+PtJFwhQXXKh5Pl3a+Gzz8Ofg0oNnxk=; b=nJ+RdN32VLe1bErN/49c1LewPYQWPlRTNpxikLGHH0sqpnxMM2y3y3t4Flmk+c5Bxo 2sWj6JVfHnCyhPJ0PXvwEp33Obz2iWAVJnL3Xnr2BgHUL+vVJuAIbduvrHdTDECMfK2J OZmydPDY+urCbyWrnn+MtCoswMr/xb0VttZHmEKpZKa35WiPKOxIgBvQ1yr6y3GXWyGf 4CRK3yoJxh8TpVjq52QGuGRpg/RmGycFM6UNH3gJXD1a6GGqdEsw77hsf4cdjgAKb/+X xyjmyy/8hC7WfEgZN+uF7kSvzRuVG80ZBoy5JlwpKh7vvuslW08iWpQwWGTj2VV1z8PF 7g7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=30jWUoq4FqvQ+PtJFwhQXXKh5Pl3a+Gzz8Ofg0oNnxk=; b=NVjw5cKgPveyh8AkjlyYBVsGRGYrzLebdMIZU+IJxKCBqxFQV9rzjn24y0ilkTsZNg tKOBsAnKHvryvluhxf8zYYte/gwKDZSHow/jSO9FN1vXqE7uOyAD5qzkI7wDsr0sqlZl WWFUCrnYB2c4FjMwhqu4NQ/YjkRNusamYoA0JK6MdOuvizdzI4flWnq1nK4rHX7UI/kO oGJkJDkTb97K5dRBRTI/lCvxXoclIBdX5sO2DQxigiyvRmTiRE70nM4VKVgyBQK3rgzH Kv+lrQLG5nKS2EkGnijxN/G7Xp5rHQLPhgRF/fwUblzlrIfdFX9/DDexRLg0m6zTMEdO Crvw== X-Gm-Message-State: AOPr4FWULu1tDsVU0dL9KK5rALgves2s5EV+mLgKXq0agC15NVIEg2dt3luTsZlZUGOy0/XpFOfzWVO5qa2MoA== MIME-Version: 1.0 X-Received: by 10.112.164.39 with SMTP id yn7mr13923622lbb.103.1462877835258; Tue, 10 May 2016 03:57:15 -0700 (PDT) Received: by 10.112.167.105 with HTTP; Tue, 10 May 2016 03:57:15 -0700 (PDT) In-Reply-To: <074e6552-6364-d173-ac4f-1d4d3f954f5f@gmail.com> References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> <074e6552-6364-d173-ac4f-1d4d3f954f5f@gmail.com> Date: Tue, 10 May 2016 12:57:15 +0200 Message-ID: From: Michelle Wetterwald To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a11c25a04b874bf05327ac908 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 10:57:20 -0000 --001a11c25a04b874bf05327ac908 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alex, STF 505 is looking at seven verticals domains, five of them are those addressed by the LSPs. In particular, we are covering Smart Cities and Smart Mobility, which include ITS and may be relevant here. The result of the technical study will be published as TR 103 375 (standards landscape) and TR 103 376 (gap analysis). You can cite these reports, as they also mention IPv6 for these domains, together with other V2X standards. Best, Michelle 2016-05-09 13:15 GMT+02:00 Alexandre Petrescu : > Hi Michelle, > > Le 06/05/2016 =C3=A0 16:38, Michelle Wetterwald a =C3=A9crit : > >> Hi Alex, all, >> >> It is a good idea to restrict to those use cases where IPv6 can be >> helpful. There are a lot of potential use cases for that and it will >> avoid creating fragmentation of solutions, as can be seen in other >> domains. Waiting now for preliminary versions of the informational >> rfc. >> > > Do you mean for item 1 "ITS General Problem Area"? > > Some drafts have been submitted along these lines, and some others are > prepared. > > We are doing some work at ETSI STF 505 on smart mobility >> standardization landscape and gap analysis which may be used as a >> reference. >> > > Is ETSI STF 505 dealing also with the vehicular communications part of > IoT LSPs, like Pilot5? or just smartcities/smartliving? > > If the former, then we may need to cite ETSI STF 505 documents. > Otherwise no. > > I am asking because the ETSI STF 505 homepage does not seem to mention > vehicles such as automobiles, but more smartcities/smartliving. > > Alex > > >> Best regards, Michelle >> >> >> 2016-05-02 15:48 GMT+02:00 Alexandre Petrescu >> > >: >> >> Hi ITSers, >> >> The latest charter text is now at http://tools.ietf.org/wg/its/trac >> >> Alex >> >> Pasted here for convenience: '''Intelligent Transportation Systems >> (its), Charter''' >> >> '''Chairs''' Russ Housley, Carlos Pignataro >> >> >> '''Assigned Area Director''' Suresh Krishnan >> >> '''Mailing list''' Address: its@ietf.org To >> >> Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: >> http://www.ietf.org/mail-archive/web/its/current/maillist.html >> >> '''Additional web page''' TBD >> >> '''Charter''' {{{ Automobiles and vehicles of all types are >> increasingly connected to the Internet. Comfort-enhancing >> entertainment applications, road safety applications using >> bidirectional data flows, and connected automated driving are but a >> few new features expected in automobiles to hit the roads from now to >> year 2020. >> >> Today, there are several deployed Vehicle-to-Internet technologies >> (V2Internet) that make use of embedded Internet modules, or through >> driver's cellular smartphone: mirrorlink, carplay, android auto. >> However, Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure >> (V2I, not to be mistaken with V2Internet) communications are still >> being developed. >> >> In the future, some vehicle communications may not use IP for >> exchanging safety messages with other vehicles and infrastructure. >> Other vehicle communications may involve IP-based protocols, >> especially when multiple applications need to share one data link. >> >> This group will work on V2V and V2I use-cases where IP is >> well-suited as a networking technology, supporting also applications >> that involve exchanges of safety-related messages between vehicles >> and infrastructure if necessary. >> >> This group will develop IP-based protocols to establish direct and >> secure connectivity between a vehicle, which is often comprised of >> moving networks, and other vehicles and stationary systems. Some >> communications will be extremely short lived, but others will last >> for many hours or days. >> >> Moving network to nearby moving or fixed network communications may >> involve various kinds of link layers: 802.11-OCB (Outside the >> Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ad, VLC >> (Visible Light Communications), IrDA, LTE-D, LP-WAN. One of the most >> used link layers for vehicular networks is IEEE 802.11-OCB, as a >> basis for DSRC. However, IPv6 on 802.11-OCB is not yet defined. >> >> The group will only work on IPv6 solutions. >> >> The group will leverage on technologies for Internet of Things (IoT) >> which are developed in other IETF efforts: 6lo, LP-WAN, T2T. >> Co-existence with techniques of infrastructure mobility management >> will be coordinated with the DMM Working Group and with LISP Working >> Group. >> >> The SDOs interested in this work are: ISO/TC204, ETSI TC ITS, 3GPP, >> NHTSA and more. >> >> This group will not work on V2V or V2I use-cases where IP is not >> well-suited. It will not work on Delay-Tolerant Networking nor on >> Information-Centric Networking. >> >> If the group is successful in accomplishing its first goals, then it >> can be rechartered to work on other things (examples include but are >> not limited to: a 1-hop mechanism of IP prefix exchange between >> moving networks, an n-hop extension, naming for moving networks; >> generalization for trains, air, unmanned and space use-cases). }}} >> '''Work items''' {{{ 1. Informational RFC "ITS General Problem Area" >> covering: - What is ITS? - Explain V2V, V2I, and related terms - Why >> is IPv6 needed? - Explain why some traffic will not use IPv6 - >> Explain why other traffic will use IPv6 - Use-cases, illustrating the >> expected areas for initial focus - Informative references, >> relationship with other SDOs >> >> 2. Standards Track RFC "IPv6 over DSRC" >> >> 3. Informational RFC "Problem Statement" covering: - Problem >> statement - Security considerations - Privacy considerations }}} >> '''Goals and milestones''' {{{ Oct 2016 - submit "ITS General Problem >> Area" to WG >> >> Dec 2016 - submit "IPv6 over DSRC" to WG >> >> Jun 2017 - submit "ITS General Problem Area" to IESG >> >> Jun 2017 - submit "IPv6 over DSRC" to IESG >> >> Sep 2017 - submit "Problem Statement" to WG >> >> May 2018 - submit "Problem Statement" to IESG >> >> }}} >> >> >> >> _______________________________________________ its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> >> >> >> -- Michelle Wetterwald michelle.wetterwald@gmail.com >> >> > --=20 Michelle Wetterwald michelle.wetterwald@gmail.com --001a11c25a04b874bf05327ac908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alex,

STF 505 is looking = at seven verticals domains, five of them are those addressed by the=C2=A0LS= Ps.
In particular, we are covering Smart Cities and Smart Mobili= ty, which include ITS=C2=A0and may be relevant here.
The result o= f the technical study will be published as TR 103 375 (standards landscape)= and TR 103 376 (gap analysis).
You can cite these reports, as th= ey also mention IPv6=C2=A0for these domains, together with other V2X standa= rds.

Best, Michelle=C2=A0


2016-05-09 13:15 GMT+= 02:00 Alexandre Petrescu <alexandre.petrescu@gmail.com><= /span>:
Hi Michelle,

Le 06/05/2016 =C3=A0 16:38, Michelle Wetterwald a =C3=A9crit :
Hi Alex, all,

It is a good idea to restrict to those use cases where IPv6 can be
helpful. There are a lot of potential use cases for that and it will
avoid creating fragmentation of solutions, as can be seen in other
domains. Waiting now for preliminary versions of the informational
rfc.

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

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

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

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

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

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

Alex


Best regards, Michelle


2016-05-02 15:48 GMT+02:00 Alexandre Petrescu
<alexa= ndre.petrescu@gmail.com
 <mailto:alexandre.petrescu@gmail.com>>:

Hi ITSers,

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

Alex

Pasted here for convenience: '''Intelligent Transportation Syst= ems
(its), Charter'''

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


'''Assigned Area Director''' Suresh Krishnan

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

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

'''Additional web page''' TBD

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

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

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

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

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

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

The group will only work on IPv6 solutions.

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

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

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

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

2. Standards Track RFC "IPv6 over DSRC"

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

Dec 2016 - submit "IPv6 over DSRC" to WG

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

Jun 2017 - submit "IPv6 over DSRC" to IESG

Sep 2017 - submit "Problem Statement" to WG

May 2018 - submit "Problem Statement" to IESG

}}}



_______________________________________________ its mailing list
its@ietf.org<= /a> <mailto:its@ietf.o= rg>
https://www.ietf.org/mailman/listinfo/its




-- Michelle Wetterwald michelle.wetterwald@gmail.com
 <mailto:michelle.wetterwald@gmail.com>



--
--001a11c25a04b874bf05327ac908-- From nobody Wed May 11 05:42:30 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACE512D12B for ; Wed, 11 May 2016 05:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRIn9fJupO4f for ; Wed, 11 May 2016 05:42:25 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6691512D0EB for ; Wed, 11 May 2016 05:42:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4BCgLCs001211; Wed, 11 May 2016 14:42:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7133720560F; Wed, 11 May 2016 14:44:20 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5A596205656; Wed, 11 May 2016 14:44:20 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4BCgLbr007020; Wed, 11 May 2016 14:42:21 +0200 To: Alex Voronov , "its@ietf.org" References: <544A6D4F.3060401@gmail.com> <544E5FE4.4000503@gmail.com> <571F346F.6060500@gmail.com> <7DA761D0-F7E3-4438-AB58-F989B430E321@viktoria.se> From: Alexandru Petrescu Message-ID: <23bb0958-534e-5ab2-023f-97a2b488df7a@gmail.com> Date: Wed, 11 May 2016 14:42:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Albin Severinson , Alex Voronov , Lei Chen , "Jan \(J.F.C.M.\) de Jongh" Subject: Re: [its] 802.11p and gcdc 2016 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 12:42:29 -0000 Hi Alex Voronov, Thanks for the reply. I am happy there is RNDITS - an open source vehicle-to-vehicle communication unit. Yours, Alex Petrescu Le 26/04/2016 à 22:05, Alex Voronov a écrit : > Hi All, > > Here is a direct link to the document compiled during the preparation of > the GCDC2016 with the instructions to set up CTU-IIG > drivers: http://www.gcdc.net/images/doc/REP.802.11p-on-APU1D.pdf , which > originate from https://gist.github.com/lisovy/80dde5a792e774a706a9 . > > One of the students participating in GCDC, Albin, even created a website > for the complete communication unit: http://rndits.com/ > > So 802.11p, and even GN\BTP\ASN.1\CAM+DENM seem to work :-) > > > Best Regards, > > Alex Voronov > > > > On 26 April 2016 at 13:10, Lei Chen > wrote: > > Thanks Alex, it is going well with GCDC2016. We have successfully > conducted safety and communication test at the the test site in > IDIADA. We are now at the final stage of planning and the Challenge > will be on 28 - 29 May. There will also be one week preparation > workshop at Helmond, and one day congress following the challenge. > > The 802.11p drivers is the one modified by CTU-IIG > (https://github.com/CTU-IIG). As described here > (https://github.com/alexvoronov/geonetworking/blob/master/HARDWARE.md) > with my colleague Alex, it seems 802.11p is not yet very well > integrated. And GCDC provides with a step by step installation guide > for 802.11p on ALIX APU1D running Voyage. All information can be > found at GCDC site (http://gcdc.net/en/). > > Again, we take the opportunity to invite all ITS experts to come and > join the challenge. Promise it will be exciting. > > BR > Lei > >> On 26 Apr 2016, at 11:27, Alexandru Petrescu >> > > wrote: >> >> Hi Lei, >> >> I hope the GCDC 2016 plan is advancing well. >> >> Any idea what are the 802.11p drivers people will use at this >> event? Is now 802.11p integrated in the mainline kernel? >> >> Yours, >> >> Alex >> >> >> >> Le 27/10/2014 18:24, Lei Chen a écrit : >>> Dear Alex, >>> >>> Thanks very much for the detailed explanation and also the >>> opportunity to share with our community about GCDC 2016. >>> >>> Please see the following for details. >>> >>> Best regards, Lei >>> >>>> On 27 Oct 2014, at 16:08, Alexandru Petrescu >>>> >>> > wrote: >>>> >>>> Dear Lei Chen, >>>> >>>> Thank you for the reply. >>>> >>>> Le 27/10/2014 14:03, Lei Chen a écrit : >>>>> Dear all, >>>>> >>>>> Just a bit self introduction, we are working on the second >>>>> edition of cooperative driving challenge (www.gcdc.net >>>>> >>>>> ) and somehow we came across the same topics >>>>> here. >>>> >>>> GCDC is the same organization that issued the first freely >>>> available 802.11p driver? >>> >>> Last time, GCDC implemented 802.11p thanks to the work with Eric >>> Koenders. It is open-source, I hope that is the same one you are >>> talking about. >>>> >>>>> Thanks to Alex to bring this topic up, it is very relevant for >>>>> the platoon applications. >>>>> >>>>> Basically, like Andras and John said, V2V through DSRC will be >>>>> the first implementation for initial application of platooning. >>>>> IP will most probably be used for Day2 applications that require >>>>> more data communications, for example, video streaming between >>>>> platoon vehicles or LDM. >>>> >>>> [LDM? (light-based communications, LiFi?)] >>> >>> Sorry for that, LDM = local dynamic map. Using DSRC and based on CAM >>> messages, LDM is able to be constructed, but if we consider more >>> accurate and complex LDM for environmental perception, I would say IP >>> will be needed. >>> >>>> >>>> I am happy to see IP communications are considered, even that is in >>>> the second day. I personally do not worry very much of being maybe >>>> later, because I think IP will support more applications, currently >>>> unspoken of. >>>> >>>>> It seems ETSI does this with an adaption layer (EN302 636-6-1, >>>>> TS102 636-6-1) for IPv6 to work with GeoNet. >>>> >>>> Yes, there is an adaptation layer for IPv6 and geonet. It may be >>>> highly necessary in the initial steps of bringing IPv6 as close as >>>> possible to the deployment. >>>> >>>> IPv6-straight-over-80211p also uses an Adaptation Layer (the >>>> Ethernet Adaptation Layer used by 802.11b). >>>> >>>>> Anyway, GeoNet seems to be in the protocol stack for C-ITS no >>>>> matter what. >>>> >>>> Thanks for the remark. It is true that GeoNet of ETSI ITS is >>>> present there but one should distinguish the cases where it is >>>> absolutely necessary - something else can not do its role. These >>>> cases are the communications depending extensively on location: >>>> geo-dissemination, etc. >>>> >>> >>> Absolutely agree! In general, for infotainment application or less >>> time critical applications, IP network (LTE for example) will be the >>> best choice. However, for time critical applications or as you said, >>> geo-dependent applications, GeoNet over 802.11p may be necessary, at >>> least for the near future applications. If we consider further with >>> 5G, where the latency is expected to be significantly reduced, I >>> guess everything can be done through IP. But it is hard to draw >>> conclusions about it at the current stage. Anyway,I guess the >>> cross-layer Decentralized Congestion Control (DCC) in C-ITS should be >>> able to take care of this based on the QoS requirement at the >>> application layer and direct the traffic to appropriate transport and >>> access methods, at least it is supposed to do this. >>> >>>>> If IPv6 is considered, then the transport layer will be TCP/UDP >>>>> over IPv6 over GeoNet, though I am not sure about the protocol >>>>> overhead. It is an interesting issue to investigate. >>>> >>>> Yes, it is an issue to investigate. >>>> >>>> At IETF there is a document called IPv6-over-80211p that I author. >>>> The ideas expressed in this document could be used in this >>>> investigation. The document itself lacks certain aspects that >>>> anyone interested could contribute. >>> >>> Thanks, I am checking with the document, I would say IPv6 over >>> 802.11p is absolutely an option and we are investigating the >>> possibilities. I hope we can also contribute to this topic. >>> >>>> >>>>> For platooning in Day1 applications, GeoNet (BTP and GeoNet for >>>>> transport) over G5 maybe the most appropriate choice at the >>>>> current stage because of the advantages of time delay. >>>> >>>> Not sure what you mean by 'time delay'? >>>> >>>> If you mean latency between vehicles, then I think 802.11p gives >>>> better latency, in the order of tens of millseconds. >>>> >>>> Or you mean that products implementing ETSI ITS GeoNet have a time >>>> advantage being already there? If so then I agree with you. >>> >>> Yes, it is latency. 802.11p based access generally have better >>> latency, and a light weight BTP&GeoNet also contributes to the >>> latency issue. I guess IP over 802.11p may achieve similar latency >>> performance, though I need to check a bit more over that. As for IPv6 >>> over GeoNet over 802.11p, as we already mentioned, the overhead is >>> worth investigating further. It is also one topic we will look at. >>> >>>> >>>>> We are looking at different implementations of GeoNet for >>>>> potential deployment in GCDC. As we work towards Day2 >>>>> applications, IPv6 is potentially considered. INRIA has been >>>>> working on the implementation through CarGeo6. If you guys have >>>>> more information about the implementation now, it is very >>>>> appreciated that you share with us. >>>> >>>> Sure, certainly. I downloaded CarGeo6 and looked at the code. I >>>> have the feeling that with it a car sends its position to another >>>> car. >>>> >>>> At my place we have another implementation of exchanging IPv6 >>>> routing information over 802.11p. We also have an update version >>>> of the original 802.11p GCDC driver for most recent linux kernels >>>> as well as other reliability improvements. >>>> >>> We are investigating CarGeo6 now. But it is very interesting you have >>> an update version of the 802.11p protocol. I am not sure if you >>> already make it open source or not. If so, it will be absolutely a >>> great help for us to check the possibilities of applying IPv6 over >>> 802.11p. Could you indicate me how and where I can check and then I >>> can talk with my colleagues both at Viktoria and TNO for further >>> discussions? If we prove the performance with IP over 802.11p during >>> the challenge, I would say that will be a great contribution to >>> C-ITS, at least for some part. Thanks very much beforehand:-) >>> >>>>> Also, if you know teams that want to show their implementations >>>>> of cooperative driving to the world, GCDC 2016 is the place to >>>>> go. They are free to contact us for registration or check >>>>> www.gcdc.net for >>>>> details. >>>> >>>> YEs, this is a good announcement. Please state here what are the >>>> participating conditions - is it free to join, what are the fees >>>> involved, in which country is it happening. >>> >>> Thanks Alex, it is my pleasure to share with our community the >>> announcement. >>> >>> GCDC2016, or i-GAME (www.gcdc.net ) is the >>> second edition of GCDC >>> based on its success in 2011 and with the purpose to accelerate >>> cooperative driving through public challenge. GCDC2016 will mainly >>> focus on the interoperability of communications, e.g. communications >>> are vendor independent and teams are very welcome to implement based >>> on different equipments from different vendors . However, the >>> communications protocol will align to the latest C-ITS standards >>> (Release 1) and potentially will contribute to Release 2. >>> >>> It is totally free to join the challenge and in addition to that, >>> teams will get support from organizers (TNO and TU/e from holland, >>> Viktoria Swedish ICT from Sweden and IDIADA from Spain). The final >>> challenge will be Q2 2016 at the test site in Helmond in Holland, >>> exactly the same test site as GCDC 2011. GCDC2016 have two challenge >>> scenarios and one demo scenario. Challenge scenarios include both >>> urban (intersection passing) and highway (platoon merge due to >>> roadwork). Demo scenario is about emergency vehicle passing. All >>> scenarios are defined to be close to reality and the implementations >>> are also expected to be as close-to market as possible. We want to >>> show the benefits of cooperative driving and also raise the awareness >>> from both government and public. >>> >>> The call on registrations is on-going. Notice that the registration >>> is not binding at this stage. Teams can show interest and ask for >>> further information and if possible, the organizers may help to >>> assist to find partners. Teams are also very welcome to contribute to >>> the implementation of communication protocols together with us. Just >>> drop us emails :-) >>> >>> For those who are interested, some general requirements are as >>> follows, •A vehicle that will be fitted with the requirements >>> •Minimum longitudinal automation •Interoperable V2X communication and >>> interaction – will be tested both remotely online and physically at >>> the challenge site •Drivers are in the vehicles, safety is critical >>> •Drivers and support crew •Budget for travel, transport and >>> subsistence •Taking part in preparative workshops and the rigorous >>> functional testing before the challenge •Be ready by Spring 2016! >>> >>> In return, the teams will get •Once in a lifetime opportunity to work >>> with universities, OEMs and authorities to forward the state of >>> cooperative autonomous driving •Get in contact with world class >>> companies and people in this field •Collaborate at the forefront of >>> standardization efforts •Help your institution learn and build its >>> reputation •Win the challenge and eternal fame! >>> >>> Just a video introduction of last time’s challenge >>> (https://www.youtube.com/watch?v=lmRifLzw8iA) for those who are >>> interested. Teams now can register at www.gcdc.net >>> or contact the >>> following people. >>> >>> For registration and team information: >>> l.r.r.schrijnemakers@tue.nl >>> (Laurens Schrijnemakers) >>> >>> For project information and collaboration: sander.maas@tno.nl >>> (Sander >>> Maas) >>> >>> We sincerely look forward for teams from all over the world to >>> participate :) >>> >>>> >>>> Alex >>>> >>>>> >>>>> Best regards, Lei >>>>> >>>>> >>>>> *Lei Chen, PhD* Senior Researcher Cooperative Systems >>>>> >>>>> >>>>> >>>>> *Viktoria Swedish ICT AB* Lindholmspiren 3A SE-417 56 Göteborg, >>>>> Sweden Tel: +46 76 777 1449 >>>>> E-mail: lei.chen@viktoria.se >>>>> www.viktoria.se >>>>> >>>>> >>>>> Part of RISE >>>>> >>>>>> On 27 Oct 2014, at 12:22, Varadi , Andras (lesswire AG Ungarn) >>>>>> >>>>>> > wrote: >>>>>> >>>>>> Dear Alex, John I agree with John, but would like to point out >>>>>> that I think its likely that we will need to extend EU >>>>>> Geonetworking (EN 302 636) to work over IP (e.g. LTE) links >>>>>> also. I think we will have such requirements for EU Day2 or 3 >>>>>> (2^nd , Third generation C-ITS) (example: update our Local >>>>>> Dynamic Map with a new Warning message received over cellular >>>>>> connection (not G5/11p)) Üdvözlettel / Best regards, András >>>>>> Váradi Project Manager – C2X/ITS Systems >>>>>> >>>>>> Automotive & WLAN Group lesswire Hungary***|***Office: +36 >>>>>> 23521 667***|***Email:Varadi@lesswire.com >>>>>> *From:*its >>>>>> [mailto:its-bounces@ietf.org]*On Behalf Of*John Kenney >>>>>> *Sent:*Saturday, October 25, 2014 1:45 AM *To:*Alexandru >>>>>> Petrescu *Cc:*its@ietf.org >>>>>> *Subject:*Re: >>>>>> [geonet/its] FYI - ETSI ITS - work on cooperative cruise >>>>>> control, platooning Hi Alex, Thanks for sharing this. I think >>>>>> many of us in the DSRC/Cooperative ITS community consider these >>>>>> two applications to be a very natural fit for the technology. >>>>>> Furthermore, my expectation is that the applications can work >>>>>> well with one-hop V2V communication of the type that does not >>>>>> typically use IP. So, I don't see a benefit of including IP. >>>>>> That doesn't mean it wouldn't work, but as you know the DSRC >>>>>> community generally plans to use a lighter weight protocol, >>>>>> WSMP, for applications that do not need IP. I expect ETSI will >>>>>> think along similar lines. Best Regards, John -- John Kenney >>>>>> Principal Researcher Toyota InfoTechnology Center, USA 465 >>>>>> Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. >>>>>> Mobile: 650-224-6644 On Fri, Oct 24, 2014 at 8:16 AM, Alexandru >>>>>> Petrescu >>>>> >>>>>> > wrote: Hello >>>>>> geonet/itsers, >>>>>> >>>>>> ETSI ITS group is an SDO in Europe. They produced many >>>>>> standards in the past for vehicular communications, e.g. ETSI >>>>>> ITS geo-networking among others. >>>>>> >>>>>> ETSI ITS recently agreed to start working on >>>>>> pre-standardization items called "Cooperative Cruise Control" >>>>>> and "Platooning". These two applications make automobiles (and >>>>>> trucks) talk to each other continuously to keep speed constant. >>>>>> It helps relieve automobile driver stress in jam situation or >>>>>> reduce gas consumption by 'platooning'. >>>>>> >>>>>> Currently the focus is on requirements including communication >>>>>> requirements. >>>>>> >>>>>> In my oppinion, and this is why I forward it to this group, >>>>>> establishing direct IP connections between vehicles may open >>>>>> paths for exchanging IP data containing speed/location and >>>>>> trigger a control process of adapting the speed. One already >>>>>> controls vehicles by sending IP data to them, from the >>>>>> infrastructure. It would be a simple matter for IP experts to >>>>>> send that same data from other vehicle, without going to the >>>>>> infrastructure. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Yours, >>>>>> >>>>>> Alex >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>> > >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>> >>>> >>>> _______________________________________________ its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>> >>> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Wed May 11 06:47:53 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED85C12D69C for ; Wed, 11 May 2016 06:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjRfaNEBZ9qR for ; Wed, 11 May 2016 06:47:50 -0700 (PDT) Received: from ndjsvnpf104.ndc.nasa.gov (NDJSVNPF104.ndc.nasa.gov [198.117.1.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8C77612D16B for ; Wed, 11 May 2016 06:47:50 -0700 (PDT) Received: from ndjsppt105.ndc.nasa.gov (ndjsppt105.ndc.nasa.gov [198.117.1.199]) by ndjsvnpf104.ndc.nasa.gov (Postfix) with ESMTP id 21D35400652F for ; Wed, 11 May 2016 08:47:50 -0500 (CDT) Received: from NDJSCHT113.ndc.nasa.gov (ndjscht113-pub.ndc.nasa.gov [198.117.1.213]) by ndjsppt105.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id u4BDlnP7015135 for ; Wed, 11 May 2016 08:47:49 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.156]) by NDJSCHT113.ndc.nasa.gov ([198.117.1.213]) with mapi id 14.03.0266.001; Wed, 11 May 2016 08:47:49 -0500 From: "Ivancic, William D. (GRC-LCA0)" To: "its@ietf.org" Thread-Topic: Aeronautics use case Thread-Index: AQHRq4u1IUqWnFX52USAy0EJdEvRDw== Date: Wed, 11 May 2016 13:47:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [139.88.111.195] Content-Type: multipart/alternative; boundary="_000_D358AFB646E63williamdivancicnasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-11_05:, , signatures=0 Archived-At: Subject: [its] Aeronautics use case X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 13:47:52 -0000 --_000_D358AFB646E63williamdivancicnasagov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 5. Global Group Will Standardize UAV Traffic Management A group of regulators, air navigation service providers (ANSP), manufacture= rs and operators is being formed to draft a global interoperability bluepri= nt for UAV traffic management (UTM)... "Global UTM will be set up as a not-for-profit organization based in Switze= rland, with international online working groups that will meet regularly ar= ound the world to adopt standards and agree on new topics to be tackled," s= ays Simon Johnson, organizer of the European UTM Day in Geneva. "Initial solutions to integrate drones into low-altitude airspace will be i= mplemented nationally. But as drone technology and missions are likely to d= evelop rapidly, a global initiative is needed to provide inputs on a harmon= ized, scalable and future-proof system that can be quickly defined and impl= emented by regulators worldwide," says Francis Schubert with Swiss ANSP Sky= guide. In addition to low-altitude airspace management, UTM encompasses a universa= l drone registration database, open identification systems, tamper-proof fl= ight data recorders, trusted 3D mapping data, dynamic weather information a= nd vehicle-to-vehicle communication, the organizing team says=85 - Graham Warwick, warwick@aviationweek.com --_000_D358AFB646E63williamdivancicnasagov_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7082EE0FE1881344BA8BA3711CC55AE6@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable

5. Global Group Will Standardize UAV Traffic Management

A group of regulators, air navigation service providers (ANSP), manufa= cturers and operators is being formed to draft a global interoperability bl= ueprint for UAV traffic management (UTM)...

"Global UTM will be set up as a not-for-profit organization based= in Switzerland, with international online working groups that will meet re= gularly around the world to adopt standards and agree on new topics to be t= ackled," says Simon Johnson, organizer of the European UTM Day in Geneva.

"Initial solutions to integrate drones into low-altitude airspace= will be implemented nationally. But as drone technology and missions are l= ikely to develop rapidly, a global initiative is needed to provide inputs o= n a harmonized, scalable and future-proof system that can be quickly defined and implemented by regulators worldwide= ," says Francis Schubert with Swiss ANSP Skyguide.

In addition to low-altitude airspace management, UTM encompasses a uni= versal drone registration database, open identification systems, tamper-pro= of flight data recorders, trusted 3D mapping data, dynamic weather informat= ion and vehicle-to-vehicle comm= unication, the organizing team says=85


- Graham Warwick, warwick@aviationweek.com


--_000_D358AFB646E63williamdivancicnasagov_-- From nobody Wed May 11 06:55:02 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591FF12B006 for ; Wed, 11 May 2016 06:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nM-lo0hGrDjp for ; Wed, 11 May 2016 06:54:57 -0700 (PDT) Received: from ukel19pa16.eemsg.mail.mil (ukel19pa16.eemsg.mail.mil [214.24.22.84]) by ietfa.amsl.com (Postfix) with ESMTP id D66BB12D526 for ; Wed, 11 May 2016 06:54:54 -0700 (PDT) Received: from edge-cols03.mail.mil ([131.64.107.102]) by ukel19pa16.eemsg.mail.mil with ESMTP; 11 May 2016 13:54:52 +0000 Received: from UCOLHPPY.easf.csd.disa.mil (131.64.107.34) by edge-cols03.mail.mil (131.64.107.102) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 11 May 2016 13:54:52 +0000 Received: from UCOLHU2J.easf.csd.disa.mil ([169.254.6.122]) by UCOLHPPY.easf.csd.disa.mil ([131.64.107.34]) with mapi id 14.03.0266.001; Wed, 11 May 2016 13:54:51 +0000 From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" To: "Ivancic, William D. (GRC-LCA0)" Thread-Topic: [Non-DoD Source] [its] Aeronautics use case Thread-Index: AQHRq4u1IUqWnFX52USAy0EJdEvRD5+zwb+w Date: Wed, 11 May 2016 13:54:50 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDFA28390EC@UCOLHU2J.easf.csd.disa.mil> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] [Non-DoD Source] Aeronautics use case X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 13:55:01 -0000 Hi, Will: Is it possible to throw a little more explanation on vehicle-to-vehicle com= munication part of it? BR/Radhika=20 -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Ivancic, William D. (G= RC-LCA0) Sent: Wednesday, May 11, 2016 9:48 AM To: its@ietf.org Subject: [Non-DoD Source] [its] Aeronautics use case 5. Global Group Will Standardize UAV Traffic Management A group of regulators, air navigation service providers (ANSP), manufacture= rs and operators is being formed to draft a global interoperability bluepri= nt for UAV traffic management (UTM)... "Global UTM will be set up as a not-for-profit organization based in Switze= rland, with international online working groups that will meet regularly ar= ound the world to adopt standards and agree on new topics to be tackled," s= ays Simon Johnson, organizer of the European UTM Day in Geneva. "Initial solutions to integrate drones into low-altitude airspace will be i= mplemented nationally. But as drone technology and missions are likely to d= evelop rapidly, a global initiative is needed to provide inputs on a harmon= ized, scalable and future-proof system that can be quickly defined and impl= emented by regulators worldwide," says Francis Schubert with Swiss ANSP Sky= guide. In addition to low-altitude airspace management, UTM encompasses a universa= l drone registration database, open identification systems, tamper-proof fl= ight data recorders, trusted 3D mapping data, dynamic weather information a= nd vehicle-to-vehicle communication, the organizing team says... - Graham Warwick, warwick@aviationweek.com From nobody Wed May 11 07:01:11 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD0212D6BB for ; Wed, 11 May 2016 07:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRTmWvwXzc3l for ; Wed, 11 May 2016 07:01:05 -0700 (PDT) Received: from ndjsvnpf102.ndc.nasa.gov (NDJSVNPF102.ndc.nasa.gov [198.117.1.152]) by ietfa.amsl.com (Postfix) with ESMTP id 9E55D12D6BD for ; Wed, 11 May 2016 07:01:05 -0700 (PDT) Received: from ndjsppt102.ndc.nasa.gov (ndjsppt102.ndc.nasa.gov [198.117.1.196]) by ndjsvnpf102.ndc.nasa.gov (Postfix) with ESMTP id E3CAF4002F65; Wed, 11 May 2016 09:01:04 -0500 (CDT) Received: from NDJSCHT116.ndc.nasa.gov (ndjscht116-pub.ndc.nasa.gov [198.117.1.216]) by ndjsppt102.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id u4BE14ro030809; Wed, 11 May 2016 09:01:04 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.156]) by NDJSCHT116.ndc.nasa.gov ([198.117.1.216]) with mapi id 14.03.0266.001; Wed, 11 May 2016 09:01:04 -0500 From: "Ivancic, William D. (GRC-LCA0)" To: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" Thread-Topic: [Non-DoD Source] [its] Aeronautics use case Thread-Index: AQHRq4u1IUqWnFX52USAy0EJdEvRD5+zwb+wgAATfgA= Date: Wed, 11 May 2016 14:01:04 +0000 Message-ID: References: <8486C8728176924BAF5BDB2F7D7EEDDFA28390EC@UCOLHU2J.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDFA28390EC@UCOLHU2J.easf.csd.disa.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [139.88.111.195] Content-Type: text/plain; charset="us-ascii" Content-ID: <4A0FB2E70887024B832D82C2E049250D@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-11_05:, , signatures=0 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] [Non-DoD Source] Aeronautics use case X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 14:01:10 -0000 This was just a press release. So, sorry, but not really at this time. I think the entire system is a blank sheet of paper - just starting and listing areas of concern. Thus, what is done in ITS could help guide this group. Just my opinion. Will On 5/11/16, 9:54 AM, "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" wrote: >Hi, Will: > >Is it possible to throw a little more explanation on vehicle-to-vehicle >communication part of it? > >BR/Radhika=20 > >-----Original Message----- >From: its [mailto:its-bounces@ietf.org] On Behalf Of Ivancic, William D. >(GRC-LCA0) >Sent: Wednesday, May 11, 2016 9:48 AM >To: its@ietf.org >Subject: [Non-DoD Source] [its] Aeronautics use case > > >5. Global Group Will Standardize UAV Traffic Management > >A group of regulators, air navigation service providers (ANSP), >manufacturers and operators is being formed to draft a global >interoperability blueprint for UAV traffic management (UTM)... > >"Global UTM will be set up as a not-for-profit organization based in >Switzerland, with international online working groups that will meet >regularly around the world to adopt standards and agree on new topics to >be tackled," says Simon Johnson, organizer of the European UTM Day in >Geneva. > >"Initial solutions to integrate drones into low-altitude airspace will be >implemented nationally. But as drone technology and missions are likely >to develop rapidly, a global initiative is needed to provide inputs on a >harmonized, scalable and future-proof system that can be quickly defined >and implemented by regulators worldwide," says Francis Schubert with >Swiss ANSP Skyguide. > >In addition to low-altitude airspace management, UTM encompasses a >universal drone registration database, open identification systems, >tamper-proof flight data recorders, trusted 3D mapping data, dynamic >weather information and vehicle-to-vehicle communication, the organizing >team says... > > >- Graham Warwick, warwick@aviationweek.com > > From nobody Wed May 11 07:13:32 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6B212DAF5 for ; Wed, 11 May 2016 07:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1bg6hnoTU8c for ; Wed, 11 May 2016 07:13:28 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id CC96412DAF4 for ; Wed, 11 May 2016 07:13:28 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 32681F2401F for ; Wed, 11 May 2016 10:13:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id M9FPEm0VAJ-c for ; Wed, 11 May 2016 09:56:40 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id CCFEDF24013 for ; Wed, 11 May 2016 10:13:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <259A19B3-8AC8-47EE-A203-4A8D93477826@vigilsec.com> Date: Wed, 11 May 2016 10:13:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <15F5B07A-B2FE-486E-B715-035C0DEC6F3E@vigilsec.com> References: <3E7E5AFB-5874-430E-BCBB-95F852773A6C@vigilsec.com> <737CC74B-DB26-4C31-AE21-4B2E51A87BAD@cisco.com> <9768E8EF-6FA6-4B12-827D-3C1CF5A37FCD@vigilsec.com> <259A19B3-8AC8-47EE-A203-4A8D93477826@vigilsec.com> To: its@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [its] Scheduling an ITS Virtual Interim X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 14:13:32 -0000 I would like to pick a date and time very soon. If you have not = responded to the doodle yet, please do so now. Russ On May 9, 2016, at 4:11 PM, Russ Housley wrote: > If we are going to hold a virtual interim before the end of the month, = then we need to pick the date and time in the next few days. >=20 > Please take the doodle pool so that the chairs can hove more that = their own calendar information to make a choice. >=20 > http://doodle.com/poll/zmwc79nuhhadsxiz >=20 > Russ >=20 From nobody Wed May 11 14:19:52 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B80F12B03C for ; Wed, 11 May 2016 14:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP0zxXmTL2K2 for ; Wed, 11 May 2016 14:19:45 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 795F012D147 for ; Wed, 11 May 2016 14:10:46 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 2CD67F2404B for ; Wed, 11 May 2016 17:10:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id UdQrz3UOGg3O for ; Wed, 11 May 2016 16:53:46 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id BB484F24013 for ; Wed, 11 May 2016 17:10:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <15F5B07A-B2FE-486E-B715-035C0DEC6F3E@vigilsec.com> Date: Wed, 11 May 2016 17:10:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8B0691EA-1C8E-4322-8204-FF6ECC95FA7B@vigilsec.com> References: <3E7E5AFB-5874-430E-BCBB-95F852773A6C@vigilsec.com> <737CC74B-DB26-4C31-AE21-4B2E51A87BAD@cisco.com> <9768E8EF-6FA6-4B12-827D-3C1CF5A37FCD@vigilsec.com> <259A19B3-8AC8-47EE-A203-4A8D93477826@vigilsec.com> <15F5B07A-B2FE-486E-B715-035C0DEC6F3E@vigilsec.com> To: its@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [its] Scheduling an ITS Virtual Interim X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 21:19:47 -0000 Thanks to all who responded to the doodle poll, Most popular date is = Tuesday, 31 May 2016 at 10:00 AM Eastern. Carlos and I will ask the AD to approve a virtual interim meeting for = this date and time. Russ On May 11, 2016, at 10:13 AM, Russ Housley wrote: > I would like to pick a date and time very soon. If you have not = responded to the doodle yet, please do so now. >=20 > Russ >=20 >=20 > On May 9, 2016, at 4:11 PM, Russ Housley wrote: >=20 >> If we are going to hold a virtual interim before the end of the = month, then we need to pick the date and time in the next few days. >>=20 >> Please take the doodle pool so that the chairs can hove more that = their own calendar information to make a choice. >>=20 >> http://doodle.com/poll/zmwc79nuhhadsxiz >>=20 >> Russ >>=20 >=20 From nobody Wed May 11 15:23:15 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B6412D5EB for ; Wed, 11 May 2016 15:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_4qokKZ9r9v for ; Wed, 11 May 2016 15:23:12 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0AE12D521 for ; Wed, 11 May 2016 15:23:12 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id EA84DF2401F for ; Wed, 11 May 2016 18:23:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id kxTibUWAOjNM for ; Wed, 11 May 2016 18:06:11 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 74FEBF24013 for ; Wed, 11 May 2016 18:23:00 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <8B0691EA-1C8E-4322-8204-FF6ECC95FA7B@vigilsec.com> Date: Wed, 11 May 2016 18:23:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E4D6270-4115-4677-B035-53CDC13DFEB8@vigilsec.com> References: <3E7E5AFB-5874-430E-BCBB-95F852773A6C@vigilsec.com> <737CC74B-DB26-4C31-AE21-4B2E51A87BAD@cisco.com> <9768E8EF-6FA6-4B12-827D-3C1CF5A37FCD@vigilsec.com> <259A19B3-8AC8-47EE-A203-4A8D93477826@vigilsec.com> <15F5B07A-B2FE-486E-B715-035C0DEC6F3E@vigilsec.com> <8B0691EA-1C8E-4322-8204-FF6ECC95FA7B@vigilsec.com> To: its@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [its] Scheduling an ITS Virtual Interim X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 22:23:15 -0000 This is the request that was forwarded to our AD =85 Intelligent Transportation Systems (its) BOF will hold a virtual interim=20= meeting on May 31, 2016 at 1000 EDT (1400 UTC) for 1 hour. Agenda: Introduction =97 Chairs =97 5 minutes Finalizing charter text and deliverables =97 Alex =97 45 minutes Finding authors for each deliverable =97 Chairs =97 10 minutes Russ On May 11, 2016, at 5:10 PM, Russ Housley wrote: > Thanks to all who responded to the doodle poll, Most popular date is = Tuesday, 31 May 2016 at 10:00 AM Eastern. >=20 > Carlos and I will ask the AD to approve a virtual interim meeting for = this date and time. >=20 > Russ >=20 >=20 > On May 11, 2016, at 10:13 AM, Russ Housley = wrote: >=20 >> I would like to pick a date and time very soon. If you have not = responded to the doodle yet, please do so now. >>=20 >> Russ >>=20 >>=20 >> On May 9, 2016, at 4:11 PM, Russ Housley = wrote: >>=20 >>> If we are going to hold a virtual interim before the end of the = month, then we need to pick the date and time in the next few days. >>>=20 >>> Please take the doodle pool so that the chairs can hove more that = their own calendar information to make a choice. >>>=20 >>> http://doodle.com/poll/zmwc79nuhhadsxiz >>>=20 >>> Russ >>>=20 >>=20 >=20 From nobody Thu May 12 11:18:15 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A88912D544 for ; Thu, 12 May 2016 11:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDnc65mlg_hE for ; Thu, 12 May 2016 11:18:11 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860DB12D0F4 for ; Thu, 12 May 2016 11:18:11 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id xk12so32103107pac.0 for ; Thu, 12 May 2016 11:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=H0Zc7s6ngQF5TYPKAhYlwLi+wsweiUTKmic1teNMKw4=; b=utAqp7Gu5rPj4aWuCck7x1d+QKNxt1Cn8xVZ5YnieLw9EtRWukv1ggVhfTdvY1rGWR fdAWFkQ6iDfGJLylpWXDq3R9ZdoShCcuZhwftmrWBfMzjuQHI/49vV2uNeCI7sAXzpKc ev+g0nVTLlU+qvypwPu0zzUpKTATp6xpuxBDKxgp6aAjx3lLWjc7pzCxJCyrBuu3wCkt pVrSJZZLpDqmb59C91r3sDtTPqKnCPl4JkfaLgb5L2aIKpZFNE7Ic/bv0XWR+SooAgN/ LS6018AvYlJGFcqBMHzTZG1Vig/WoxSsFTn14mc6youqf2ivwuIYHpkmPrulFgM1qwos mVhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=H0Zc7s6ngQF5TYPKAhYlwLi+wsweiUTKmic1teNMKw4=; b=Z82Ozq2Aoe4IPsso9gW6qGo9Gcv2i0FrCAWo4qk80vksP4UljDwsykwjhI33Drmloy Qqt+SQbRNi5RLlaRYgTUdP7hiMjhSHaut7duPNOAFmbbjPZgQiqPFBkQJ1HQmwHBz00g Ii7/cMAuxsr/ooXISrjBUq3pYH9P3eclrmwV66GnfLwH7YjftwazhTgllidF4ZhzPbf5 2aDJ8hOye/AWR5NlX0UwT5PTGD7aJ3I5z2+CxSNQwYntzkIg63Y6H6Ttha5cpYT2KSUD +hciCAWvA8RnNSK1LUUuqQs6GsX0QEf8/xGjCp8IP4TIOiA7/eJiiVX06SjoSZQN9bAE gEiA== X-Gm-Message-State: AOPr4FUurR7MP9yGQtSnlXU7Gux2Z7MNkb8ChaPa2gDIfWrjUK0gjOGgoz/ZAsUpCg/87Q== X-Received: by 10.67.13.144 with SMTP id ey16mr16005159pad.147.1463077091185; Thu, 12 May 2016 11:18:11 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id 19sm21431301pfu.83.2016.05.12.11.18.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2016 11:18:10 -0700 (PDT) From: Dino Farinacci Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 12 May 2016 11:18:07 -0700 Message-Id: To: its@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Padma Pillay-Esnault Subject: [its] Potential LISP solutions for ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 18:18:13 -0000 We just posted some new IDs in the LISP working group. You guys may be = interested. The =E2=80=9Cpredictive-RLOCs=E2=80=9D draft is probably the = most applicable to ITS. Thanks in advance for your review. Dino https://www.ietf.org/id/draft-farinacci-lisp-geo-00.txt https://www.ietf.org/id/draft-farinacci-lisp-eid-anonymity-00.txt https://www.ietf.org/id/draft-farinacci-lisp-name-encoding-00.txt https://www.ietf.org/id/draft-farinacci-lisp-predictive-rlocs-00.txt= From nobody Thu May 12 15:45:33 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE5912D117 for ; Thu, 12 May 2016 15:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNkoJMkidonx for ; Thu, 12 May 2016 15:45:30 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4842E12D0C9 for ; Thu, 12 May 2016 15:45:30 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 554DCF2402A for ; Thu, 12 May 2016 18:45:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id RP01wTMud+zs for ; Thu, 12 May 2016 18:28:36 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id C45EBF24013 for ; Thu, 12 May 2016 18:45:29 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_62546E7C-F0B2-4B86-BAC2-BC54E4DA0F91" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley X-Priority: 3 X-Mail-Calendar-Part: Yes Date: Thu, 12 May 2016 18:45:32 -0400 Message-Id: <15DB2EAB-9946-4BF2-ADDF-57E372BCFFF1@vigilsec.com> To: its@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [its] WebEx meeting invitation: ITS Virtual BOF Session X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: its-chairs@ietf.org List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 22:45:32 -0000 --Apple-Mail=_62546E7C-F0B2-4B86-BAC2-BC54E4DA0F91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii ITS Virtual BOF Session Tuesday, May 31, 2016 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr =20 Join WebEx meeting Meeting number: 644 158 525 Meeting password: may31st =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 644 158 525 Toll-free calling restrictions =20 Add this meeting to your calendar. (Cannot add from mobile devices.) =20 Need help? Go to http://help.webex.com. =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. --Apple-Mail=_62546E7C-F0B2-4B86-BAC2-BC54E4DA0F91 Content-Type: multipart/mixed; boundary="Apple-Mail=_0904F4FC-B2EB-4373-B4FA-69A71087EFAD" --Apple-Mail=_0904F4FC-B2EB-4373-B4FA-69A71087EFAD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
ITS Virtual BOF Session
Tuesday, May 31, 2016
10:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr
 
Join WebEx meeting
Meeting number: 644 158 525
Meeting password: may31st
 
Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 644 158 525
Toll-free calling restrictions
 
Add this meeting to your calendar. (Cannot add from mobile devices.)
 
Need help? Go to http://help.webex.com.
 
IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.
--Apple-Mail=_0904F4FC-B2EB-4373-B4FA-69A71087EFAD Content-Disposition: attachment; filename=WebEx_Meeting.ics Content-Type: text/calendar; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0APRODID:-//Microsoft=20Corporation//Outlook=2010.0=20= MIMEDIR//EN=0AVERSION:2.0=0AMETHOD:REQUEST=0ABEGIN:VTIMEZONE=0A= TZID:Eastern=20Time=0ABEGIN:STANDARD=0ADTSTART:20141101T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11=0A= TZOFFSETFROM:-0400=0ATZOFFSETTO:-0500=0ATZNAME:Standard=20Time=0A= END:STANDARD=0ABEGIN:DAYLIGHT=0ADTSTART:20140301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3=0A= TZOFFSETFROM:-0500=0ATZOFFSETTO:-0400=0ATZNAME:Daylight=20Savings=20Time=0A= END:DAYLIGHT=0AEND:VTIMEZONE=0ABEGIN:VEVENT=0AATTENDEE;CN=3D"ITS=20= BOF";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:its-chairs@ietf.org=0A= ORGANIZER;CN=3D"ITS=20BOF":MAILTO:its-chairs@ietf.org=0A= DTSTART;TZID=3D"Eastern=20Time":20160531T100000=0ADTEND;TZID=3D"Eastern=20= Time":20160531T110000=0ALOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0ASEQUENCE:1463092919=0A= UID:e8a20e30-7311-40c7-aa51-dc5d72a8099d=0ADTSTAMP:20160531T140000Z=0A= DESCRIPTION:\n\n\nJOIN=20WEBEX=20= MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm2c3eee5f322accfac068475= 10a85ccd9\nMeeting=20number:=20644=20158=20525\nMeeting=20password:=20= may31st\n\n\nJOIN=20BY=20PHONE\n1-877-668-4493=20Call-in=20toll=20free=20= number=20(US/Canada)=20\n1-650-479-3208=20Call-in=20toll=20number=20= (US/Canada)\nAccess=20code:=20644=20158=20525\n\nToll-free=20dialing=20= restrictions:=20= \nhttps://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't=20= join=20the=20meeting?=20Contact=20support=20= here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT=20NOTICE:=20Please=20= note=20that=20this=20WebEx=20service=20allows=20audio=20and=20other=20= information=20sent=20during=20the=20session=20to=20be=20recorded,=20= which=20may=20be=20discoverable=20in=20a=20legal=20matter.=20By=20= joining=20this=20session,=20you=20automatically=20consent=20to=20such=20= recordings.=20If=20you=20do=20not=20consent=20to=20being=20recorded,=20= discuss=20your=20concerns=20with=20the=20host=20or=20do=20not=20join=20= the=20session.\n=0AX-ALT-DESC;FMTTYPE=3Dtext/html:=09 
=20=09=09Join=20= WebEx=20meeting=09=09=09=09=09=09=09=09=09=09=09=09= =09=09=09=09=09= =09=09=09=09= =09=09=09
=09=09=09=09=09=09Meeting=20number:=09=09=09=09=09=09=09=09=09=09=09644=20158=20525=09=09=09=09=09
=09=09=09
Meeting=20= password:may31st
=09=09 
 
Join=20by=20phone =20
1-877-668-4493 Call-in=20toll=20= free=20number=20(US/Canada) =20
1-650-479-3208 Call-in=20toll=20= number=20(US/Canada) =20
Access=20code:=20644=20158=20= 525 =20
Toll-free=20calling=20= restrictions=20 =20


=09 
=09= =09=09=09=09= Can't=20join=20the=20meeting?=09=09Contact=20support.=09=  
 
IMPORTANT=20NOTICE:=20Please=20note=20that=20this=20WebEx=20= service=20allows=20audio=20and=20other=20information=20sent=20during=20= the=20session=20to=20be=20recorded,=20which=20may=20be=20discoverable=20= in=20a=20legal=20matter.=20By=20joining=20this=20session,=20you=20= automatically=20consent=20to=20such=20recordings.=20If=20you=20do=20not=20= consent=20to=20being=20recorded,=20discuss=20your=20concerns=20with=20= the=20host=20or=20do=20not=20join=20the=20session.=0A= SUMMARY:ITS=20Virtual=20BOF=20Session=0APRIORITY:5=0ACLASS:PUBLIC=0A= BEGIN:VALARM=0ATRIGGER:-PT5M=0AACTION:DISPLAY=0ADESCRIPTION:Reminder=0A= END:VALARM=0AEND:VEVENT=0AEND:VCALENDAR=0A= --Apple-Mail=_0904F4FC-B2EB-4373-B4FA-69A71087EFAD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii --Apple-Mail=_0904F4FC-B2EB-4373-B4FA-69A71087EFAD-- --Apple-Mail=_62546E7C-F0B2-4B86-BAC2-BC54E4DA0F91-- From nobody Thu May 12 15:58:50 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAEE12D0B4 for ; Thu, 12 May 2016 15:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hV3iIDLxGaWA for ; Thu, 12 May 2016 15:58:47 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EDF12B020 for ; Thu, 12 May 2016 15:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19080; q=dns/txt; s=iport; t=1463093926; x=1464303526; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NKX6m6uFNKuTc7Im3TVw+WXQCSLfKwGOTA9knkhGIi4=; b=mGtl3M1taGFhJxhRPhzo7BO7QMpHZRF6Ldeu3NDiyGkpecW4dXozlAeO c7c3MePIcJGt/h3XgTCqHWirzKn81wZW2hv3PdroQXRrtQUY1o9Vvgq+x VPR942feYCzJY4HHV5Ek/mURGpVcI75blxwEjKnixrOr+EmneGjGL5H4L M=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQBICjVX/4gNJK1EFwOCbExVfga5U?= =?us-ascii?q?Q6BDQVkFwEMhXACgTE4FAEBAQEBAQFlHAuEQgEBAQIBAQEBASBDCBAJAgIBCBg?= =?us-ascii?q?UBAwDAwICGwwLFBABAgEDEw6IGQgOLKw5hQ2LaAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQ4OBYYggXaCVoE5AYJ2MBUCDweCMiuCLgWTMIR3AYMogWhthWWCO4FpFze?= =?us-ascii?q?EAYhhj0ABDw8BQ4IFDQ6BAEtuAYcxfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,611,1454976000"; d="asc'?scan'208,217";a="102026736" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 May 2016 22:58:45 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u4CMwj3L015983 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 May 2016 22:58:45 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 12 May 2016 18:58:44 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Thu, 12 May 2016 18:58:44 -0400 From: "Carlos Pignataro (cpignata)" To: "its@ietf.org" Thread-Topic: [its] WebEx meeting invitation: ITS Virtual BOF Session Thread-Index: AQHRrKASjO4rcFzMwUq/5sr2KJ3tPJ+2LXgA Date: Thu, 12 May 2016 22:58:44 +0000 Message-ID: <2C1E110A-F8F3-4DFF-8DC8-3222BEFAD39A@cisco.com> References: <15DB2EAB-9946-4BF2-ADDF-57E372BCFFF1@vigilsec.com> In-Reply-To: <15DB2EAB-9946-4BF2-ADDF-57E372BCFFF1@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.255.230] Content-Type: multipart/signed; boundary="Apple-Mail=_D123BCA9-1430-4870-87D8-3AB09DF4ABC4"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [its] WebEx meeting invitation: ITS Virtual BOF Session X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 22:58:49 -0000 --Apple-Mail=_D123BCA9-1430-4870-87D8-3AB09DF4ABC4 Content-Type: multipart/alternative; boundary="Apple-Mail=_5B120075-276E-4247-9F7D-366CCAA57867" --Apple-Mail=_5B120075-276E-4247-9F7D-366CCAA57867 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, ITS, Some additional info besides the WebEx meeting information for our ITS = Virtual Interim BOF found below. Meeting materials will be found at: https://www.ietf.org/proceedings/interim/2016/05/31/its/proceedings.html = = Additional information: Intelligent Transportation Systems (its) BOF will hold a virtual interim meeting on May 31, 2016 at 1000 EDT (1400 UTC) for 1 hour. Agenda: Introduction =E2=80=94 Chairs =E2=80=94 5 minutes Finalizing charter text and deliverables =E2=80=94 Alex =E2=80=94 = 45 minutes Finding authors for each deliverable =E2=80=94 Chairs =E2=80=94 = 10 minutes Thanks! =E2=80=94 Carlos. > On May 12, 2016, at 6:45 PM, Russ Housley = wrote: >=20 > ITS Virtual BOF Session > Tuesday, May 31, 2016 > 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr >=20 > Join WebEx meeting = > Meeting number: 644 158 525 > Meeting password: may31st >=20 > Join by phone > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 644 158 525 > Toll-free calling restrictions = >=20 > Add this meeting = to your calendar. (Cannot add from mobile devices.) >=20 > Need help? Go to http://help.webex.com . >=20 > IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its = --Apple-Mail=_5B120075-276E-4247-9F7D-366CCAA57867 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi, ITS,

Some additional info besides the WebEx = meeting information for our ITS Virtual Interim BOF found below.

Meeting materials will be found at:
https://www.ietf.org/proceedings/interim/2016/05/31/its/proceed= ings.html

Additional = information:

Intelligent Transportation = Systems (its) BOF will hold a virtual interim
meeting on = May 31, 2016 at 1000 EDT (1400 UTC) for 1 hour.

Agenda:
Introduction =E2=80=94 Chairs =E2=80= =94 5 minutes
Finalizing charter text and = deliverables =E2=80=94 Alex =E2=80=94 45 minutes
Finding = authors for each deliverable =E2=80=94 Chairs =E2=80=94 10 minutes

Thanks!

=E2=80=94 = Carlos.





On May 12, 2016, at 6:45 PM, Russ Housley = <housley@vigilsec.com> wrote:

ITS = Virtual BOF Session
Tuesday, May 31, 2016
10:00 = am  |  Eastern Daylight Time (New York, = GMT-04:00)  |  1 hr
 
Join WebEx meeting
Meeting number:644 158 525
Meeting password:may31st
 
Join by phone
1-877-668-4493 Call-in toll free = number (US/Canada)
1-650-479-3208 Call-in toll = number (US/Canada)
Access code: 644 158 525
Toll-free calling = restrictions
 
Add this = meeting to your = calendar. (Cannot add from mobile = devices.)
 
Need help? Go to http://help.webex.com.
 
IMPORTANT NOTICE: Please note that this WebEx = service allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the = session.
<WebEx_Meetin= g.ics>_______________________________________________
its mailing = list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

= --Apple-Mail=_5B120075-276E-4247-9F7D-366CCAA57867-- --Apple-Mail=_D123BCA9-1430-4870-87D8-3AB09DF4ABC4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXNQqkAAoJEIXgpQGOZny9lO0QAIXUrakLW83h2oPN/ueD+YFV gpgMjq9C84xmTYfd4nUW1H20RRy3a8jrQIqmlT8FxyJTj6dsffRQOb7hhp2jXyLQ 4XH55fTTIfCRQjBT/H+um1tF3BV5DyU9/kUnFpuM0SvWYKLrYqaSzYbijDyx5iSX 1JsIiXH6BPFmb2KWrTWYfL8rHyJymkfVGxe8kgHbPuyz87iPUWz7+wts0f6+OVcj oyPJl4Qjc+rbRG4X18Wsm73qk1J8+SDfSl33ontLWi6dCYRXFFqJ2zW4GmBJVrqB A+djuxHLsKInDx+rHBKQBbs+Bo0drvIp/MI2v40ielFIWXsdn9mMZiPcle1NZ7pH p+y+KE1pHpD5J23a4qjKcwteKqYm5hk+43prLx37Cvii6pZZ3gK82rbbm5HiegJz Hau3kL2xbJNanZzUDprXHO6S44lSas/5mDz2Qs3m/S5ja3YmnMkuO/BZFOTDtcdl ObFgrCJ9CMWpaxgF3C5oM+T0dsVWPUC9nWp3ALuWq0CT+HGowcJUDXiSk/QCLBvN 2ui3rzt19bdJaZQxBsRNfEgFTOgQqQyuZzjwEeUBGl49MtS2g+Jd03g/snRwCXP/ zLZXHYwj7rK5++duopadubaGJgEp3S4CtMNhBB6bExo8/qahyp77maXjNQY7LURI G7sxL3kVYhcyAQ0+93dw =BwA/ -----END PGP SIGNATURE----- --Apple-Mail=_D123BCA9-1430-4870-87D8-3AB09DF4ABC4-- From nobody Thu May 12 16:26:45 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 A725B12B020; Thu, 12 May 2016 16:26:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160512232644.31516.82715.idtracker@ietfa.amsl.com> Date: Thu, 12 May 2016 16:26:44 -0700 Archived-At: Cc: its@ietf.org Subject: [its] ITS BOF Virtual Interim Meeting: May 31, 2016 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 23:26:45 -0000 The Intelligent Transportation Systems (its) BOF will hold a virtual interim meeting on May 31, 2016 at 1000 EDT (1400 UTC). ITS Virtual BOF Session Tuesday, May 31, 2016 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m6a2426507fd79ed99642514b3c75c149 Meeting number: 644 158 525 Meeting password: may31st JOIN BY PHONE 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 644 158 525 Toll-free dialing restrictions: https://www.webex.com/pdf/tollfree_restrictions.pdf Add this meeting to your calendar (Cannot add from mobile devices): https://ietf.webex.com/ietf/j.php?MTID=m5f3d256232517f6c2e17acdeca317f3f Need help? Go to: http://help.webex.com IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. From nobody Tue May 17 14:31:05 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE3912DA2B for ; Tue, 17 May 2016 14:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKsYMSh-XGFz for ; Tue, 17 May 2016 14:31:02 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704CE12D9D1 for ; Tue, 17 May 2016 14:31:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4HLQhUW013104 for ; Tue, 17 May 2016 23:30:59 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DDA49208D03 for ; Tue, 17 May 2016 16:31:41 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CB1BF208C50 for ; Tue, 17 May 2016 16:31:41 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4HEVffA004566 for ; Tue, 17 May 2016 16:31:41 +0200 To: its@ietf.org References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> From: Alexandre Petrescu Message-ID: <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> Date: Tue, 17 May 2016 16:31:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <57275AB1.5030308@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 21:31:04 -0000 Hello, Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit : [...] > 1. Informational RFC "ITS General Problem Area" covering: > - What is ITS? > - Explain V2V, V2I, and related terms > - Why is IPv6 needed? > - Explain why some traffic will not use IPv6 > - Explain why other traffic will use IPv6 > - Use-cases, illustrating the expected areas for initial focus > - Informative references, relationship with other SDOs > > 2. Standards Track RFC "IPv6 over DSRC" This particular mentioning of "IPv6 over DSRC" has raised a number of questions. Do you think it is the appropriate title? Alex > > 3. Informational RFC "Problem Statement" covering: > - Problem statement > - Security considerations > - Privacy considerations From nobody Tue May 17 19:28:42 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0411412D583 for ; Tue, 17 May 2016 19:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDvBhSNLMhNC for ; Tue, 17 May 2016 19:28:39 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 60B5B12D57E for ; Tue, 17 May 2016 19:28:39 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id y69so12938933pfb.1 for ; Tue, 17 May 2016 19:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:date:in-reply-to:references:mime-version :content-transfer-encoding; bh=pYl0cx+ZyOWuV70QtmXEU3zvQGCpDqg2SEn5moWfqak=; b=j2poq/kMlZjxm9i6YogGQlVpXeYezRwpEQ20V5sLiQahiSX9c80EIN72S2u2QzARTL jam/1ACFMJe2hQ1UzrU8oHuz2lv3WUdUEK2QO8NKrFsdsfJMGyk1UKl3QOz8YD5gmMsG jnVMftJkGd1+grLcPqcVh4dYhcpQ2TSpH7+2/GCChwc115FBOpEpaCLTo6+dT2x/KUrb w3wpuhixQlU0sAyiJ9nv6DeCCd3RBIH24m1gv+Ry32Uo8bTpN3yvFnjiiiuL5enggUyk fB33Qz6hreFubr1oyupGyoQHxstjQDKLVVvxVZwx4r4QJ+rqHORuH+/XEimv70LGrH1l 3+RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=pYl0cx+ZyOWuV70QtmXEU3zvQGCpDqg2SEn5moWfqak=; b=Wj6QWNKdupdD51SOusuiCBfUlfZARb9IoKp/UQYGxSIVXV+yXakuZPw0pxa4gSNE7a c1GTdUBQTnLhR8MnBLOHwkLan+FY7vkWZE0ck1YkBHCMx/XjdpMHgD5Nj5C1x30iYdVD kXfOpFqyo+ZzOoiBQORZqXqo/C76Ns9JFmt3nP4wtpivY+Sfv0UyqMaJm/vWEhMmnwHN 7vG8n1WpFABkl5D6G9mh4TdFF3R+SvbSLyWwgJFNXAiAbnasjAK9JXpbg0U16krL0n9C 7E7NWq3G/nnH+rpkbPM9Wumt24Fz/xPjPiGvcY/7w3qN4Qz9/0Hcy3URBqvexwKvO++7 n3YQ== X-Gm-Message-State: AOPr4FXr5g4hjjpmII2u+i6XdPuRjYkH/1b609Y1YPYSdCu5gefWswJH9k18hzm35lCJfQ== X-Received: by 10.98.95.71 with SMTP id t68mr6929804pfb.158.1463538518978; Tue, 17 May 2016 19:28:38 -0700 (PDT) Received: from localhost.localdomain (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by smtp.gmail.com with ESMTPSA id kb15sm7731617pad.28.2016.05.17.19.28.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 May 2016 19:28:38 -0700 (PDT) Message-ID: <1463538517.3378.3.camel@gmail.com> From: Rex Buddenberg To: Alexandre Petrescu , its@ietf.org Date: Tue, 17 May 2016 19:28:37 -0700 In-Reply-To: <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 02:28:41 -0000 shared medium On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote: > Hello, > > > Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit : > [...] > > > > 1. Informational RFC "ITS General Problem Area" covering: > >   - What is ITS? > >      - Explain V2V, V2I, and related terms > >   - Why is IPv6 needed? > >      - Explain why some traffic will not use IPv6 > >      - Explain why other traffic will use IPv6 > >   - Use-cases, illustrating the expected areas for initial focus > >   - Informative references, relationship with other SDOs > > > > 2. Standards Track RFC "IPv6 over DSRC" > This particular mentioning of "IPv6 over DSRC" has raised a number > of  > questions. > > Do you think it is the appropriate title? > > Alex > > > > > > > 3. Informational RFC "Problem Statement" covering: > >    - Problem statement > >    - Security considerations > >    - Privacy considerations > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Wed May 18 00:24:01 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B5C12B03F for ; Wed, 18 May 2016 00:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3stV2__vu31 for ; Wed, 18 May 2016 00:23:58 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C571F12B02B for ; Wed, 18 May 2016 00:23:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4I7NtCq028394; Wed, 18 May 2016 09:23:55 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CDBCC205921; Wed, 18 May 2016 09:23:55 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C08922058F8; Wed, 18 May 2016 09:23:55 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4I7NsZN030993; Wed, 18 May 2016 09:23:54 +0200 To: Rex Buddenberg References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> <1463538517.3378.3.camel@gmail.com> From: Alexandre Petrescu Message-ID: <2cc0e36a-0f38-9aa7-128f-c63110bfd510@gmail.com> Date: Wed, 18 May 2016 09:23:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <1463538517.3378.3.camel@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: its@ietf.org Subject: Re: [its] latest charter text - title of items X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 07:24:00 -0000 Well yes, it's a shared medium. But "IPv6-over-foo" documents are titled something like: "Transmission of IPv6 Packets over Ethernet Networks" RFC 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" RFC 4944 "Transmission of IPv6 Packets over ITU-T G.9959 Networks" RFC 7428 What could DSRC in "IPv6 over DSRC" mean? The 802.11 OCB link? 802.11p? The set of WAVE WSMP messages? I am tempted to believe that in this context "DSRC" means "802.11 OCB". Alex Le 18/05/2016 à 04:28, Rex Buddenberg a écrit : > shared medium > > On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote: >> Hello, >> >> >> Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit : >> [...] >>> >>> 1. Informational RFC "ITS General Problem Area" covering: >>> - What is ITS? >>> - Explain V2V, V2I, and related terms >>> - Why is IPv6 needed? >>> - Explain why some traffic will not use IPv6 >>> - Explain why other traffic will use IPv6 >>> - Use-cases, illustrating the expected areas for initial focus >>> - Informative references, relationship with other SDOs >>> >>> 2. Standards Track RFC "IPv6 over DSRC" >> This particular mentioning of "IPv6 over DSRC" has raised a number >> of >> questions. >> >> Do you think it is the appropriate title? >> >> Alex >> >>> >>> >>> 3. Informational RFC "Problem Statement" covering: >>> - Problem statement >>> - Security considerations >>> - Privacy considerations >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > From nobody Tue May 24 05:41:38 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A417712D5A2 for ; Tue, 24 May 2016 05:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7_xu_93aw6j for ; Tue, 24 May 2016 05:41:34 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B399D12B05D for ; Tue, 24 May 2016 05:41:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4OCfVYo032201 for ; Tue, 24 May 2016 14:41:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5490A209906 for ; Tue, 24 May 2016 14:41:41 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4C3762098F3 for ; Tue, 24 May 2016 14:41:41 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4OCfV3R008322 for ; Tue, 24 May 2016 14:41:31 +0200 To: its@ietf.org References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> <1463538517.3378.3.camel@gmail.com> <2cc0e36a-0f38-9aa7-128f-c63110bfd510@gmail.com> From: Alexandre Petrescu Message-ID: <6469b110-d0e5-bb89-615e-e8993787908e@gmail.com> Date: Tue, 24 May 2016 14:41:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <2cc0e36a-0f38-9aa7-128f-c63110bfd510@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 12:41:37 -0000 Hello ITSers, I discussed with people involved in GCDC, yogoko, and open source of ETSI ITS CAM (github.com/alexvoronov/geonetworking), IEEE 802.11p (github.com/CTU-IIG/802.11p-linux) and SAE BSM at itsforge.net. At this time I believe the title of the work item number 2 should be: "IPv6 over 802.11p" and not "IPv6 over DSRC". In this title the "DSRC" term was a source of confusion: - it means link-layer in some context but app-layer in other, - the authoritative source of definition of 'DSRC' seems to be SAE, but not sure whether it's rather IEEE, or other - not sure where to look for it. On the contrary, '802.11p' is clearly defined as 'Outside the Context of a BSSID of 802.11' by IEEE. It always means link-layer (there are no 802.11p applications - an application runs equally well on 802.11b as on 802.11p). I will modify the title in the work item charter proposal accordingly. This does not preclude that later we can work on "Transmission of DSRC messages like BSM over IPv6 over 802.11p". Alex Le 18/05/2016 à 09:23, Alexandre Petrescu a écrit : > Well yes, it's a shared medium. > > But "IPv6-over-foo" documents are titled something like: > "Transmission of IPv6 Packets over Ethernet Networks" RFC 2464 > "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" RFC 4944 > "Transmission of IPv6 Packets over ITU-T G.9959 Networks" RFC 7428 > > What could DSRC in "IPv6 over DSRC" mean? The 802.11 OCB link? > 802.11p? The set of WAVE WSMP messages? > > I am tempted to believe that in this context "DSRC" means "802.11 OCB". > > Alex > > > Le 18/05/2016 à 04:28, Rex Buddenberg a écrit : >> shared medium >> >> On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote: >>> Hello, >>> >>> >>> Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit : >>> [...] >>>> >>>> 1. Informational RFC "ITS General Problem Area" covering: >>>> - What is ITS? >>>> - Explain V2V, V2I, and related terms >>>> - Why is IPv6 needed? >>>> - Explain why some traffic will not use IPv6 >>>> - Explain why other traffic will use IPv6 >>>> - Use-cases, illustrating the expected areas for initial focus >>>> - Informative references, relationship with other SDOs >>>> >>>> 2. Standards Track RFC "IPv6 over DSRC" >>> This particular mentioning of "IPv6 over DSRC" has raised a number >>> of >>> questions. >>> >>> Do you think it is the appropriate title? >>> >>> Alex >>> >>>> >>>> >>>> 3. Informational RFC "Problem Statement" covering: >>>> - Problem statement >>>> - Security considerations >>>> - Privacy considerations >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Wed May 25 00:47:53 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D1E12D527 for ; Wed, 25 May 2016 00:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztfXVSaS0X89 for ; Wed, 25 May 2016 00:47:49 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DEE12D1D7 for ; Wed, 25 May 2016 00:47:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4P7lj9P005925; Wed, 25 May 2016 09:47:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2708B20A16E; Wed, 25 May 2016 09:47:56 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 19DBF201549; Wed, 25 May 2016 09:47:56 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4P7ljNA009468; Wed, 25 May 2016 09:47:45 +0200 To: dickroy@alum.mit.edu References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> <1463538517.3378.3.camel@gmail.com> <2cc0e36a-0f38-9aa7-128f-c63110bfd510@gmail.com> <6469b110-d0e5-bb89-615e-e8993787908e@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 25 May 2016 09:47:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.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] latest charter text - title of items "IPv6 over 802.11p" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 07:47:52 -0000 Le 25/05/2016 à 00:46, Dick Roy a écrit : > There are two problems with using the term "802.11p". > > 1) Technically, it no longer exists within IEEE 802. If you go to try to > find documentation on it, it will be difficult at best. I can agree. Instead of saying 802.11p, how about: "IPv6 over 802.11-OCB, with optional Timestamp Advertise Message, and with half-rate OFDM at 5.9GHz" The unique IEEE document is called "802.11" and has a "OCB" flag. (there are no longer 802.11b, or 802.11g documents, nor 802.11p for that matter.) > 2) Being outside the context of a BSS has NOTHING to do with any mods or > additions to IPv6 functions that might be required. In a sense yes, but indirectly there may be some needs. Indeed being OCB does not change the fact that the ethertype must be 0x86DD (and not 0x8947 geonet, nor 0x88DC WAVE)- this maybe the single most important point of such a spec. But there could be some other needs. What do you think could be other needs? The ones I think of are the following: Being OCB means there is no link-layer security, which means that IPv6-over-OCB MUST use some IP security mechanism - there is no optionality. It is a fundamental requirement. Being OCB has some other impacts in IP handovers between OCB links. Being OCB and with TSA may mean that rather than TSA one should use an IPv6 Router Advertisement containing a timestamp. > You would do well to simply drop any mention of ANY particular MAC&PHY and > do not use the word "over" in the title (or your thoughts, for that matter). In a sense yes, but the use of "over" is not my particular thought. I learned this at IETF. There is an established practice of writing "IPv6 over foo documents": RFC 2464 "IPv6 over Ethernet" RFC 2470 "IPv6 over Token Ring" ... RFC 4944 "IPv6 over 802.15.4" etc. Currently there are numerous ongoing "IPv6 over foo" efforts at IETF, e.g. "IPv6 over NFC": https://tools.ietf.org/html/draft-ietf-6lo-nfc-03 > Simply think of "networks with rapidly changing topology and unreliable > links" ... GOOD ENOUGH. Good enough, but there is other ongoing work of that kind: "Multi-hop Ad Hoc Wireless Communication" draft-ietf-intarea-adhoc-wireless-com-01 abstract: > This document describes characteristics of communication between > interfaces in a multi-hop ad hoc wireless network, that protocol > engineers and system analysts should be aware of when designing > solutions for ad hoc networks at the IP layer. https://tools.ietf.org/html/draft-ietf-intarea-adhoc-wireless-com-01 (that document is not particular to vehicular communications, doesnt use OCB). Alex > > Cheers, > > RR > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Tuesday, May 24, 2016 5:41 AM > To: its@ietf.org > Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p" > > Hello ITSers, > > I discussed with people involved in GCDC, yogoko, and open source of > ETSI ITS CAM (github.com/alexvoronov/geonetworking), IEEE 802.11p > (github.com/CTU-IIG/802.11p-linux) and SAE BSM at itsforge.net. > > At this time I believe the title of the work item number 2 should be: > > "IPv6 over 802.11p" and not "IPv6 over DSRC". > > In this title the "DSRC" term was a source of confusion: > - it means link-layer in some context but app-layer in other, > - the authoritative source of definition of 'DSRC' seems to be SAE, > but not sure whether it's rather IEEE, or other - not sure where to > look for it. > > On the contrary, '802.11p' is clearly defined as 'Outside the Context of > a BSSID of 802.11' by IEEE. It always means link-layer (there are no > 802.11p applications - an application runs equally well on 802.11b as on > 802.11p). > > I will modify the title in the work item charter proposal accordingly. > > This does not preclude that later we can work on "Transmission of DSRC > messages like BSM over IPv6 over 802.11p". > > Alex > > Le 18/05/2016 à 09:23, Alexandre Petrescu a écrit : >> Well yes, it's a shared medium. >> >> But "IPv6-over-foo" documents are titled something like: >> "Transmission of IPv6 Packets over Ethernet Networks" RFC 2464 >> "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" RFC 4944 >> "Transmission of IPv6 Packets over ITU-T G.9959 Networks" RFC 7428 >> >> What could DSRC in "IPv6 over DSRC" mean? The 802.11 OCB link? >> 802.11p? The set of WAVE WSMP messages? >> >> I am tempted to believe that in this context "DSRC" means "802.11 OCB". >> >> Alex >> >> >> Le 18/05/2016 à 04:28, Rex Buddenberg a écrit : >>> shared medium >>> >>> On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote: >>>> Hello, >>>> >>>> >>>> Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit : >>>> [...] >>>>> >>>>> 1. Informational RFC "ITS General Problem Area" covering: >>>>> - What is ITS? >>>>> - Explain V2V, V2I, and related terms >>>>> - Why is IPv6 needed? >>>>> - Explain why some traffic will not use IPv6 >>>>> - Explain why other traffic will use IPv6 >>>>> - Use-cases, illustrating the expected areas for initial focus >>>>> - Informative references, relationship with other SDOs >>>>> >>>>> 2. Standards Track RFC "IPv6 over DSRC" >>>> This particular mentioning of "IPv6 over DSRC" has raised a number >>>> of >>>> questions. >>>> >>>> Do you think it is the appropriate title? >>>> >>>> Alex >>>> >>>>> >>>>> >>>>> 3. Informational RFC "Problem Statement" covering: >>>>> - Problem statement >>>>> - Security considerations >>>>> - Privacy considerations >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > > > From nobody Wed May 25 01:50:41 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834F712D137 for ; Wed, 25 May 2016 01:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21-7kYYFhf-o for ; Wed, 25 May 2016 01:50:38 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2743212D14F for ; Wed, 25 May 2016 01:50:37 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4P8oXbt000919; Wed, 25 May 2016 10:50:33 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 956CE201C1E; Wed, 25 May 2016 10:50:44 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8880D20A347; Wed, 25 May 2016 10:50:44 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4P8oXIf015607; Wed, 25 May 2016 10:50:33 +0200 From: Alexandre Petrescu To: dickroy@alum.mit.edu, its@ietf.org References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> <1463538517.3378.3.camel@gmail.com> <2cc0e36a-0f38-9aa7-128f-c63110bfd510@gmail.com> <6469b110-d0e5-bb89-615e-e8993787908e@gmail.com> <7D2F1744F772491CAF81F9D50BF5A2BC@SRA5> Message-ID: <5a35230a-59df-5c8e-538e-f2fd81d6801c@gmail.com> Date: Wed, 25 May 2016 10:50:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <7D2F1744F772491CAF81F9D50BF5A2BC@SRA5> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 08:50:40 -0000 Le 25/05/2016 à 00:49, Dick Roy a écrit : > Any mention of messages and/or message types that could or should or > might or can't or whatever be sent using this "new IP functionality" > is out of scope. IPv6 connectivity in highly transient environments > is the goal. Just keep it simple! I fully agree. That's why "DSRC" in the title is not simple at all. > Saying you are going to send BSMs using IPv6 is going to needlessly > ruffle some big feathers! I agree. Sending BSM over IPv6 over 802.11p may be an activity for later, if proven necessary. (BSM stands for "Basic Safety Message" and is defined by the Society of Automotive Engineers in the standard J2735_201603 "DSRC Message Set Dictionary", paying access; a BSM is however dissected by the freely available open source wireshark tool, and some packet captures are freely available open source at http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files#82) Alex > > RR > > -----Original Message----- From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, May 24, 2016 > 5:41 AM To: its@ietf.org Subject: Re: [its] latest charter text - > title of items "IPv6 over 802.11p" > > Hello ITSers, > > I discussed with people involved in GCDC, yogoko, and open source of > ETSI ITS CAM (github.com/alexvoronov/geonetworking), IEEE 802.11p > (github.com/CTU-IIG/802.11p-linux) and SAE BSM at itsforge.net. > > At this time I believe the title of the work item number 2 should > be: > > "IPv6 over 802.11p" and not "IPv6 over DSRC". > > In this title the "DSRC" term was a source of confusion: - it means > link-layer in some context but app-layer in other, - the > authoritative source of definition of 'DSRC' seems to be SAE, but not > sure whether it's rather IEEE, or other - not sure where to look for > it. > > On the contrary, '802.11p' is clearly defined as 'Outside the Context > of a BSSID of 802.11' by IEEE. It always means link-layer (there are > no 802.11p applications - an application runs equally well on 802.11b > as on 802.11p). > > I will modify the title in the work item charter proposal > accordingly. > > This does not preclude that later we can work on "Transmission of > DSRC messages like BSM over IPv6 over 802.11p". > > Alex > > Le 18/05/2016 à 09:23, Alexandre Petrescu a écrit : >> Well yes, it's a shared medium. >> >> But "IPv6-over-foo" documents are titled something like: >> "Transmission of IPv6 Packets over Ethernet Networks" RFC >> 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" RFC >> 4944 "Transmission of IPv6 Packets over ITU-T G.9959 Networks" RFC >> 7428 >> >> What could DSRC in "IPv6 over DSRC" mean? The 802.11 OCB link? >> 802.11p? The set of WAVE WSMP messages? >> >> I am tempted to believe that in this context "DSRC" means "802.11 >> OCB". >> >> Alex >> >> >> Le 18/05/2016 à 04:28, Rex Buddenberg a écrit : >>> shared medium >>> >>> On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote: >>>> Hello, >>>> >>>> >>>> Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit : [...] >>>>> >>>>> 1. Informational RFC "ITS General Problem Area" covering: - >>>>> What is ITS? - Explain V2V, V2I, and related terms - Why is >>>>> IPv6 needed? - Explain why some traffic will not use IPv6 - >>>>> Explain why other traffic will use IPv6 - Use-cases, >>>>> illustrating the expected areas for initial focus - >>>>> Informative references, relationship with other SDOs >>>>> >>>>> 2. Standards Track RFC "IPv6 over DSRC" >>>> This particular mentioning of "IPv6 over DSRC" has raised a >>>> number of questions. >>>> >>>> Do you think it is the appropriate title? >>>> >>>> Alex >>>> >>>>> >>>>> >>>>> 3. Informational RFC "Problem Statement" covering: - Problem >>>>> statement - Security considerations - Privacy considerations >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > > From nobody Wed May 25 23:56:16 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB18712D884 for ; Wed, 25 May 2016 23:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTA84webgC6m for ; Wed, 25 May 2016 23:56:12 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 794AD12D883 for ; Wed, 25 May 2016 23:56:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4Q6u6ul024147; Thu, 26 May 2016 08:56:06 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BB91C204F2A; Thu, 26 May 2016 08:56:18 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A5740200B4E; Thu, 26 May 2016 08:56:18 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4Q6u5Ob018681; Thu, 26 May 2016 08:56:06 +0200 To: dickroy@alum.mit.edu References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> <1463538517.3378.3.camel@gmail.com> <2cc0e36a-0f38-9aa7-128f-c63110bfd510@gmail.com> <6469b110-d0e5-bb89-615e-e8993787908e@gmail.com> <7D2F1744F772491CAF81F9D50BF5A2BC@SRA5> <5a35230a-59df-5c8e-538e-f2fd81d6801c@gmail.com> From: Alexandre Petrescu Message-ID: <624afe60-3d17-3a33-131e-542e71254a93@gmail.com> Date: Thu, 26 May 2016 08:56:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.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] latest charter text - title of items "IPv6 over 802.11p" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 06:56:15 -0000 Dick, thanks for the reply. Le 26/05/2016 à 08:44, Dick Roy a écrit : > > > -----Original Message----- From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Sent: Wednesday, May 25, 2016 > 1:51 AM To: dickroy@alum.mit.edu; its@ietf.org Subject: Re: [its] > latest charter text - title of items "IPv6 over 802.11p" > > Le 25/05/2016 à 00:49, Dick Roy a écrit : >> Any mention of messages and/or message types that could or should >> or might or can't or whatever be sent using this "new IP >> functionality" is out of scope. IPv6 connectivity in highly >> transient environments is the goal. Just keep it simple! > > I fully agree. That's why "DSRC" in the title is not simple at all. > >> Saying you are going to send BSMs using IPv6 is going to >> needlessly ruffle some big feathers! > > I agree. Sending BSM over IPv6 over 802.11p may be an activity for > later, if proven necessary. [RR>] Whether or not it happens has NO > bearing on the work this group should be considering. It's a local > broadcast, and does not need IPv6 at all. Well, let us save this discussion for later. There are many aspects that need to be mentioned about advantages and inconvenients of a network layer-less local broadcast. > (BSM stands for "Basic Safety Message" and is defined by the Society > of Automotive Engineers in the standard J2735_201603 "DSRC Message > Set Dictionary", paying access; a BSM is however dissected by the > freely available open source wireshark tool, and some packet captures > are freely available open source at > http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files > > > > [RR>] NB: The BSM is an ASN.1 data object. It's ABSTRACT. Ok. > It can be and is encoded in a variety of ways. When encoded > according to what a few people believe to be the correct encoding for > US V2V deployments, I hope there is BSM interoperability at least within US V2V deployments. That should me more than just what a few people believe. then yes, a wireshark tool programmed to decode > that particular encoding can dissect the contents. So when the rules > are finally set, if the encoding changes, so muist the wireshark > tools if they want to be able to "dissect the BSM". You mean the rules are undergoing change? Alex > > RR > > > Alex > >> >> RR >> >> -----Original Message----- From: Alexandre Petrescu >> [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, May 24, 2016 >> 5:41 AM To: its@ietf.org Subject: Re: [its] latest charter text - >> title of items "IPv6 over 802.11p" >> >> Hello ITSers, >> >> I discussed with people involved in GCDC, yogoko, and open source >> of ETSI ITS CAM (github.com/alexvoronov/geonetworking), IEEE >> 802.11p (github.com/CTU-IIG/802.11p-linux) and SAE BSM at >> itsforge.net. >> >> At this time I believe the title of the work item number 2 should >> be: >> >> "IPv6 over 802.11p" and not "IPv6 over DSRC". >> >> In this title the "DSRC" term was a source of confusion: - it >> means link-layer in some context but app-layer in other, - the >> authoritative source of definition of 'DSRC' seems to be SAE, but >> not sure whether it's rather IEEE, or other - not sure where to >> look for it. >> >> On the contrary, '802.11p' is clearly defined as 'Outside the >> Context of a BSSID of 802.11' by IEEE. It always means link-layer >> (there are no 802.11p applications - an application runs equally >> well on 802.11b as on 802.11p). >> >> I will modify the title in the work item charter proposal >> accordingly. >> >> This does not preclude that later we can work on "Transmission of >> DSRC messages like BSM over IPv6 over 802.11p". >> >> Alex >> >> Le 18/05/2016 à 09:23, Alexandre Petrescu a écrit : >>> Well yes, it's a shared medium. >>> >>> But "IPv6-over-foo" documents are titled something like: >>> "Transmission of IPv6 Packets over Ethernet Networks" RFC >>> 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" >>> RFC 4944 "Transmission of IPv6 Packets over ITU-T G.9959 >>> Networks" RFC 7428 >>> >>> What could DSRC in "IPv6 over DSRC" mean? The 802.11 OCB link? >>> 802.11p? The set of WAVE WSMP messages? >>> >>> I am tempted to believe that in this context "DSRC" means >>> "802.11 OCB". >>> >>> Alex >>> >>> >>> Le 18/05/2016 à 04:28, Rex Buddenberg a écrit : >>>> shared medium >>>> >>>> On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote: >>>>> Hello, >>>>> >>>>> >>>>> Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit : [...] >>>>>> >>>>>> 1. Informational RFC "ITS General Problem Area" covering: >>>>>> - What is ITS? - Explain V2V, V2I, and related terms - Why >>>>>> is IPv6 needed? - Explain why some traffic will not use >>>>>> IPv6 - Explain why other traffic will use IPv6 - >>>>>> Use-cases, illustrating the expected areas for initial >>>>>> focus - Informative references, relationship with other >>>>>> SDOs >>>>>> >>>>>> 2. Standards Track RFC "IPv6 over DSRC" >>>>> This particular mentioning of "IPv6 over DSRC" has raised a >>>>> number of questions. >>>>> >>>>> Do you think it is the appropriate title? >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> >>>>>> 3. Informational RFC "Problem Statement" covering: - >>>>>> Problem statement - Security considerations - Privacy >>>>>> considerations >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> >> >> > > > > From dickroy3777@comcast.net Thu May 26 10:13:45 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F2112D7CF for ; Thu, 26 May 2016 10:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.875 X-Spam-Level: X-Spam-Status: No, score=-3.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PI773vckAsrb for ; Thu, 26 May 2016 10:13:37 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22E612D7C0 for ; Thu, 26 May 2016 10:13:36 -0700 (PDT) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by comcast with SMTP id 5ynJbioEDWmAB5yqlb288j; Thu, 26 May 2016 17:13:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464282815; bh=UYFrETSoLiPZLQu+Du7bkmEtNEB0WI/c5y7nR7mr3QA=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=QaQSv2TbaXwGujwaIPaTUnSRmeb1FN8NRLZRMbXvqa5VxQ5AbvfCIq6rYwguhOerY CRycKcidIAG2ZjRcTfd3od/LO5GAm4VeuAi5XGL21adzZ91ZG9o26E5px1uSmgApxy Ptm3qT1CJ4puv7PcwWg1ZOmpKom1rSs4NPYyVm5/TxE3QhuwSvFIX7m/IQFYbjQjlE l+4BTRytEEMJdnekyso1w5XDFNZ7yvKvuwf/REAL6IJQIs78+hFrgy10hdYZEEMfkQ IwpoRImrJ5cZ7MbSkrqiPoXmz0TfRiNfDyIhX1rNMQ8Q9rGEO0A6D0WiNzplIGqnoG UxyAAWjGHyIxw== Received: from SRA5 ([73.231.86.178]) by resomta-po-16v.sys.comcast.net with comcast id z5Da1s0023qs29D015Datt; Thu, 26 May 2016 17:13:35 +0000 From: "Dick Roy" To: "'Alexandre Petrescu'" , References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> <1463538517.3378.3.camel@gmail.com> <2cc0e36a-0f38-9aa7-128f-c63110bfd510@gmail.com> <6469b110-d0e5-bb89-615e-e8993787908e@gmail.com> <7D2F1744F772491CAF81F9D50BF5A2BC@SRA5> <5a35230a-59df-5c8e-538e-f2fd81d6801c@gmail.com> <624afe60-3d17-3a33-131e-542e71254a93@gmail.com> In-Reply-To: <624afe60-3d17-3a33-131e-542e71254a93@gmail.com> Date: Thu, 26 May 2016 10:13:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0141_01D1B737.445AF130" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AdG3G7F5lxNufGb0RgSJafv7nANZVgAUK5vQ x-mimeole: Produced By Microsoft MimeOLE V10.0.10011.16384 Archived-At: X-Mailman-Approved-At: Thu, 26 May 2016 11:12:50 -0700 Cc: its@ietf.org Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 17:38:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0141_01D1B737.445AF130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At present, in the U.S., there are NO rules. NHTSA has yet to =93make = the rules=94. If all goes according to the current plan in the minds of a = few individuals, then the relevant SAE and IEEE standards that have been produced over the last 15 years will form the basis of that ruling. = Things could change, including the frequency allocations, between now and then. Stay tuned =85 =20 As for the BSM, it has little to no value outside a VERY LIMITED = geographic and temporal region. No one more than a few hundred meters from a given vehicle cares where it is, and even if it knew, within a few tenths of a second, it would be yesterday=92s news! There is NO thought that = broadcasting BSMs through networks makes any sense at all. That DOES NOT mean that logging a few for transmission to a TMC to be used for traffic = management and efficiency applications won=92t happen. But that is NOT an IP = broadcast. There is simply NO WAY all (or even a miniscule fraction thereof) BSMs transmitted are going to end up traversing IP networks. The network(s) can=92t handle all the USELESS information! =20 RR =20 -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Wednesday, May 25, 2016 11:56 PM To: dickroy@alum.mit.edu Cc: its@ietf.org Subject: Re: [its] latest charter text - title of items "IPv6 over = 802.11p" =20 Dick, thanks for the reply. =20 Le 26/05/2016 =E0 08:44, Dick Roy a =E9crit : >=20 >=20 > -----Original Message----- From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Sent: Wednesday, May 25, 2016 > 1:51 AM To: dickroy@alum.mit.edu; its@ietf.org Subject: Re: [its] > latest charter text - title of items "IPv6 over 802.11p" >=20 > Le 25/05/2016 =E0 00:49, Dick Roy a =E9crit : >> Any mention of messages and/or message types that could or should >> or might or can't or whatever be sent using this "new IP >> functionality" is out of scope. IPv6 connectivity in highly >> transient environments is the goal. Just keep it simple! >=20 > I fully agree. That's why "DSRC" in the title is not simple at all. >=20 >> Saying you are going to send BSMs using IPv6 is going to >> needlessly ruffle some big feathers! >=20 > I agree. Sending BSM over IPv6 over 802.11p may be an activity for > later, if proven necessary. [RR>] Whether or not it happens has NO > bearing on the work this group should be considering. It's a local > broadcast, and does not need IPv6 at all. =20 Well, let us save this discussion for later. There are many aspects that need to be mentioned about advantages and inconvenients of a network layer-less local broadcast. =20 > (BSM stands for "Basic Safety Message" and is defined by the Society > of Automotive Engineers in the standard J2735_201603 "DSRC Message > Set Dictionary", paying access; a BSM is however dissected by the > freely available open source wireshark tool, and some packet captures > are freely available open source at > http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-fi= les >=20 >=20 >=20 > [RR>] NB: The BSM is an ASN.1 data object. It's ABSTRACT. =20 Ok. =20 > It can be and is encoded in a variety of ways. When encoded > according to what a few people believe to be the correct encoding for > US V2V deployments, =20 I hope there is BSM interoperability at least within US V2V deployments. = That should me more than just what a few people believe. =20 then yes, a wireshark tool programmed to decode > that particular encoding can dissect the contents. So when the rules > are finally set, if the encoding changes, so muist the wireshark > tools if they want to be able to "dissect the BSM". =20 You mean the rules are undergoing change? =20 Alex =20 >=20 > RR >=20 >=20 > Alex >=20 >>=20 >> RR >>=20 >> -----Original Message----- From: Alexandre Petrescu >> [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, May 24, 2016 >> 5:41 AM To: its@ietf.org Subject: Re: [its] latest charter text - >> title of items "IPv6 over 802.11p" >>=20 >> Hello ITSers, >>=20 >> I discussed with people involved in GCDC, yogoko, and open source >> of ETSI ITS CAM (github.com/alexvoronov/geonetworking), IEEE >> 802.11p (github.com/CTU-IIG/802.11p-linux) and SAE BSM at >> itsforge.net. >>=20 >> At this time I believe the title of the work item number 2 should >> be: >>=20 >> "IPv6 over 802.11p" and not "IPv6 over DSRC". >>=20 >> In this title the "DSRC" term was a source of confusion: - it >> means link-layer in some context but app-layer in other, - the >> authoritative source of definition of 'DSRC' seems to be SAE, but >> not sure whether it's rather IEEE, or other - not sure where to >> look for it. >>=20 >> On the contrary, '802.11p' is clearly defined as 'Outside the >> Context of a BSSID of 802.11' by IEEE. It always means link-layer >> (there are no 802.11p applications - an application runs equally >> well on 802.11b as on 802.11p). >>=20 >> I will modify the title in the work item charter proposal >> accordingly. >>=20 >> This does not preclude that later we can work on "Transmission of >> DSRC messages like BSM over IPv6 over 802.11p". >>=20 >> Alex >>=20 >> Le 18/05/2016 =E0 09:23, Alexandre Petrescu a =E9crit : >>> Well yes, it's a shared medium. >>>=20 >>> But "IPv6-over-foo" documents are titled something like: >>> "Transmission of IPv6 Packets over Ethernet Networks" RFC >>> 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" >>> RFC 4944 "Transmission of IPv6 Packets over ITU-T G.9959 >>> Networks" RFC 7428 >>>=20 >>> What could DSRC in "IPv6 over DSRC" mean? The 802.11 OCB link? >>> 802.11p? The set of WAVE WSMP messages? >>>=20 >>> I am tempted to believe that in this context "DSRC" means >>> "802.11 OCB". >>>=20 >>> Alex >>>=20 >>>=20 >>> Le 18/05/2016 =E0 04:28, Rex Buddenberg a =E9crit : >>>> shared medium >>>>=20 >>>> On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote: >>>>> Hello, >>>>>=20 >>>>>=20 >>>>> Le 02/05/2016 =E0 15:48, Alexandre Petrescu a =E9crit : [...] >>>>>>=20 >>>>>> 1. Informational RFC "ITS General Problem Area" covering: >>>>>> - What is ITS? - Explain V2V, V2I, and related terms - Why >>>>>> is IPv6 needed? - Explain why some traffic will not use >>>>>> IPv6 - Explain why other traffic will use IPv6 - >>>>>> Use-cases, illustrating the expected areas for initial >>>>>> focus - Informative references, relationship with other >>>>>> SDOs >>>>>>=20 >>>>>> 2. Standards Track RFC "IPv6 over DSRC" >>>>> This particular mentioning of "IPv6 over DSRC" has raised a >>>>> number of questions. >>>>>=20 >>>>> Do you think it is the appropriate title? >>>>>=20 >>>>> Alex >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> 3. Informational RFC "Problem Statement" covering: - >>>>>> Problem statement - Security considerations - Privacy >>>>>> considerations >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>=20 >>>=20 >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 ------=_NextPart_000_0141_01D1B737.445AF130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

 

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

 

RR

 

-----Original Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
Sent: Wednesday, May 25, 2016 11:56 PM
To: dickroy@alum.mit.edu
Cc: its@ietf.org
Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p"

 

Dick, thanks for the reply.

 

Le 26/05/2016 =E0 08:44, Dick Roy a =E9crit = :

> 

> 

> -----Original Message----- From: Alexandre = Petrescu

> [mailto:alexandre.petrescu@gmail.com] Sent: Wednesday, May = 25, 2016

> 1:51 AM To: dickroy@alum.mit.edu; its@ietf.org Subject: Re: = [its]

> latest charter text - title of items "IPv6 over = 802.11p"

> 

> Le 25/05/2016 =E0 00:49, Dick Roy a =E9crit = :

>> Any mention of messages and/or message types that could = or should

>> or might or can't or whatever be sent using this = "new IP

>> functionality" is out of scope.=A0 IPv6 = connectivity in highly

>> transient environments is the goal. Just keep it = simple!

> 

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

> 

>> Saying you are going to send BSMs using IPv6 is going = to

>> needlessly ruffle some big = feathers!

> 

> I agree.=A0 Sending BSM over IPv6 over 802.11p may be an = activity for

> later, if proven necessary. [RR>] Whether or not it = happens has NO

> bearing on the work this group should be considering.=A0 = It's a local

> broadcast, and does not need IPv6 at = all.

 

Well, let us save this discussion for later.=A0 There are many = aspects

that need to be mentioned about advantages and inconvenients of = a

network layer-less local broadcast.

 

> (BSM stands for "Basic Safety Message" and is = defined by the Society

> of Automotive Engineers in the standard J2735_201603 = "DSRC Message

> Set Dictionary", paying access; a BSM is however = dissected by the

> freely available open source wireshark tool, and some = packet captures

> are freely available open source = at

> http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-fi= les

> 

> 

> 

> [RR>] NB: The BSM is an ASN.1 data object. It's = ABSTRACT.

 

Ok.

 

> It can be and is encoded in a variety of ways.=A0 When = encoded

> according to what a few people believe to be the correct = encoding for

> US V2V deployments,

 

I hope there is BSM interoperability at least within US V2V deployments.

=A0 That should me more than just what a few people = believe.

 

=A0 then yes, a wireshark tool programmed to = decode

> that particular encoding can dissect the contents.=A0 So = when the rules

> are finally set, if the encoding changes, so muist the = wireshark

> tools if they want to be able to "dissect the = BSM".

 

You mean the rules are undergoing = change?

 

Alex

 

> 

> RR

> 

> 

> Alex

> 

>> 

>> RR

>> 

>> -----Original Message----- From: Alexandre = Petrescu

>> [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, = May 24, 2016

>> 5:41 AM To: its@ietf.org Subject: Re: [its] latest = charter text -

>> title of items "IPv6 over = 802.11p"

>> 

>> Hello ITSers,

>> 

>> I discussed with people involved in GCDC, yogoko, and = open source

>> of ETSI ITS CAM (github.com/alexvoronov/geonetworking), = IEEE

>> 802.11p (github.com/CTU-IIG/802.11p-linux) and SAE BSM = at

>> itsforge.net.

>> 

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

>> be:

>> 

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

>> 

>> In this title the "DSRC" term was a source of confusion: - it

>> means link-layer in some context but app-layer in = other, - the

>> authoritative source of definition of 'DSRC' seems to = be SAE, but

>> not sure whether it's rather IEEE, or other - not sure = where to

>> look for it.

>> 

>> On the contrary, '802.11p' is clearly defined as = 'Outside the

>> Context of a BSSID of 802.11' by IEEE.=A0 It always = means link-layer

>> (there are no 802.11p applications - an application = runs equally

>> well on 802.11b as on = 802.11p).

>> 

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

>> accordingly.

>> 

>> This does not preclude that later we can work on "Transmission of

>> DSRC messages like BSM over IPv6 over = 802.11p".

>> 

>> Alex

>> 

>> Le 18/05/2016 =E0 09:23, Alexandre Petrescu a =E9crit = :

>>> Well yes, it's a shared = medium.

>>> 

>>> But "IPv6-over-foo" documents are titled something like:

>>> "Transmission of IPv6 Packets over Ethernet Networks"=A0=A0=A0=A0=A0 RFC

>>> 2464 "Transmission of IPv6 Packets over IEEE = 802.15.4 Networks"

>>> RFC 4944 "Transmission of IPv6 Packets over = ITU-T G.9959

>>> Networks"=A0 RFC = 7428

>>> 

>>> What could DSRC in "IPv6 over DSRC" = mean?=A0 The 802.11 OCB link?

>>> 802.11p?=A0 The set of WAVE WSMP = messages?

>>> 

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

>>> "802.11 = OCB".

>>> 

>>> Alex

>>> 

>>> 

>>> Le 18/05/2016 =E0 04:28, Rex Buddenberg a =E9crit = :

>>>> shared medium

>>>> 

>>>> On Tue, 2016-05-17 at 16:31 +0200, Alexandre = Petrescu wrote:

>>>>> Hello,

>>>>> 

>>>>> 

>>>>> Le 02/05/2016 =E0 15:48, Alexandre Petrescu = a =E9crit : [...]

>>>>>> 

>>>>>> 1. Informational RFC "ITS General = Problem Area" covering:

>>>>>> - What is ITS? - Explain V2V, V2I, and = related terms - Why

>>>>>> is IPv6 needed? - Explain why some = traffic will not use

>>>>>> IPv6 - Explain why other traffic will = use IPv6 -

>>>>>> Use-cases, illustrating the expected = areas for initial

>>>>>> focus - Informative references, = relationship with other

>>>>>> SDOs

>>>>>> 

>>>>>> 2. Standards Track RFC "IPv6 over DSRC"

>>>>> This particular mentioning of "IPv6 = over DSRC" has raised a

>>>>> number of = questions.

>>>>> 

>>>>> Do you think it is the appropriate = title?

>>>>> 

>>>>> Alex

>>>>> 

>>>>>> 

>>>>>> 

>>>>>> 3. Informational RFC "Problem Statement" covering: -

>>>>>> Problem statement - Security = considerations - Privacy

>>>>>> = considerations

>>>>> = _______________________________________________ its mailing

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

>>>> 

>>> 

>>> _______________________________________________ its mailing list

>>> its@ietf.org = https://www.ietf.org/mailman/listinfo/its

>> 

>> 

>> 

>> 

> 

> 

> 

> 

------=_NextPart_000_0141_01D1B737.445AF130-- From nobody Thu May 26 11:40:02 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2B612D13A for ; Thu, 26 May 2016 11:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=us-toyota-itc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU19x2qiA2Su for ; Thu, 26 May 2016 11:39:59 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 957CE12D096 for ; Thu, 26 May 2016 11:39:58 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id j1so138237559oih.3 for ; Thu, 26 May 2016 11:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us-toyota-itc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=AJSHXJYyqnAp3Z8SBIX66ArOIzSnbL2Zw7SRRr3WMZM=; b=2DWDZHEdVprS3Zbc1bEojq8yDIojTSfNsT2uiApY4kVE//B57oxXzvh00KMCwPv8rx s7Yiey+T07835RbYwF6QvwVOXxiTJsDDwxmqf9ySml2aE0ct4Mv/+FKYF9QlEH4evS8f /LkfRzITOy1g00mL9BWrjx8D3fFHsv085bQemOyfLVLc2z/mobhKaVmoYWnCYDWmKXU6 A8tJPVek+XH9iFbeiJBBpFPGkPSs2EiKmvmU1fstN9B8MdyWyE9pwq3Ix9Y0PoMEzWkD LKeJFHe7QbLeWF+2SPAeGVtXv3ezJ8/WCwQ2RrYO1K1gEzaOHhUM4t9bWdFA/Hb9ZOtk Q6aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AJSHXJYyqnAp3Z8SBIX66ArOIzSnbL2Zw7SRRr3WMZM=; b=ZAsN1tNiGyi2rnJuRi+PHeeQFtWigwoMXR4A+dVagmyznNJPUYu/bPCrPmiQlqk0k5 epfyH9a43KF5OtZg7kRvvSwmQnay9BaBJC6Y9Mh5k4EsRtjMffhwzDKAcyVTnTgI0M6e D/5fuVNuqrhO/ycbhSw98UUdtzW1yPep8vHqHdjseUAppvXlc5SlpaWDxzMW28lAGAA4 dBAw+85jSUFbaCXDZphXI/bOM+5i9vCrapwZzENxyAJ5ug8IOOHM5wPT6aWvC3oIwDo+ dk6zAPzKtYiBcbOsfQA1lusF3mdQvTKpCBk8H/yERKy7PPAEzqKG7i7gqfNAfHL2ngq+ YrHg== X-Gm-Message-State: ALyK8tJrx7GS3KDIqCLOFb2aqILY1Nr06U0Xj2NNvGpdGATsvjH0Dp6KtL2dpqrrs+BP1QF0jj9dbSHFwkgYYYRJ MIME-Version: 1.0 X-Received: by 10.202.224.138 with SMTP id x132mr6165021oig.28.1464287997750; Thu, 26 May 2016 11:39:57 -0700 (PDT) Received: by 10.157.22.162 with HTTP; Thu, 26 May 2016 11:39:57 -0700 (PDT) In-Reply-To: References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> <1463538517.3378.3.camel@gmail.com> <2cc0e36a-0f38-9aa7-128f-c63110bfd510@gmail.com> <6469b110-d0e5-bb89-615e-e8993787908e@gmail.com> <7D2F1744F772491CAF81F9D50BF5A2BC@SRA5> <5a35230a-59df-5c8e-538e-f2fd81d6801c@gmail.com> <624afe60-3d17-3a33-131e-542e71254a93@gmail.com> Date: Thu, 26 May 2016 11:39:57 -0700 Message-ID: From: John Kenney To: Dick Roy Content-Type: multipart/alternative; boundary=001a113d306af48c6d0533c31d59 Archived-At: Cc: Alexandre Petrescu , Richard Roy , "its@ietf.org" Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 18:40:02 -0000 --001a113d306af48c6d0533c31d59 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't disagree with Dick's second paragraph, but I wouldn't want there to be confusion about the existence of "rules." The auto industry has worked hard to develop and publish key standards related to the BSM (SAE J2735, SAE J2945/1), so there will be interoperability. Deployments are moving ahead in the US based on those standards. Best Regards, John On Thu, May 26, 2016 at 10:13 AM, Dick Roy wrote: > At present, in the U.S., there are NO rules. NHTSA has yet to =E2=80=9Cm= ake the > rules=E2=80=9D. If all goes according to the current plan in the minds o= f a few > individuals, then the relevant SAE and IEEE standards that have been > produced over the last 15 years will form the basis of that ruling. Thin= gs > could change, including the frequency allocations, between now and then. > Stay tuned =E2=80=A6 > > > > As for the BSM, it has little to no value outside a VERY LIMITED > geographic and temporal region. No one more than a few hundred meters fr= om > a given vehicle cares where it is, and even if it knew, within a few tent= hs > of a second, it would be yesterday=E2=80=99s news! There is NO thought t= hat > broadcasting BSMs through networks makes any sense at all. That DOES NOT > mean that logging a few for transmission to a TMC to be used for traffic > management and efficiency applications won=E2=80=99t happen. But that is= NOT an IP > broadcast. There is simply NO WAY all (or even a miniscule fraction > thereof) BSMs transmitted are going to end up traversing IP networks. Th= e > network(s) can=E2=80=99t handle all the USELESS information! > > > > RR > > > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Wednesday, May 25, 2016 11:56 PM > To: dickroy@alum.mit.edu > Cc: its@ietf.org > Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11= p" > > > > Dick, thanks for the reply. > > > > Le 26/05/2016 =C3=A0 08:44, Dick Roy a =C3=A9crit : > > > > > > > > > -----Original Message----- From: Alexandre Petrescu > > > [mailto:alexandre.petrescu@gmail.com] Sent: Wednesday, May 25, 2016 > > > 1:51 AM To: dickroy@alum.mit.edu; its@ietf.org Subject: Re: [its] > > > latest charter text - title of items "IPv6 over 802.11p" > > > > > > Le 25/05/2016 =C3=A0 00:49, Dick Roy a =C3=A9crit : > > >> Any mention of messages and/or message types that could or should > > >> or might or can't or whatever be sent using this "new IP > > >> functionality" is out of scope. IPv6 connectivity in highly > > >> transient environments is the goal. Just keep it simple! > > > > > > I fully agree. That's why "DSRC" in the title is not simple at all. > > > > > >> Saying you are going to send BSMs using IPv6 is going to > > >> needlessly ruffle some big feathers! > > > > > > I agree. Sending BSM over IPv6 over 802.11p may be an activity for > > > later, if proven necessary. [RR>] Whether or not it happens has NO > > > bearing on the work this group should be considering. It's a local > > > broadcast, and does not need IPv6 at all. > > > > Well, let us save this discussion for later. There are many aspects > > that need to be mentioned about advantages and inconvenients of a > > network layer-less local broadcast. > > > > > (BSM stands for "Basic Safety Message" and is defined by the Society > > > of Automotive Engineers in the standard J2735_201603 "DSRC Message > > > Set Dictionary", paying access; a BSM is however dissected by the > > > freely available open source wireshark tool, and some packet captures > > > are freely available open source at > > > > http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-fi= les > > > > > > > > > > > > [RR>] NB: The BSM is an ASN.1 data object. It's ABSTRACT. > > > > Ok. > > > > > It can be and is encoded in a variety of ways. When encoded > > > according to what a few people believe to be the correct encoding for > > > US V2V deployments, > > > > I hope there is BSM interoperability at least within US V2V deployments. > > That should me more than just what a few people believe. > > > > then yes, a wireshark tool programmed to decode > > > that particular encoding can dissect the contents. So when the rules > > > are finally set, if the encoding changes, so muist the wireshark > > > tools if they want to be able to "dissect the BSM". > > > > You mean the rules are undergoing change? > > > > Alex > > > > > > > > RR > > > > > > > > > Alex > > > > > >> > > >> RR > > >> > > >> -----Original Message----- From: Alexandre Petrescu > > >> [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, May 24, 2016 > > >> 5:41 AM To: its@ietf.org Subject: Re: [its] latest charter text - > > >> title of items "IPv6 over 802.11p" > > >> > > >> Hello ITSers, > > >> > > >> I discussed with people involved in GCDC, yogoko, and open source > > >> of ETSI ITS CAM (github.com/alexvoronov/geonetworking), IEEE > > >> 802.11p (github.com/CTU-IIG/802.11p-linux) and SAE BSM at > > >> itsforge.net. > > >> > > >> At this time I believe the title of the work item number 2 should > > >> be: > > >> > > >> "IPv6 over 802.11p" and not "IPv6 over DSRC". > > >> > > >> In this title the "DSRC" term was a source of confusion: - it > > >> means link-layer in some context but app-layer in other, - the > > >> authoritative source of definition of 'DSRC' seems to be SAE, but > > >> not sure whether it's rather IEEE, or other - not sure where to > > >> look for it. > > >> > > >> On the contrary, '802.11p' is clearly defined as 'Outside the > > >> Context of a BSSID of 802.11' by IEEE. It always means link-layer > > >> (there are no 802.11p applications - an application runs equally > > >> well on 802.11b as on 802.11p). > > >> > > >> I will modify the title in the work item charter proposal > > >> accordingly. > > >> > > >> This does not preclude that later we can work on "Transmission of > > >> DSRC messages like BSM over IPv6 over 802.11p". > > >> > > >> Alex > > >> > > >> Le 18/05/2016 =C3=A0 09:23, Alexandre Petrescu a =C3=A9crit : > > >>> Well yes, it's a shared medium. > > >>> > > >>> But "IPv6-over-foo" documents are titled something like: > > >>> "Transmission of IPv6 Packets over Ethernet Networks" RFC > > >>> 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" > > >>> RFC 4944 "Transmission of IPv6 Packets over ITU-T G.9959 > > >>> Networks" RFC 7428 > > >>> > > >>> What could DSRC in "IPv6 over DSRC" mean? The 802.11 OCB link? > > >>> 802.11p? The set of WAVE WSMP messages? > > >>> > > >>> I am tempted to believe that in this context "DSRC" means > > >>> "802.11 OCB". > > >>> > > >>> Alex > > >>> > > >>> > > >>> Le 18/05/2016 =C3=A0 04:28, Rex Buddenberg a =C3=A9crit : > > >>>> shared medium > > >>>> > > >>>> On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote: > > >>>>> Hello, > > >>>>> > > >>>>> > > >>>>> Le 02/05/2016 =C3=A0 15:48, Alexandre Petrescu a =C3=A9crit : [...] > > >>>>>> > > >>>>>> 1. Informational RFC "ITS General Problem Area" covering: > > >>>>>> - What is ITS? - Explain V2V, V2I, and related terms - Why > > >>>>>> is IPv6 needed? - Explain why some traffic will not use > > >>>>>> IPv6 - Explain why other traffic will use IPv6 - > > >>>>>> Use-cases, illustrating the expected areas for initial > > >>>>>> focus - Informative references, relationship with other > > >>>>>> SDOs > > >>>>>> > > >>>>>> 2. Standards Track RFC "IPv6 over DSRC" > > >>>>> This particular mentioning of "IPv6 over DSRC" has raised a > > >>>>> number of questions. > > >>>>> > > >>>>> Do you think it is the appropriate title? > > >>>>> > > >>>>> Alex > > >>>>> > > >>>>>> > > >>>>>> > > >>>>>> 3. Informational RFC "Problem Statement" covering: - > > >>>>>> Problem statement - Security considerations - Privacy > > >>>>>> considerations > > >>>>> _______________________________________________ its mailing > > >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its > > >>>> > > >>> > > >>> _______________________________________________ its mailing list > > >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --=20 John Kenney Director and Principal Researcher Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 --001a113d306af48c6d0533c31d59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't disagree with Dick's second paragraph, but= I wouldn't want there to be confusion about the existence of "rul= es." The auto industry has worked hard to develop and publish key stan= dards related to the BSM (SAE J2735, SAE J2945/1), so there will be interop= erability.=C2=A0 Deployments are moving ahead in the US based on those stan= dards.

Best Regards,
John

On Thu, May 26, 2016 at 10= :13 AM, Dick Roy <dickroy3777@comcast.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

A= t present, in the U.S., there are NO rules.=C2=A0 NHTSA has yet to =E2=80=9Cmake the rules=E2=80=9D= .=C2=A0 If all goes according to the current plan in the minds of a few individuals, then = the relevant SAE and IEEE standards that have been produced over the last 15 years will = form the basis of that ruling.=C2=A0 Things could change, including the frequenc= y allocations, between now and then.=C2=A0 Stay tuned =E2=80=A6=

<= u>=C2=A0

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

<= u>=C2=A0

R= R

<= u>=C2=A0

<= span class=3D"">-----Original Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]

Sent: Wednesday, May 25, 2016 11:56 PM
To: dickroy@alum.= mit.edu
Cc: its@ietf.org
Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p"

<= u>=C2=A0

D= ick, thanks for the reply.

<= u>=C2=A0

L= e 26/05/2016 =C3=A0 08:44, Dick Roy a =C3=A9crit :

&= gt;=C2=A0

&= gt;=C2=A0

&= gt; -----Original Message----- From: Alexandre Petrescu

&= gt; [mailto:alexandre.petrescu@gmail.com] Sent: Wednesday, May 25, 2016

&= gt; 1:51 AM To: d= ickroy@alum.mit.edu; = its@ietf.org Subject: Re: [its]

&= gt; latest charter text - title of items "IPv6 over 802.11p"

&= gt;=C2=A0

&= gt; Le 25/05/2016 =C3=A0 00:49, Dick Roy a =C3=A9crit :

&= gt;> Any mention of messages and/or message types that could or should

&= gt;> or might or can't or whatever be sent using this "new IP

&= gt;> functionality" is out of scope.=C2=A0 IPv6 connectivity in highly

&= gt;> transient environments is the goal. Just keep it simple!<= /u>

&= gt;=C2=A0

&= gt; I fully agree.=C2=A0 That's why "DSRC" in the title is no= t simple at all.

&= gt;=C2=A0

&= gt;> Saying you are going to send BSMs using IPv6 is going to<= /u>

&= gt;> needlessly ruffle some big feathers!

&= gt;=C2=A0

&= gt; I agree.=C2=A0 Sending BSM over IPv6 over 802.11p may be an activity for

&= gt; later, if proven necessary. [RR>] Whether or not it happens has NO

&= gt; bearing on the work this group should be considering.=C2=A0 It's a local

&= gt; broadcast, and does not need IPv6 at all.

<= u>=C2=A0

W= ell, let us save this discussion for later.=C2=A0 There are many aspects=

t= hat need to be mentioned about advantages and inconvenients of a<= /u>

n= etwork layer-less local broadcast.

=C2=A0

&= gt; (BSM stands for "Basic Safety Message" and is defined by the Society

&= gt; of Automotive Engineers in the standard J2735_201603 "DSRC Message

&= gt; Set Dictionary", paying access; a BSM is however dissected by the

&= gt; freely available open source wireshark tool, and some packet captures

&= gt; are freely available open source at

&= gt; http://www.itsforge.net/index.php/forum/cv-= dsrc-message-parser/44-test-files

&= gt;=C2=A0

&= gt;=C2=A0

&= gt;=C2=A0

&= gt; [RR>] NB: The BSM is an ASN.1 data object. It's ABSTRACT.=

<= u>=C2=A0

O= k.

<= u>=C2=A0

&= gt; It can be and is encoded in a variety of ways.=C2=A0 When encoded

&= gt; according to what a few people believe to be the correct encoding for

&= gt; US V2V deployments,

<= u>=C2=A0

I= hope there is BSM interoperability at least within US V2V deployments.

= =C2=A0 That should me more than just what a few people believe.

<= u>=C2=A0

= =C2=A0 then yes, a wireshark tool programmed to decode=

&= gt; that particular encoding can dissect the contents.=C2=A0 So when the rules

&= gt; are finally set, if the encoding changes, so muist the wireshark=

&= gt; tools if they want to be able to "dissect the BSM".=

<= u>=C2=A0

Y= ou mean the rules are undergoing change?

<= u>=C2=A0

A= lex

<= u>=C2=A0

&= gt;=C2=A0

&= gt; RR

&= gt;=C2=A0

&= gt;=C2=A0

&= gt; Alex

&= gt;=C2=A0

&= gt;>=C2=A0

&= gt;> RR

&= gt;>=C2=A0

&= gt;> -----Original Message----- From: Alexandre Petrescu

&= gt;> [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, May 24, 2016

&= gt;> 5:41 AM To: its@i= etf.org Subject: Re: [its] latest charter text -

&= gt;> title of items "IPv6 over 802.11p"

&= gt;>=C2=A0

&= gt;> Hello ITSers,

&= gt;>=C2=A0

&= gt;> I discussed with people involved in GCDC, yogoko, and open source

&= gt;> of ETSI ITS CAM (github.com/alexvoronov/geonetworking), IEEE<= /u>

&= gt;> 802.11p (github.com/CTU-IIG/802.11p-linux) and SAE BSM at<= /u>

&= gt;> itsforge.net.=

&= gt;>=C2=A0

&= gt;> At this time I believe the title of the work item number 2 should

&= gt;> be:

&= gt;>=C2=A0

&= gt;> "IPv6 over 802.11p" and not "IPv6 over DSRC".

&= gt;>=C2=A0

&= gt;> In this title the "DSRC" term was a source of confusion: - it

&= gt;> means link-layer in some context but app-layer in other, - the

&= gt;> authoritative source of definition of 'DSRC' seems to be SA= E, but

&= gt;> not sure whether it's rather IEEE, or other - not sure where to

&= gt;> look for it.

&= gt;>=C2=A0

&= gt;> On the contrary, '802.11p' is clearly defined as 'Outsi= de the

&= gt;> Context of a BSSID of 802.11' by IEEE.=C2=A0 It always means link-layer

&= gt;> (there are no 802.11p applications - an application runs equally

&= gt;> well on 802.11b as on 802.11p).

&= gt;>=C2=A0

&= gt;> I will modify the title in the work item charter proposal=

&= gt;> accordingly.

&= gt;>=C2=A0

&= gt;> This does not preclude that later we can work on "Transmission of

&= gt;> DSRC messages like BSM over IPv6 over 802.11p".<= /span>

&= gt;>=C2=A0

&= gt;> Alex

&= gt;>=C2=A0

&= gt;> Le 18/05/2016 =C3=A0 09:23, Alexandre Petrescu a =C3=A9crit :

&= gt;>> Well yes, it's a shared medium.=

&= gt;>>=C2=A0

&= gt;>> But "IPv6-over-foo" documents are titled something like:

&= gt;>> "Transmission of IPv6 Packets over Ethernet Networks"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC

&= gt;>> 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks"

&= gt;>> RFC 4944 "Transmission of IPv6 Packets over ITU-T G.9959

&= gt;>> Networks"=C2=A0 RFC 7428

&= gt;>>=C2=A0

&= gt;>> What could DSRC in "IPv6 over DSRC" mean?=C2=A0 The 802.11 OCB link?

&= gt;>> 802.11p?=C2=A0 The set of WAVE WSMP messages?

&= gt;>>=C2=A0

&= gt;>> I am tempted to believe that in this context "DSRC" means

&= gt;>> "802.11 OCB".

&= gt;>>=C2=A0

&= gt;>> Alex

&= gt;>>=C2=A0

&= gt;>>=C2=A0

&= gt;>> Le 18/05/2016 =C3=A0 04:28, Rex Buddenberg a =C3=A9crit :

&= gt;>>> shared medium

&= gt;>>>=C2=A0

&= gt;>>> On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote:

&= gt;>>>> Hello,

&= gt;>>>>=C2=A0

&= gt;>>>>=C2=A0

&= gt;>>>> Le 02/05/2016 =C3=A0 15:48, Alexandre Petrescu a =C3=A9= crit : [...]

&= gt;>>>>>=C2=A0

&= gt;>>>>> 1. Informational RFC "ITS General Problem Area" covering:

&= gt;>>>>> - What is ITS? - Explain V2V, V2I, and related terms - Why

&= gt;>>>>> is IPv6 needed? - Explain why some traffic will not use

&= gt;>>>>> IPv6 - Explain why other traffic will use IPv6 -

&= gt;>>>>> Use-cases, illustrating the expected areas for initial

&= gt;>>>>> focus - Informative references, relationship with other

&= gt;>>>>> SDOs

&= gt;>>>>>=C2=A0

&= gt;>>>>> 2. Standards Track RFC "IPv6 over DSRC"

&= gt;>>>> This particular mentioning of "IPv6 over DSRC"= ; has raised a

&= gt;>>>> number of questions.

&= gt;>>>>=C2=A0

&= gt;>>>> Do you think it is the appropriate title?=

&= gt;>>>>=C2=A0

&= gt;>>>> Alex

&= gt;>>>>=C2=A0

&= gt;>>>>>=C2=A0

&= gt;>>>>>=C2=A0

&= gt;>>>>> 3. Informational RFC "Problem Statement" covering: -

&= gt;>>>>> Problem statement - Security considerations - Privacy

&= gt;>>>>> considerations

&= gt;>>>> _______________________________________________ its mailing

&= gt;>>>> list = its@ietf.org htt= ps://www.ietf.org/mailman/listinfo/its

&= gt;>>>=C2=A0

&= gt;>>=C2=A0

&= gt;>> _______________________________________________ its mailing list

&= gt;>> its@ietf.org<= /a> https://www.ietf.org/mailman/listinfo/its<= /p>

&= gt;>=C2=A0

&= gt;>=C2=A0

&= gt;>=C2=A0

&= gt;>=C2=A0

&= gt;=C2=A0

&= gt;=C2=A0

&= gt;=C2=A0

&= gt;=C2=A0


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




--
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644
--001a113d306af48c6d0533c31d59-- From nobody Thu May 26 13:47:02 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AA012D179 for ; Thu, 26 May 2016 13:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcnsJ2MNIt1F for ; Thu, 26 May 2016 13:46:59 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C332412D148 for ; Thu, 26 May 2016 13:46:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4QKkpmM007980; Thu, 26 May 2016 22:46:51 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8F1CE204FD3; Thu, 26 May 2016 22:47:04 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7FA21201C3E; Thu, 26 May 2016 22:47:04 +0200 (CEST) Received: from [132.166.84.6] ([132.166.84.6]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4QKko5r011399; Thu, 26 May 2016 22:46:50 +0200 To: Dick Roy , dickroy@alum.mit.edu References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> <1463538517.3378.3.camel@gmail.com> <2cc0e36a-0f38-9aa7-128f-c63110bfd510@gmail.com> <6469b110-d0e5-bb89-615e-e8993787908e@gmail.com> <7D2F1744F772491CAF81F9D50BF5A2BC@SRA5> <5a35230a-59df-5c8e-538e-f2fd81d6801c@gmail.com> <624afe60-3d17-3a33-131e-542e71254a93@gmail.com> From: Alexandre Petrescu Message-ID: <566118f7-af87-1a73-4a02-37453ed4883c@gmail.com> Date: Thu, 26 May 2016 22:46:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.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] latest charter text - title of items "IPv6 over 802.11p" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 20:47:02 -0000 Dick, Once again - the relevance of putting a BSM directly on the link-layer, or on a network layer first, is debatable. There are many pro and con arguments for each; you list only the cons for putting BSM on network layer. Let's have that discussion later. For now, I guess you will agree we pursue with putting _something_ on top of IPv6 on top of 802.11p, right? Alex Le 26/05/2016 à 19:13, Dick Roy a écrit : > At present, in the U.S., there are NO rules. NHTSA has yet to “make the > rules”. If all goes according to the current plan in the minds of a few > individuals, then the relevant SAE and IEEE standards that have been > produced over the last 15 years will form the basis of that ruling. > Things could change, including the frequency allocations, between now > and then. Stay tuned … > > > > As for the BSM, it has little to no value outside a VERY LIMITED > geographic and temporal region. No one more than a few hundred meters > from a given vehicle cares where it is, and even if it knew, within a > few tenths of a second, it would be yesterday’s news! There is NO > thought that broadcasting BSMs through networks makes any sense at all. > That DOES NOT mean that logging a few for transmission to a TMC to be > used for traffic management and efficiency applications won’t happen. > But that is NOT an IP broadcast. There is simply NO WAY all (or even a > miniscule fraction thereof) BSMs transmitted are going to end up > traversing IP networks. The network(s) can’t handle all the USELESS > information! > > > > RR > > > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Wednesday, May 25, 2016 11:56 PM > To: dickroy@alum.mit.edu > Cc: its@ietf.org > Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p" > > > > Dick, thanks for the reply. > > > > Le 26/05/2016 à 08:44, Dick Roy a écrit : > >> > >> > >> -----Original Message----- From: Alexandre Petrescu > >> [mailto:alexandre.petrescu@gmail.com] Sent: Wednesday, May 25, 2016 > >> 1:51 AM To: dickroy@alum.mit.edu; its@ietf.org Subject: Re: [its] > >> latest charter text - title of items "IPv6 over 802.11p" > >> > >> Le 25/05/2016 à 00:49, Dick Roy a écrit : > >>> Any mention of messages and/or message types that could or should > >>> or might or can't or whatever be sent using this "new IP > >>> functionality" is out of scope. IPv6 connectivity in highly > >>> transient environments is the goal. Just keep it simple! > >> > >> I fully agree. That's why "DSRC" in the title is not simple at all. > >> > >>> Saying you are going to send BSMs using IPv6 is going to > >>> needlessly ruffle some big feathers! > >> > >> I agree. Sending BSM over IPv6 over 802.11p may be an activity for > >> later, if proven necessary. [RR>] Whether or not it happens has NO > >> bearing on the work this group should be considering. It's a local > >> broadcast, and does not need IPv6 at all. > > > > Well, let us save this discussion for later. There are many aspects > > that need to be mentioned about advantages and inconvenients of a > > network layer-less local broadcast. > > */ /* > >> (BSM stands for "Basic Safety Message" and is defined by the Society > >> of Automotive Engineers in the standard J2735_201603 "DSRC Message > >> Set Dictionary", paying access; a BSM is however dissected by the > >> freely available open source wireshark tool, and some packet captures > >> are freely available open source at > >> http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files > >> > >> > >> > >> [RR>] NB: The BSM is an ASN.1 data object. It's ABSTRACT. > > > > Ok. > > > >> It can be and is encoded in a variety of ways. When encoded > >> according to what a few people believe to be the correct encoding for > >> US V2V deployments, > > > > I hope there is BSM interoperability at least within US V2V deployments. > > That should me more than just what a few people believe. > > > > then yes, a wireshark tool programmed to decode > >> that particular encoding can dissect the contents. So when the rules > >> are finally set, if the encoding changes, so muist the wireshark > >> tools if they want to be able to "dissect the BSM". > > > > You mean the rules are undergoing change? > > > > Alex > > > >> > >> RR > >> > >> > >> Alex > >> > >>> > >>> RR > >>> > >>> -----Original Message----- From: Alexandre Petrescu > >>> [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, May 24, 2016 > >>> 5:41 AM To: its@ietf.org Subject: Re: [its] latest charter text - > >>> title of items "IPv6 over 802.11p" > >>> > >>> Hello ITSers, > >>> > >>> I discussed with people involved in GCDC, yogoko, and open source > >>> of ETSI ITS CAM (github.com/alexvoronov/geonetworking), IEEE > >>> 802.11p (github.com/CTU-IIG/802.11p-linux) and SAE BSM at > >>> itsforge.net. > >>> > >>> At this time I believe the title of the work item number 2 should > >>> be: > >>> > >>> "IPv6 over 802.11p" and not "IPv6 over DSRC". > >>> > >>> In this title the "DSRC" term was a source of confusion: - it > >>> means link-layer in some context but app-layer in other, - the > >>> authoritative source of definition of 'DSRC' seems to be SAE, but > >>> not sure whether it's rather IEEE, or other - not sure where to > >>> look for it. > >>> > >>> On the contrary, '802.11p' is clearly defined as 'Outside the > >>> Context of a BSSID of 802.11' by IEEE. It always means link-layer > >>> (there are no 802.11p applications - an application runs equally > >>> well on 802.11b as on 802.11p). > >>> > >>> I will modify the title in the work item charter proposal > >>> accordingly. > >>> > >>> This does not preclude that later we can work on "Transmission of > >>> DSRC messages like BSM over IPv6 over 802.11p". > >>> > >>> Alex > >>> > >>> Le 18/05/2016 à 09:23, Alexandre Petrescu a écrit : > >>>> Well yes, it's a shared medium. > >>>> > >>>> But "IPv6-over-foo" documents are titled something like: > >>>> "Transmission of IPv6 Packets over Ethernet Networks" RFC > >>>> 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" > >>>> RFC 4944 "Transmission of IPv6 Packets over ITU-T G.9959 > >>>> Networks" RFC 7428 > >>>> > >>>> What could DSRC in "IPv6 over DSRC" mean? The 802.11 OCB link? > >>>> 802.11p? The set of WAVE WSMP messages? > >>>> > >>>> I am tempted to believe that in this context "DSRC" means > >>>> "802.11 OCB". > >>>> > >>>> Alex > >>>> > >>>> > >>>> Le 18/05/2016 à 04:28, Rex Buddenberg a écrit : > >>>>> shared medium > >>>>> > >>>>> On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote: > >>>>>> Hello, > >>>>>> > >>>>>> > >>>>>> Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit : [...] > >>>>>>> > >>>>>>> 1. Informational RFC "ITS General Problem Area" covering: > >>>>>>> - What is ITS? - Explain V2V, V2I, and related terms - Why > >>>>>>> is IPv6 needed? - Explain why some traffic will not use > >>>>>>> IPv6 - Explain why other traffic will use IPv6 - > >>>>>>> Use-cases, illustrating the expected areas for initial > >>>>>>> focus - Informative references, relationship with other > >>>>>>> SDOs > >>>>>>> > >>>>>>> 2. Standards Track RFC "IPv6 over DSRC" > >>>>>> This particular mentioning of "IPv6 over DSRC" has raised a > >>>>>> number of questions. > >>>>>> > >>>>>> Do you think it is the appropriate title? > >>>>>> > >>>>>> Alex > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 3. Informational RFC "Problem Statement" covering: - > >>>>>>> Problem statement - Security considerations - Privacy > >>>>>>> considerations > >>>>>> _______________________________________________ its mailing > >>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its > >>>>> > >>>> > >>>> _______________________________________________ its mailing list > >>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its > >>> > >>> > >>> > >>> > >> > >> > >> > >> > From nobody Thu May 26 17:45:59 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ABB12D5B4 for ; Thu, 26 May 2016 17:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.875 X-Spam-Level: X-Spam-Status: No, score=-3.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzJkA_xMjntA for ; Thu, 26 May 2016 17:45:55 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B3C12B050 for ; Thu, 26 May 2016 17:45:55 -0700 (PDT) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by comcast with SMTP id 65uAbwyQuvJlg65uUbFLOT; Fri, 27 May 2016 00:45:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464309954; bh=O+lTWCW6lA8Zn9Kkm7US9mTQDpCShVIwdaK2924b1Rg=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=TydSbF+neQAzQjlGWam1XWFG37ASoUfaAoldsfzu4oBO1ASuNvckWY2ekAqLuJ7md bbFOIl9p3pDnqTBFBXz8FJH57JbBT9CSo7uXHdSGczagcW1TJNaLA/VvtdOMsohShu VhH+MLwzw0SaqIZ/l+4HFdNb2iDkCu/aAUfbwPyjxMcBS4XCd4Q2+T9YbucUxKAyi0 5z/TKBuiZzj76dQnnDRYr75VL+9gasoVZ9qWKgbeQs3r5DeuOdVSN00UR2MvmPWMPD 9sVjn9JBNBl39wt2OKnA1GAGaviAPwJwH5xeFjGXo+9gITHVgMHBo/yXFyUSupkJih CiA0Sn7vtHHQQ== Received: from SRA5 ([73.231.86.178]) by resomta-po-13v.sys.comcast.net with comcast id zClt1s0023qs29D01CltTi; Fri, 27 May 2016 00:45:54 +0000 From: "Dick Roy" To: "'John Kenney'" References: <571E06FF.9060404@gmail.com><571F6758.4050402@gmail.com><57275AB1.5030308@gmail.com><15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com><1463538517.3378.3.camel@gmail.com><2cc0e36a-0f38-9aa7-128f-c63110bfd510@gmail.com><6469b110-d0e5-bb89-615e-e8993787908e@gmail.com><7D2F1744F772491CAF81F9D50BF5A2BC@SRA5><5a35230a-59df-5c8e-538e-f2fd81d6801c@gmail.com><624afe60-3d17-3a33-131e-542e71254a93@gmail.com> In-Reply-To: Date: Thu, 26 May 2016 17:45:51 -0700 Message-ID: <5DA74713E5D1492F912D442ED26177EC@SRA5> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_030A_01D1B776.7428A620" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AdG3fgGJzUT6UlQ+Ro23PQYDPMlRvAAMc7pw x-mimeole: Produced By Microsoft MimeOLE V10.0.10011.16384 Archived-At: Cc: 'Alexandre Petrescu' , 'Richard Roy' , its@ietf.org Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 00:45:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_030A_01D1B776.7428A620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable While we could debate the word =93deployments=94, nothing John points = out is essentially incorrect (double negatives are beautiful in such circumstances:^))). The problem is there is a very strong lobby that may result in rules being put in place that were not what is currently =93anticipated=94. None of this is particularly relevant to the issue = at hand, however. =20 =20 The real point is that basing a use case on a particular technology = (5.9GHz 802.11p) when it is not necessary to do so is just not a good idea. To describe and justify the IETF=92s effort to =93upgrade IP=94 to handle = rapidly varying network topologies and unreliable links does NOT require mention = of any particular MAC&PHY. There are more than enough to go around, and = the resulting IPv6 functionality will not depend on what frequency band is = being used at the PHY! Add to this the fact that the 5.9GHz band is the most tenuous at present of all the other possible choices, focusing on it is probably the worst choice you could make. The characteristics of the = lower layers (1 and 2) can be described sufficiently well without naming = names, so don=92t name names. =20 RR =20 =20 _____ =20 From: John Kenney [mailto:jkenney@us.toyota-itc.com]=20 Sent: Thursday, May 26, 2016 11:40 AM To: Dick Roy Cc: Alexandre Petrescu; Richard Roy; its@ietf.org Subject: Re: [its] latest charter text - title of items "IPv6 over = 802.11p" =20 I don't disagree with Dick's second paragraph, but I wouldn't want there = to be confusion about the existence of "rules." The auto industry has = worked hard to develop and publish key standards related to the BSM (SAE J2735, = SAE J2945/1), so there will be interoperability. Deployments are moving = ahead in the US based on those standards. =20 Best Regards, John =20 On Thu, May 26, 2016 at 10:13 AM, Dick Roy = wrote: At present, in the U.S., there are NO rules. NHTSA has yet to =93make = the rules=94. If all goes according to the current plan in the minds of a = few individuals, then the relevant SAE and IEEE standards that have been produced over the last 15 years will form the basis of that ruling. = Things could change, including the frequency allocations, between now and then. Stay tuned =85 =20 As for the BSM, it has little to no value outside a VERY LIMITED = geographic and temporal region. No one more than a few hundred meters from a given vehicle cares where it is, and even if it knew, within a few tenths of a second, it would be yesterday=92s news! There is NO thought that = broadcasting BSMs through networks makes any sense at all. That DOES NOT mean that logging a few for transmission to a TMC to be used for traffic = management and efficiency applications won=92t happen. But that is NOT an IP = broadcast. There is simply NO WAY all (or even a miniscule fraction thereof) BSMs transmitted are going to end up traversing IP networks. The network(s) can=92t handle all the USELESS information! =20 RR =20 -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Wednesday, May 25, 2016 11:56 PM To: dickroy@alum.mit.edu Cc: its@ietf.org Subject: Re: [its] latest charter text - title of items "IPv6 over = 802.11p" =20 Dick, thanks for the reply. =20 Le 26/05/2016 =E0 08:44, Dick Roy a =E9crit : >=20 >=20 > -----Original Message----- From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Sent: Wednesday, May 25, 2016 > 1:51 AM To: dickroy@alum.mit.edu; its@ietf.org Subject: Re: [its] > latest charter text - title of items "IPv6 over 802.11p" >=20 > Le 25/05/2016 =E0 00:49, Dick Roy a =E9crit : >> Any mention of messages and/or message types that could or should >> or might or can't or whatever be sent using this "new IP >> functionality" is out of scope. IPv6 connectivity in highly >> transient environments is the goal. Just keep it simple! >=20 > I fully agree. That's why "DSRC" in the title is not simple at all. >=20 >> Saying you are going to send BSMs using IPv6 is going to >> needlessly ruffle some big feathers! >=20 > I agree. Sending BSM over IPv6 over 802.11p may be an activity for > later, if proven necessary. [RR>] Whether or not it happens has NO > bearing on the work this group should be considering. It's a local > broadcast, and does not need IPv6 at all. =20 Well, let us save this discussion for later. There are many aspects that need to be mentioned about advantages and inconvenients of a network layer-less local broadcast. =20 > (BSM stands for "Basic Safety Message" and is defined by the Society > of Automotive Engineers in the standard J2735_201603 "DSRC Message > Set Dictionary", paying access; a BSM is however dissected by the > freely available open source wireshark tool, and some packet captures > are freely available open source at > http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-fi= les >=20 >=20 >=20 > [RR>] NB: The BSM is an ASN.1 data object. It's ABSTRACT. =20 Ok. =20 > It can be and is encoded in a variety of ways. When encoded > according to what a few people believe to be the correct encoding for > US V2V deployments, =20 I hope there is BSM interoperability at least within US V2V deployments. = That should me more than just what a few people believe. =20 then yes, a wireshark tool programmed to decode > that particular encoding can dissect the contents. So when the rules > are finally set, if the encoding changes, so muist the wireshark > tools if they want to be able to "dissect the BSM". =20 You mean the rules are undergoing change? =20 Alex =20 >=20 > RR >=20 >=20 > Alex >=20 >>=20 >> RR >>=20 >> -----Original Message----- From: Alexandre Petrescu >> [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, May 24, 2016 >> 5:41 AM To: its@ietf.org Subject: Re: [its] latest charter text - >> title of items "IPv6 over 802.11p" >>=20 >> Hello ITSers, >>=20 >> I discussed with people involved in GCDC, yogoko, and open source >> of ETSI ITS CAM (github.com/alexvoronov/geonetworking), IEEE >> 802.11p (github.com/CTU-IIG/802.11p-linux) and SAE BSM at >> itsforge.net. >>=20 >> At this time I believe the title of the work item number 2 should >> be: >>=20 >> "IPv6 over 802.11p" and not "IPv6 over DSRC". >>=20 >> In this title the "DSRC" term was a source of confusion: - it >> means link-layer in some context but app-layer in other, - the >> authoritative source of definition of 'DSRC' seems to be SAE, but >> not sure whether it's rather IEEE, or other - not sure where to >> look for it. >>=20 >> On the contrary, '802.11p' is clearly defined as 'Outside the >> Context of a BSSID of 802.11' by IEEE. It always means link-layer >> (there are no 802.11p applications - an application runs equally >> well on 802.11b as on 802.11p). >>=20 >> I will modify the title in the work item charter proposal >> accordingly. >>=20 >> This does not preclude that later we can work on "Transmission of >> DSRC messages like BSM over IPv6 over 802.11p". >>=20 >> Alex >>=20 >> Le 18/05/2016 =E0 09:23, Alexandre Petrescu a =E9crit : >>> Well yes, it's a shared medium. >>>=20 >>> But "IPv6-over-foo" documents are titled something like: >>> "Transmission of IPv6 Packets over Ethernet Networks" RFC >>> 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" >>> RFC 4944 "Transmission of IPv6 Packets over ITU-T G.9959 >>> Networks" RFC 7428 >>>=20 >>> What could DSRC in "IPv6 over DSRC" mean? The 802.11 OCB link? >>> 802.11p? The set of WAVE WSMP messages? >>>=20 >>> I am tempted to believe that in this context "DSRC" means >>> "802.11 OCB". >>>=20 >>> Alex >>>=20 >>>=20 >>> Le 18/05/2016 =E0 04:28, Rex Buddenberg a =E9crit : >>>> shared medium >>>>=20 >>>> On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote: >>>>> Hello, >>>>>=20 >>>>>=20 >>>>> Le 02/05/2016 =E0 15:48, Alexandre Petrescu a =E9crit : [...] >>>>>>=20 >>>>>> 1. Informational RFC "ITS General Problem Area" covering: >>>>>> - What is ITS? - Explain V2V, V2I, and related terms - Why >>>>>> is IPv6 needed? - Explain why some traffic will not use >>>>>> IPv6 - Explain why other traffic will use IPv6 - >>>>>> Use-cases, illustrating the expected areas for initial >>>>>> focus - Informative references, relationship with other >>>>>> SDOs >>>>>>=20 >>>>>> 2. Standards Track RFC "IPv6 over DSRC" >>>>> This particular mentioning of "IPv6 over DSRC" has raised a >>>>> number of questions. >>>>>=20 >>>>> Do you think it is the appropriate title? >>>>>=20 >>>>> Alex >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> 3. Informational RFC "Problem Statement" covering: - >>>>>> Problem statement - Security considerations - Privacy >>>>>> considerations >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>=20 >>>=20 >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its =20 --=20 John Kenney Director and Principal Researcher Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 ------=_NextPart_000_030A_01D1B776.7428A620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

 

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

 

RR=A0 = =A0=A0

 

From: John = Kenney [mailto:jkenney@us.toyota-itc.com]
Sent: Thursday, May 26, = 2016 11:40 AM
To: Dick Roy
Cc: Alexandre Petrescu; = Richard Roy; its@ietf.org
Subject: Re: [its] latest = charter text - title of items "IPv6 over = 802.11p"

 

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

 

Best Regards,

John

 

On Thu, May 26, 2016 at 10:13 AM, Dick Roy <dickroy3777@comcast.net> wrote:

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

 

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

 

RR

 

-----Original Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] =

Sent: Wednesday, May 25, 2016 11:56 PM
To: dickroy@alum.mit.edu
Cc: its@ietf.org
Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p"

 

Dick, thanks for the reply.

 

Le 26/05/2016 =E0 08:44, Dick Roy a =E9crit = :

> 

> 

> -----Original Message----- From: Alexandre = Petrescu

> [mailto:alexandre.petrescu@gmail.com] Sent: Wednesday, May = 25, 2016

> 1:51 AM To: dickroy@alum.mit.edu; its@ietf.org Subject: Re: = [its]

> latest charter text - title of items "IPv6 over 802.11p"

> 

> Le 25/05/2016 =E0 00:49, Dick Roy a =E9crit = :

>> Any mention of messages and/or message types = that could or should

>> or might or can't or whatever be sent using this "new IP

>> functionality" is out of scope.  IPv6 connectivity in highly

>> transient environments is the goal. Just keep it = simple!

> 

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

> 

>> Saying you are going to send BSMs using IPv6 is = going to

>> needlessly ruffle some big = feathers!

> 

> I agree.  Sending BSM over IPv6 over 802.11p = may be an activity for

> later, if proven necessary. [RR>] Whether or not = it happens has NO

> bearing on the work this group should be = considering.  It's a local

> broadcast, and does not need IPv6 at = all.

 

Well, let us save this discussion for later.  There = are many aspects

that need to be mentioned about advantages and = inconvenients of a

network layer-less local = broadcast.

 =

> (BSM stands for "Basic Safety Message" and = is defined by the Society

> of Automotive Engineers in the standard J2735_201603 "DSRC Message

> Set Dictionary", paying access; a BSM is = however dissected by the

> freely available open source wireshark tool, and = some packet captures

> are freely available open source = at

> http://www.itsforge.net/index.php/forum/cv-dsrc-message= -parser/44-test-files

> 

> 

> 

> [RR>] NB: The BSM is an ASN.1 data object. It's ABSTRACT.

 

Ok.

 

> It can be and is encoded in a variety of ways.  = When encoded

> according to what a few people believe to be the = correct encoding for

> US V2V deployments,

 

I hope there is BSM interoperability at least within US = V2V deployments.

  That should me more than just what a few people = believe.

 

  then yes, a wireshark tool programmed to = decode

> that particular encoding can dissect the = contents.  So when the rules

> are finally set, if the encoding changes, so muist = the wireshark

> tools if they want to be able to "dissect the BSM".

 

You mean the rules are undergoing = change?

 

Alex

 

> 

> RR

> 

> 

> Alex

> 

>> 

>> RR

>> 

>> -----Original Message----- From: Alexandre = Petrescu

>> [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, May = 24, 2016

>> 5:41 AM To: its@ietf.org Subject: Re: [its] latest charter = text -

>> title of items "IPv6 over = 802.11p"

>> 

>> Hello ITSers,

>> 

>> I discussed with people involved in GCDC, = yogoko, and open source

>> of ETSI ITS CAM (github.com/alexvoronov/geonetworking), IEEE

>> 802.11p (github.com/CTU-IIG/802.11p-linux) and SAE BSM at

>> itsforge.net.

>> 

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

>> be:

>> 

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

>> 

>> In this title the "DSRC" term was a = source of confusion: - it

>> means link-layer in some context but app-layer = in other, - the

>> authoritative source of definition of 'DSRC' = seems to be SAE, but

>> not sure whether it's rather IEEE, or other - = not sure where to

>> look for it.

>> 

>> On the contrary, '802.11p' is clearly defined as 'Outside the

>> Context of a BSSID of 802.11' by IEEE.  It = always means link-layer

>> (there are no 802.11p applications - an = application runs equally

>> well on 802.11b as on = 802.11p).

>> 

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

>> accordingly.

>> 

>> This does not preclude that later we can work on "Transmission of

>> DSRC messages like BSM over IPv6 over = 802.11p".

>> 

>> Alex

>> 

>> Le 18/05/2016 =E0 09:23, Alexandre Petrescu a = =E9crit :

>>> Well yes, it's a shared = medium.

>>> 

>>> But "IPv6-over-foo" documents are = titled something like:

>>> "Transmission of IPv6 Packets over = Ethernet Networks"      = RFC

>>> 2464 "Transmission of IPv6 Packets over = IEEE 802.15.4 Networks"

>>> RFC 4944 "Transmission of IPv6 Packets = over ITU-T G.9959

>>> Networks"  RFC = 7428

>>> 

>>> What could DSRC in "IPv6 over = DSRC" mean?  The 802.11 OCB link?

>>> 802.11p?  The set of WAVE WSMP = messages?

>>> 

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

>>> "802.11 = OCB".

>>> 

>>> Alex

>>> 

>>> 

>>> Le 18/05/2016 =E0 04:28, Rex Buddenberg a = =E9crit :

>>>> shared = medium

>>>> 

>>>> On Tue, 2016-05-17 at 16:31 +0200, = Alexandre Petrescu wrote:

>>>>> Hello,

>>>>> 

>>>>> 

>>>>> Le 02/05/2016 =E0 15:48, Alexandre = Petrescu a =E9crit : [...]

>>>>>> 

>>>>>> 1. Informational RFC "ITS = General Problem Area" covering:

>>>>>> - What is ITS? - Explain V2V, = V2I, and related terms - Why

>>>>>> is IPv6 needed? - Explain why = some traffic will not use

>>>>>> IPv6 - Explain why other traffic = will use IPv6 -

>>>>>> Use-cases, illustrating the = expected areas for initial

>>>>>> focus - Informative references, relationship with other

>>>>>> = SDOs

>>>>>> 

>>>>>> 2. Standards Track RFC = "IPv6 over DSRC"

>>>>> This particular mentioning of = "IPv6 over DSRC" has raised a

>>>>> number of = questions.

>>>>> 

>>>>> Do you think it is the appropriate = title?

>>>>> 

>>>>> Alex

>>>>> 

>>>>>> 

>>>>>> 

>>>>>> 3. Informational RFC = "Problem Statement" covering: -

>>>>>> Problem statement - Security considerations - Privacy

>>>>>> = considerations

>>>>> _______________________________________________ its = mailing

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

>>>> 

>>> 

>>> = _______________________________________________ its mailing list

>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its

>> 

>> 

>> 

>> 

> 

> 

> 

> 


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



 

--

John Kenney

Director and Principal Researcher

Toyota = InfoTechnology Center, USA

465 Bernardo = Avenue

Mountain = View, CA 94043

Tel: 650-694-4160. Mobile: 650-224-6644

------=_NextPart_000_030A_01D1B776.7428A620-- From nobody Thu May 26 21:10:59 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ABD12D59B for ; Thu, 26 May 2016 21:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fischer-tech.eu 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 jJmbvQCdN-UB for ; Thu, 26 May 2016 21:10:52 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28AAB12D54F for ; Thu, 26 May 2016 21:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1464322249; l=61520; s=domk; d=fischer-tech.eu; h=Content-Type:In-Reply-To:MIME-Version:Date:From:Cc:References:To: Subject; bh=AMpDGCsmnfAWpIiEr1Sc0IhwXGqUu8v+eiDCwhMIrAI=; b=O/WoJXqrPLwFuEiBdteBn0BM8s6bejNuMKzw+UumpDhpqz49Br1ayIrth3kxUqt+mfA NzWAl+ZNDbWeLmTyTXBL0YxP51kiZSryV6WDmPHp9d8n8kvd2j1CHQCLMw1jAXaLS3jfh Nxvuav3yrIRl7TBgL4Td6FMm+3QJr1m601M= X-RZG-AUTH: :JGYCfFOrc/o0m7eTcArWz0wjmOawaLakL8gsnQV23mJctoKb1FltCfvwAqRXXtvj0s4FYjSh X-RZG-CLASS-ID: mo00 Received: from [192.168.222.100] (p549C9834.dip0.t-ipconnect.de [84.156.152.52]) by smtp.strato.de (RZmta 37.28 DYNA|AUTH) with ESMTPSA id e00216s4R4Af3SR (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Fri, 27 May 2016 06:10:41 +0200 (CEST) To: Dick Roy , 'John Kenney' References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> <1463538517.3378.3.camel@gmail.com> <2cc0e36a-0f38-9aa7-128f-c63110bfd510@gmail.com> <6469b110-d0e5-bb89-615e-e8993787908e@gmail.com> <7D2F1744F772491CAF81F9D50BF5A2BC@SRA5> <5a35230a-59df-5c8e-538e-f2fd81d6801c@gmail.com> <624afe60-3d17-3a33-131e-542e71254a93@gmail.com> <5DA74713E5D1492F912D442ED26177EC@SRA5> From: "Dr. Hans-Joachim Fischer" Organization: ESF GmbH Message-ID: Date: Fri, 27 May 2016 06:10:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5DA74713E5D1492F912D442ED26177EC@SRA5> Content-Type: multipart/alternative; boundary="------------4772DC7F2B2162B3CE96806A" Archived-At: Cc: 'Alexandre Petrescu' , 'Richard Roy' , its@ietf.org Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 04:10:57 -0000 This is a multi-part message in MIME format. --------------4772DC7F2B2162B3CE96806A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dick is right. Mentioning a specific access technology would be a "one way street with dead end". Presenting now new "rules" and new "appraoches" competing with what SAE / IEEE has developed can only aim on stopping the NHTSA project - I wonder whether IETF is interested in this? Hans-Joachim Am 27.05.2016 um 02:45 schrieb Dick Roy: > > While we could debate the word “deployments”, nothing John points out > is essentially incorrect (double negatives are beautiful in such > circumstances:^))). The problem is there is a very strong lobby that > may result in rules being put in place that were not what is currently > “anticipated”. None of this is particularly relevant to the issue at > hand, however. > > The real point is that basing a use case on a particular technology > (5.9GHz 802.11p) when it is not necessary to do so is just not a good > idea. To describe and justify the IETF’s effort to “upgrade IP” to > handle rapidly varying network topologies and unreliable links does > NOT require mention of any particular MAC&PHY. There are more than > enough to go around, and the resulting IPv6 functionality will not > depend on what frequency band is being used at the PHY! Add to this > the fact that the 5.9GHz band is the most tenuous at present of all > the other possible choices, focusing on it is probably the worst > choice you could make. The characteristics of the lower layers (1 and > 2) can be described sufficiently well without naming names, so don’t > name names. > > RR > > ------------------------------------------------------------------------ > > *From:*John Kenney [mailto:jkenney@us.toyota-itc.com] > *Sent:* Thursday, May 26, 2016 11:40 AM > *To:* Dick Roy > *Cc:* Alexandre Petrescu; Richard Roy; its@ietf.org > *Subject:* Re: [its] latest charter text - title of items "IPv6 over > 802.11p" > > I don't disagree with Dick's second paragraph, but I wouldn't want > there to be confusion about the existence of "rules." The auto > industry has worked hard to develop and publish key standards related > to the BSM (SAE J2735, SAE J2945/1), so there will be > interoperability. Deployments are moving ahead in the US based on > those standards. > > Best Regards, > > John > > On Thu, May 26, 2016 at 10:13 AM, Dick Roy > wrote: > > At present, in the U.S., there are NO rules. NHTSA has yet to “make > the rules”. If all goes according to the current plan in the minds of > a few individuals, then the relevant SAE and IEEE standards that have > been produced over the last 15 years will form the basis of that > ruling. Things could change, including the frequency allocations, > between now and then. Stay tuned … > > As for the BSM, it has little to no value outside a VERY LIMITED > geographic and temporal region. No one more than a few hundred meters > from a given vehicle cares where it is, and even if it knew, within a > few tenths of a second, it would be yesterday’s news! There is NO > thought that broadcasting BSMs through networks makes any sense at > all. That DOES NOT mean that logging a few for transmission to a TMC > to be used for traffic management and efficiency applications won’t > happen. But that is NOT an IP broadcast. There is simply NO WAY all > (or even a miniscule fraction thereof) BSMs transmitted are going to > end up traversing IP networks. The network(s) can’t handle all the > USELESS information! > > RR > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com > ] > > Sent: Wednesday, May 25, 2016 11:56 PM > To: dickroy@alum.mit.edu > Cc: its@ietf.org > Subject: Re: [its] latest charter text - title of items "IPv6 over > 802.11p" > > Dick, thanks for the reply. > > Le 26/05/2016 à 08:44, Dick Roy a écrit : > > > > > > > > > -----Original Message----- From: Alexandre Petrescu > > > [mailto:alexandre.petrescu@gmail.com > ] Sent: Wednesday, May 25, 2016 > > > 1:51 AM To: dickroy@alum.mit.edu ; > its@ietf.org Subject: Re: [its] > > > latest charter text - title of items "IPv6 over 802.11p" > > > > > > Le 25/05/2016 à 00:49, Dick Roy a écrit : > > >> Any mention of messages and/or message types that could or should > > >> or might or can't or whatever be sent using this "new IP > > >> functionality" is out of scope. IPv6 connectivity in highly > > >> transient environments is the goal. Just keep it simple! > > > > > > I fully agree. That's why "DSRC" in the title is not simple at all. > > > > > >> Saying you are going to send BSMs using IPv6 is going to > > >> needlessly ruffle some big feathers! > > > > > > I agree. Sending BSM over IPv6 over 802.11p may be an activity for > > > later, if proven necessary. [RR>] Whether or not it happens has NO > > > bearing on the work this group should be considering. It's a local > > > broadcast, and does not need IPv6 at all. > > Well, let us save this discussion for later. There are many aspects > > that need to be mentioned about advantages and inconvenients of a > > network layer-less local broadcast. > > *//* > > > (BSM stands for "Basic Safety Message" and is defined by the Society > > > of Automotive Engineers in the standard J2735_201603 "DSRC Message > > > Set Dictionary", paying access; a BSM is however dissected by the > > > freely available open source wireshark tool, and some packet captures > > > are freely available open source at > > >http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files > > > > > > > > > > > > [RR>] NB: The BSM is an ASN.1 data object. It's ABSTRACT. > > Ok. > > > It can be and is encoded in a variety of ways. When encoded > > > according to what a few people believe to be the correct encoding for > > >US V2V deployments, > > I hope there is BSM interoperability at least within US V2V deployments. > > That should me more than just what a few people believe. > > then yes, a wireshark tool programmed to decode > > > that particular encoding can dissect the contents. So when the rules > > > are finally set, if the encoding changes, so muist the wireshark > > > tools if they want to be able to "dissect the BSM". > > You mean the rules are undergoing change? > > Alex > > > > > > RR > > > > > > > > > Alex > > > > > >> > > >> RR > > >> > > >> -----Original Message----- From: Alexandre Petrescu > > >> [mailto:alexandre.petrescu@gmail.com > ] Sent: Tuesday, May 24, 2016 > > >> 5:41 AM To: its@ietf.org Subject: Re: [its] > latest charter text - > > >> title of items "IPv6 over 802.11p" > > >> > > >> Hello ITSers, > > >> > > >> I discussed with people involved in GCDC, yogoko, and open source > > >> of ETSI ITS CAM (github.com/alexvoronov/geonetworking > ), IEEE > > >> 802.11p (github.com/CTU-IIG/802.11p-linux > ) and SAE BSM at > > >> itsforge.net . > > >> > > >> At this time I believe the title of the work item number 2 should > > >> be: > > >> > > >> "IPv6 over 802.11p" and not "IPv6 over DSRC". > > >> > > >> In this title the "DSRC" term was a source of confusion: - it > > >> means link-layer in some context but app-layer in other, - the > > >> authoritative source of definition of 'DSRC' seems to be SAE, but > > >> not sure whether it's rather IEEE, or other - not sure where to > > >> look for it. > > >> > > >> On the contrary, '802.11p' is clearly defined as 'Outside the > > >> Context of a BSSID of 802.11' by IEEE. It always means link-layer > > >> (there are no 802.11p applications - an application runs equally > > >> well on 802.11b as on 802.11p). > > >> > > >> I will modify the title in the work item charter proposal > > >> accordingly. > > >> > > >> This does not preclude that later we can work on "Transmission of > > >> DSRC messages like BSM over IPv6 over 802.11p". > > >> > > >> Alex > > >> > > >> Le 18/05/2016 à 09:23, Alexandre Petrescu a écrit : > > >>> Well yes, it's a shared medium. > > >>> > > >>> But "IPv6-over-foo" documents are titled something like: > > >>> "Transmission of IPv6 Packets over Ethernet Networks" RFC > > >>> 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" > > >>> RFC 4944 "Transmission of IPv6 Packets over ITU-T G.9959 > > >>> Networks" RFC 7428 > > >>> > > >>> What could DSRC in "IPv6 over DSRC" mean? The 802.11 OCB link? > > >>> 802.11p? The set of WAVE WSMP messages? > > >>> > > >>> I am tempted to believe that in this context "DSRC" means > > >>> "802.11 OCB". > > >>> > > >>> Alex > > >>> > > >>> > > >>> Le 18/05/2016 à 04:28, Rex Buddenberg a écrit : > > >>>> shared medium > > >>>> > > >>>> On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote: > > >>>>> Hello, > > >>>>> > > >>>>> > > >>>>> Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit : [...] > > >>>>>> > > >>>>>> 1. Informational RFC "ITS General Problem Area" covering: > > >>>>>> - What is ITS? - Explain V2V, V2I, and related terms - Why > > >>>>>> is IPv6 needed? - Explain why some traffic will not use > > >>>>>> IPv6 - Explain why other traffic will use IPv6 - > > >>>>>> Use-cases, illustrating the expected areas for initial > > >>>>>> focus - Informative references, relationship with other > > >>>>>> SDOs > > >>>>>> > > >>>>>> 2. Standards Track RFC "IPv6 over DSRC" > > >>>>> This particular mentioning of "IPv6 over DSRC" has raised a > > >>>>> number of questions. > > >>>>> > > >>>>> Do you think it is the appropriate title? > > >>>>> > > >>>>> Alex > > >>>>> > > >>>>>> > > >>>>>> > > >>>>>> 3. Informational RFC "Problem Statement" covering: - > > >>>>>> Problem statement - Security considerations - Privacy > > >>>>>> considerations > > >>>>> _______________________________________________ its mailing > > >>>>> list its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > >>>> > > >>> > > >>> _______________________________________________ its mailing list > > >>> its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > -- > > John Kenney > > Director and Principal Researcher > > Toyota InfoTechnology Center, USA > > 465 Bernardo Avenue > > Mountain View, CA 94043 > > Tel: 650-694-4160. Mobile: 650-224-6644 > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its -- Dr. Hans-Joachim Fischer Managing Director ------------------------------------------------------------------------------- ESF News edition 2016/1 http://fischer-tech.eu/Feeds/News/ESF-News-2016-01.pdf ------------------------------------------------------------------------------- + + + Instaurare omnia in Christo + + + ------------------------------------------------------------------------------- The information contained in this message is confidential and may be legally privileged. This email is intended for the addressee(s). Addressees may be individual persons or members of mailing list. If you are not an addressee, you are hereby notified that any use, dissemination, or reproduction of this email and its optional attachements is strictly prohibited and may be unlawful. If you are not an addressee, please contact the sender by return e-mail and destroy all copies of the original message. ------------------------------------------------------------------------------- ESF GmbH Fichtenweg 9 89143 Blaubeuren +49 (7344) 175340 (Direct line) +49 (7344) 919188 (Central office) +49 (7344) 919123 (Fax) http://fischer-tech.eu : Main web of ESF GmbH http://its-standards.eu : News on cooperative ITS standardization http://its-testing.org : International consultancy for cooperative ITS ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- ESF online-news: http://fischer-tech.eu/Feeds/esf.rss C-ITS online news: http://its-standards.info/Feeds/cits.rss ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss ------------------------------------------------------------------------------- --------------4772DC7F2B2162B3CE96806A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit


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

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


Hans-Joachim


Am 27.05.2016 um 02:45 schrieb Dick Roy:

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

 

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

 

RR    

 

From: John Kenney [mailto:jkenney@us.toyota-itc.com]
Sent: Thursday, May 26, 2016 11:40 AM
To: Dick Roy
Cc: Alexandre Petrescu; Richard Roy; its@ietf.org
Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p"

 

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

 

Best Regards,

John

 

On Thu, May 26, 2016 at 10:13 AM, Dick Roy <dickroy3777@comcast.net> wrote:

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

 

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

 

RR

 

-----Original Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]

Sent: Wednesday, May 25, 2016 11:56 PM
To: dickroy@alum.mit.edu
Cc: its@ietf.org
Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p"

 

Dick, thanks for the reply.

 

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

> 

> 

> -----Original Message----- From: Alexandre Petrescu

> [mailto:alexandre.petrescu@gmail.com] Sent: Wednesday, May 25, 2016

> 1:51 AM To: dickroy@alum.mit.edu; its@ietf.org Subject: Re: [its]

> latest charter text - title of items "IPv6 over 802.11p"

> 

> Le 25/05/2016 à 00:49, Dick Roy a écrit :

>> Any mention of messages and/or message types that could or should

>> or might or can't or whatever be sent using this "new IP

>> functionality" is out of scope.  IPv6 connectivity in highly

>> transient environments is the goal. Just keep it simple!

> 

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

> 

>> Saying you are going to send BSMs using IPv6 is going to

>> needlessly ruffle some big feathers!

> 

> I agree.  Sending BSM over IPv6 over 802.11p may be an activity for

> later, if proven necessary. [RR>] Whether or not it happens has NO

> bearing on the work this group should be considering.  It's a local

> broadcast, and does not need IPv6 at all.

 

Well, let us save this discussion for later.  There are many aspects

that need to be mentioned about advantages and inconvenients of a

network layer-less local broadcast.

 

> (BSM stands for "Basic Safety Message" and is defined by the Society

> of Automotive Engineers in the standard J2735_201603 "DSRC Message

> Set Dictionary", paying access; a BSM is however dissected by the

> freely available open source wireshark tool, and some packet captures

> are freely available open source at

> http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files

> 

> 

> 

> [RR>] NB: The BSM is an ASN.1 data object. It's ABSTRACT.

 

Ok.

 

> It can be and is encoded in a variety of ways.  When encoded

> according to what a few people believe to be the correct encoding for

> US V2V deployments,

 

I hope there is BSM interoperability at least within US V2V deployments.

  That should me more than just what a few people believe.

 

  then yes, a wireshark tool programmed to decode

> that particular encoding can dissect the contents.  So when the rules

> are finally set, if the encoding changes, so muist the wireshark

> tools if they want to be able to "dissect the BSM".

 

You mean the rules are undergoing change?

 

Alex

 

> 

> RR

> 

> 

> Alex

> 

>> 

>> RR

>> 

>> -----Original Message----- From: Alexandre Petrescu

>> [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, May 24, 2016

>> 5:41 AM To: its@ietf.org Subject: Re: [its] latest charter text -

>> title of items "IPv6 over 802.11p"

>> 

>> Hello ITSers,

>> 

>> I discussed with people involved in GCDC, yogoko, and open source

>> of ETSI ITS CAM (github.com/alexvoronov/geonetworking), IEEE

>> 802.11p (github.com/CTU-IIG/802.11p-linux) and SAE BSM at

>> itsforge.net.

>> 

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

>> be:

>> 

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

>> 

>> In this title the "DSRC" term was a source of confusion: - it

>> means link-layer in some context but app-layer in other, - the

>> authoritative source of definition of 'DSRC' seems to be SAE, but

>> not sure whether it's rather IEEE, or other - not sure where to

>> look for it.

>> 

>> On the contrary, '802.11p' is clearly defined as 'Outside the

>> Context of a BSSID of 802.11' by IEEE.  It always means link-layer

>> (there are no 802.11p applications - an application runs equally

>> well on 802.11b as on 802.11p).

>> 

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

>> accordingly.

>> 

>> This does not preclude that later we can work on "Transmission of

>> DSRC messages like BSM over IPv6 over 802.11p".

>> 

>> Alex

>> 

>> Le 18/05/2016 à 09:23, Alexandre Petrescu a écrit :

>>> Well yes, it's a shared medium.

>>> 

>>> But "IPv6-over-foo" documents are titled something like:

>>> "Transmission of IPv6 Packets over Ethernet Networks"      RFC

>>> 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks"

>>> RFC 4944 "Transmission of IPv6 Packets over ITU-T G.9959

>>> Networks"  RFC 7428

>>> 

>>> What could DSRC in "IPv6 over DSRC" mean?  The 802.11 OCB link?

>>> 802.11p?  The set of WAVE WSMP messages?

>>> 

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

>>> "802.11 OCB".

>>> 

>>> Alex

>>> 

>>> 

>>> Le 18/05/2016 à 04:28, Rex Buddenberg a écrit :

>>>> shared medium

>>>> 

>>>> On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote:

>>>>> Hello,

>>>>> 

>>>>> 

>>>>> Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit : [...]

>>>>>> 

>>>>>> 1. Informational RFC "ITS General Problem Area" covering:

>>>>>> - What is ITS? - Explain V2V, V2I, and related terms - Why

>>>>>> is IPv6 needed? - Explain why some traffic will not use

>>>>>> IPv6 - Explain why other traffic will use IPv6 -

>>>>>> Use-cases, illustrating the expected areas for initial

>>>>>> focus - Informative references, relationship with other

>>>>>> SDOs

>>>>>> 

>>>>>> 2. Standards Track RFC "IPv6 over DSRC"

>>>>> This particular mentioning of "IPv6 over DSRC" has raised a

>>>>> number of questions.

>>>>> 

>>>>> Do you think it is the appropriate title?

>>>>> 

>>>>> Alex

>>>>> 

>>>>>> 

>>>>>> 

>>>>>> 3. Informational RFC "Problem Statement" covering: -

>>>>>> Problem statement - Security considerations - Privacy

>>>>>> considerations

>>>>> _______________________________________________ its mailing

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

>>>> 

>>> 

>>> _______________________________________________ its mailing list

>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its

>> 

>> 

>> 

>> 

> 

> 

> 

> 


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



 

--

John Kenney

Director and Principal Researcher

Toyota InfoTechnology Center, USA

465 Bernardo Avenue

Mountain View, CA 94043

Tel: 650-694-4160. Mobile: 650-224-6644



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


-- 
Dr. Hans-Joachim Fischer
Managing Director


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

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

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

------------------------------------------------------------------------------- 
ESF online-news:    http://fischer-tech.eu/Feeds/esf.rss
C-ITS online news:  http://its-standards.info/Feeds/cits.rss
ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss
-------------------------------------------------------------------------------
--------------4772DC7F2B2162B3CE96806A-- From nobody Fri May 27 00:43:37 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D182F12B059 for ; Fri, 27 May 2016 00:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0xRbQO20jps for ; Fri, 27 May 2016 00:43:32 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2722F12D0A0 for ; Fri, 27 May 2016 00:43:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4R7hOLv019391; Fri, 27 May 2016 09:43:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 81C6C20529A; Fri, 27 May 2016 09:43:37 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6D7F0201D1C; Fri, 27 May 2016 09:43:37 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4R7hNrB028400; Fri, 27 May 2016 09:43:23 +0200 To: "Dr. Hans-Joachim Fischer" , Dick Roy , "'John Kenney'" References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> <1463538517.3378.3.camel@gmail.com> <2cc0e36a-0f38-9aa7-128f-c63110bfd510@gmail.com> <6469b110-d0e5-bb89-615e-e8993787908e@gmail.com> <7D2F1744F772491CAF81F9D50BF5A2BC@SRA5> <5a35230a-59df-5c8e-538e-f2fd81d6801c@gmail.com> <624afe60-3d17-3a33-131e-542e71254a93@gmail.com> <5DA74713E5D1492F912D442ED26177EC@SRA5> From: Alexandre Petrescu Message-ID: <03285857-9d64-72c9-abe4-7cb16d22e210@gmail.com> Date: Fri, 27 May 2016 09:43:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Richard Roy' , its@ietf.org Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 07:43:36 -0000 Hans-Joachim, Thanks for the message. Generally speaking, the politics I see at IETF is at Layer8, well beyond "rough consensus and running code". NHTSA: I still have to see somebody from NHTSA here or meet at IETF, or in the virtual meeting... For the mentioning of access technology: there are clearly two directions of thought: 1. the IPv6-over-foo documents help in keeping the IP layer dire (unmodified, see the well-known IETF/Steve Deering hourglass model); in that sense yes, IPv6-over-80211p will help keep IPv6 unmodified, and thus not lead to that dead end you mention. 2. an "upgraded" IPv6 layer dedicated to highly dynamic link layers; this is something that an IPv6-over-dynamiclinklayer document could do. One could free one's imagination in so "upgrading" the IPv6 layer (add header compression, new identifiers, congestion control, etc.) IMHO this leads to a dead end in that there can not be enough people agreeing to "upgrade IP", nor about the features to include. It is also a domain typically of MANET WG, not here. In the charter text I propose an aggressive schedule for this "IPv6 over foo" WG item: delivery to the WG by December 2016. This assumes until then there should be multiple personal I-Ds published... If we follow that timeline, there is obviously no time to propose anything along the lines of 'upgrading' an IP layer. I can not not add, again for information, that a typical "IPv6-over-foo" document at IETF is like RFC 2464 "IPv6 over Ethernet". There are many such IPv6-over-foo RFCs; these RFCs are very much mirroring each other. We can discuss separately about what is an "IPv6 over foo" document. Alex Le 27/05/2016 à 06:10, Dr. Hans-Joachim Fischer a écrit : > > Dick is right. Mentioning a specific access technology would be a "one > way street with dead end". > > Presenting now new "rules" and new "appraoches" competing with what SAE > / IEEE has developed can only aim on stopping the NHTSA project - I > wonder whether IETF is interested in this? > > > Hans-Joachim > > > Am 27.05.2016 um 02:45 schrieb Dick Roy: >> >> While we could debate the word “deployments”, nothing John points out >> is essentially incorrect (double negatives are beautiful in such >> circumstances:^))). The problem is there is a very strong lobby that >> may result in rules being put in place that were not what is currently >> “anticipated”. None of this is particularly relevant to the issue at >> hand, however. >> >> >> >> The real point is that basing a use case on a particular technology >> (5.9GHz 802.11p) when it is not necessary to do so is just not a good >> idea. To describe and justify the IETF’s effort to “upgrade IP” to >> handle rapidly varying network topologies and unreliable links does >> NOT require mention of any particular MAC&PHY. There are more than >> enough to go around, and the resulting IPv6 functionality will not >> depend on what frequency band is being used at the PHY! Add to this >> the fact that the 5.9GHz band is the most tenuous at present of all >> the other possible choices, focusing on it is probably the worst >> choice you could make. The characteristics of the lower layers (1 and >> 2) can be described sufficiently well without naming names, so don’t >> name names. >> >> >> >> RR >> >> >> >> ------------------------------------------------------------------------ >> >> *From:*John Kenney [mailto:jkenney@us.toyota-itc.com] >> *Sent:* Thursday, May 26, 2016 11:40 AM >> *To:* Dick Roy >> *Cc:* Alexandre Petrescu; Richard Roy; its@ietf.org >> *Subject:* Re: [its] latest charter text - title of items "IPv6 over >> 802.11p" >> >> >> >> I don't disagree with Dick's second paragraph, but I wouldn't want >> there to be confusion about the existence of "rules." The auto >> industry has worked hard to develop and publish key standards related >> to the BSM (SAE J2735, SAE J2945/1), so there will be >> interoperability. Deployments are moving ahead in the US based on >> those standards. >> >> >> >> Best Regards, >> >> John >> >> >> >> On Thu, May 26, 2016 at 10:13 AM, Dick Roy >> <dickroy3777@comcast.net> wrote: >> >> At present, in the U.S., there are NO rules. NHTSA has yet to “make >> the rules”. If all goes according to the current plan in the minds of >> a few individuals, then the relevant SAE and IEEE standards that have >> been produced over the last 15 years will form the basis of that >> ruling. Things could change, including the frequency allocations, >> between now and then. Stay tuned … >> >> >> >> As for the BSM, it has little to no value outside a VERY LIMITED >> geographic and temporal region. No one more than a few hundred meters >> from a given vehicle cares where it is, and even if it knew, within a >> few tenths of a second, it would be yesterday’s news! There is NO >> thought that broadcasting BSMs through networks makes any sense at >> all. That DOES NOT mean that logging a few for transmission to a TMC >> to be used for traffic management and efficiency applications won’t >> happen. But that is NOT an IP broadcast. There is simply NO WAY all >> (or even a miniscule fraction thereof) BSMs transmitted are going to >> end up traversing IP networks. The network(s) can’t handle all the >> USELESS information! >> >> >> >> RR >> >> >> >> -----Original Message----- >> From: Alexandre Petrescu >> [mailto:alexandre.petrescu@gmail.com] >> >> >> Sent: Wednesday, May 25, 2016 11:56 PM >> To: dickroy@alum.mit.edu >> Cc: its@ietf.org >> Subject: Re: [its] latest charter text - title of items "IPv6 over >> 802.11p" >> >> >> >> Dick, thanks for the reply. >> >> >> >> Le 26/05/2016 à 08:44, Dick Roy a écrit : >> >> > >> >> > >> >> > -----Original Message----- From: Alexandre Petrescu >> >> > [mailto:alexandre.petrescu@gmail.com] Sent: Wednesday, May 25, 2016 >> >> > 1:51 AM To: dickroy@alum.mit.edu; >> its@ietf.org Subject: Re: [its] >> >> > latest charter text - title of items "IPv6 over 802.11p" >> >> > >> >> > Le 25/05/2016 à 00:49, Dick Roy a écrit : >> >> >> Any mention of messages and/or message types that could or should >> >> >> or might or can't or whatever be sent using this "new IP >> >> >> functionality" is out of scope. IPv6 connectivity in highly >> >> >> transient environments is the goal. Just keep it simple! >> >> > >> >> > I fully agree. That's why "DSRC" in the title is not simple at all. >> >> > >> >> >> Saying you are going to send BSMs using IPv6 is going to >> >> >> needlessly ruffle some big feathers! >> >> > >> >> > I agree. Sending BSM over IPv6 over 802.11p may be an activity for >> >> > later, if proven necessary. [RR>] Whether or not it happens has NO >> >> > bearing on the work this group should be considering. It's a local >> >> > broadcast, and does not need IPv6 at all. >> >> >> >> Well, let us save this discussion for later. There are many aspects >> >> that need to be mentioned about advantages and inconvenients of a >> >> network layer-less local broadcast. >> >> */ /* >> >> > (BSM stands for "Basic Safety Message" and is defined by the Society >> >> > of Automotive Engineers in the standard J2735_201603 "DSRC Message >> >> > Set Dictionary", paying access; a BSM is however dissected by the >> >> > freely available open source wireshark tool, and some packet captures >> >> > are freely available open source at >> >> > http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files >> >> > >> >> > >> >> > >> >> > [RR>] NB: The BSM is an ASN.1 data object. It's ABSTRACT. >> >> >> >> Ok. >> >> >> >> > It can be and is encoded in a variety of ways. When encoded >> >> > according to what a few people believe to be the correct encoding for >> >> > US V2V deployments, >> >> >> >> I hope there is BSM interoperability at least within US V2V deployments. >> >> That should me more than just what a few people believe. >> >> >> >> then yes, a wireshark tool programmed to decode >> >> > that particular encoding can dissect the contents. So when the rules >> >> > are finally set, if the encoding changes, so muist the wireshark >> >> > tools if they want to be able to "dissect the BSM". >> >> >> >> You mean the rules are undergoing change? >> >> >> >> Alex >> >> >> >> > >> >> > RR >> >> > >> >> > >> >> > Alex >> >> > >> >> >> >> >> >> RR >> >> >> >> >> >> -----Original Message----- From: Alexandre Petrescu >> >> >> [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, May 24, 2016 >> >> >> 5:41 AM To: its@ietf.org Subject: Re: [its] >> latest charter text - >> >> >> title of items "IPv6 over 802.11p" >> >> >> >> >> >> Hello ITSers, >> >> >> >> >> >> I discussed with people involved in GCDC, yogoko, and open source >> >> >> of ETSI ITS CAM (github.com/alexvoronov/geonetworking >> ), IEEE >> >> >> 802.11p (github.com/CTU-IIG/802.11p-linux >> ) and SAE BSM at >> >> >> itsforge.net . >> >> >> >> >> >> At this time I believe the title of the work item number 2 should >> >> >> be: >> >> >> >> >> >> "IPv6 over 802.11p" and not "IPv6 over DSRC". >> >> >> >> >> >> In this title the "DSRC" term was a source of confusion: - it >> >> >> means link-layer in some context but app-layer in other, - the >> >> >> authoritative source of definition of 'DSRC' seems to be SAE, but >> >> >> not sure whether it's rather IEEE, or other - not sure where to >> >> >> look for it. >> >> >> >> >> >> On the contrary, '802.11p' is clearly defined as 'Outside the >> >> >> Context of a BSSID of 802.11' by IEEE. It always means link-layer >> >> >> (there are no 802.11p applications - an application runs equally >> >> >> well on 802.11b as on 802.11p). >> >> >> >> >> >> I will modify the title in the work item charter proposal >> >> >> accordingly. >> >> >> >> >> >> This does not preclude that later we can work on "Transmission of >> >> >> DSRC messages like BSM over IPv6 over 802.11p". >> >> >> >> >> >> Alex >> >> >> >> >> >> Le 18/05/2016 à 09:23, Alexandre Petrescu a écrit : >> >> >>> Well yes, it's a shared medium. >> >> >>> >> >> >>> But "IPv6-over-foo" documents are titled something like: >> >> >>> "Transmission of IPv6 Packets over Ethernet Networks" RFC >> >> >>> 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" >> >> >>> RFC 4944 "Transmission of IPv6 Packets over ITU-T G.9959 >> >> >>> Networks" RFC 7428 >> >> >>> >> >> >>> What could DSRC in "IPv6 over DSRC" mean? The 802.11 OCB link? >> >> >>> 802.11p? The set of WAVE WSMP messages? >> >> >>> >> >> >>> I am tempted to believe that in this context "DSRC" means >> >> >>> "802.11 OCB". >> >> >>> >> >> >>> Alex >> >> >>> >> >> >>> >> >> >>> Le 18/05/2016 à 04:28, Rex Buddenberg a écrit : >> >> >>>> shared medium >> >> >>>> >> >> >>>> On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote: >> >> >>>>> Hello, >> >> >>>>> >> >> >>>>> >> >> >>>>> Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit : [...] >> >> >>>>>> >> >> >>>>>> 1. Informational RFC "ITS General Problem Area" covering: >> >> >>>>>> - What is ITS? - Explain V2V, V2I, and related terms - Why >> >> >>>>>> is IPv6 needed? - Explain why some traffic will not use >> >> >>>>>> IPv6 - Explain why other traffic will use IPv6 - >> >> >>>>>> Use-cases, illustrating the expected areas for initial >> >> >>>>>> focus - Informative references, relationship with other >> >> >>>>>> SDOs >> >> >>>>>> >> >> >>>>>> 2. Standards Track RFC "IPv6 over DSRC" >> >> >>>>> This particular mentioning of "IPv6 over DSRC" has raised a >> >> >>>>> number of questions. >> >> >>>>> >> >> >>>>> Do you think it is the appropriate title? >> >> >>>>> >> >> >>>>> Alex >> >> >>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> 3. Informational RFC "Problem Statement" covering: - >> >> >>>>>> Problem statement - Security considerations - Privacy >> >> >>>>>> considerations >> >> >>>>> _______________________________________________ its mailing >> >> >>>>> list its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> >>>> >> >> >>> >> >> >>> _______________________________________________ its mailing list >> >> >>> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> >> >> >> >> -- >> >> John Kenney >> >> Director and Principal Researcher >> >> Toyota InfoTechnology Center, USA >> >> 465 Bernardo Avenue >> >> Mountain View, CA 94043 >> >> Tel: 650-694-4160. Mobile: 650-224-6644 >> >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > -- > Dr. Hans-Joachim Fischer > Managing Director > > > ------------------------------------------------------------------------------- > > ESF News edition 2016/1 > http://fischer-tech.eu/Feeds/News/ESF-News-2016-01.pdf > > ------------------------------------------------------------------------------- > + + + Instaurare omnia in Christo + + + > ------------------------------------------------------------------------------- > The information contained in this message is confidential and may be legally > privileged. This email is intended for the addressee(s). Addressees may be > individual persons or members of mailing list. > If you are not an addressee, you are hereby notified that any use, > dissemination, or reproduction of this email and its optional attachements is > strictly prohibited and may be unlawful. If you are not an addressee, please > contact the sender by return e-mail and destroy all copies of the original > message. > ------------------------------------------------------------------------------- > ESF GmbH > Fichtenweg 9 > 89143 Blaubeuren > +49 (7344) 175340 (Direct line) > +49 (7344) 919188 (Central office) > +49 (7344) 919123 (Fax) > http://fischer-tech.eu : Main web of ESF GmbH > http://its-standards.eu : News on cooperative ITS standardization > http://its-testing.org : International consultancy for cooperative ITS > ------------------------------------------------------------------------------- > > ------------------------------------------------------------------------------- > ESF online-news: http://fischer-tech.eu/Feeds/esf.rss > C-ITS online news: http://its-standards.info/Feeds/cits.rss > ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss > ------------------------------------------------------------------------------- > From nobody Fri May 27 04:29:12 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576A512DBB4 for ; Fri, 27 May 2016 04:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YLZWpg49afu for ; Fri, 27 May 2016 04:29:07 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D4812DBB2 for ; Fri, 27 May 2016 04:29:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4RBSxgf008418; Fri, 27 May 2016 13:28:59 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3067220776B; Fri, 27 May 2016 13:29:13 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1E64E20528E; Fri, 27 May 2016 13:29:13 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4RBSwPp019545; Fri, 27 May 2016 13:28:59 +0200 To: Dick Roy , "'John Kenney'" References: <571E06FF.9060404@gmail.com> <571F6758.4050402@gmail.com> <57275AB1.5030308@gmail.com> <15c04ca5-d6e3-095b-dead-149ca1cda060@gmail.com> <1463538517.3378.3.camel@gmail.com> <2cc0e36a-0f38-9aa7-128f-c63110bfd510@gmail.com> <6469b110-d0e5-bb89-615e-e8993787908e@gmail.com> <7D2F1744F772491CAF81F9D50BF5A2BC@SRA5> <5a35230a-59df-5c8e-538e-f2fd81d6801c@gmail.com> <624afe60-3d17-3a33-131e-542e71254a93@gmail.com> <5DA74713E5D1492F912D442ED26177EC@SRA5> From: Alexandre Petrescu Message-ID: Date: Fri, 27 May 2016 13:28:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5DA74713E5D1492F912D442ED26177EC@SRA5> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Richard Roy' , its@ietf.org Subject: Re: [its] latest charter text - title of items "IPv6 over 802.11p" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 11:29:10 -0000 Le 27/05/2016 à 02:45, Dick Roy a écrit : [...] > To describe and justify the IETF’s effort to “upgrade IP” to handle > rapidly varying network topologies and unreliable links does NOT > require mention of any particular MAC&PHY. To clarify - I wonder where this perspective about upgrading IP can come from? I never said and I never heard such discussion here. Alex > There are more than enough to go around, and the resulting IPv6 > functionality will not depend on what frequency band is being used at > the PHY! Add to this the fact that the 5.9GHz band is the most > tenuous at present of all the other possible choices, focusing on it > is probably the worst choice you could make. The characteristics of > the lower layers (1 and 2) can be described sufficiently well without > naming names, so don’t name names. > > > > RR > > > > ------------------------------------------------------------------------ > > *From:*John Kenney [mailto:jkenney@us.toyota-itc.com] *Sent:* > Thursday, May 26, 2016 11:40 AM *To:* Dick Roy *Cc:* Alexandre > Petrescu; Richard Roy; its@ietf.org *Subject:* Re: [its] latest > charter text - title of items "IPv6 over 802.11p" > > > > I don't disagree with Dick's second paragraph, but I wouldn't want > there to be confusion about the existence of "rules." The auto > industry has worked hard to develop and publish key standards related > to the BSM (SAE J2735, SAE J2945/1), so there will be > interoperability. Deployments are moving ahead in the US based on > those standards. > > > > Best Regards, > > John > > > > On Thu, May 26, 2016 at 10:13 AM, Dick Roy > wrote: > > At present, in the U.S., there are NO rules. NHTSA has yet to “make > the rules”. If all goes according to the current plan in the minds > of a few individuals, then the relevant SAE and IEEE standards that > have been produced over the last 15 years will form the basis of that > ruling. Things could change, including the frequency allocations, > between now and then. Stay tuned … > > > > As for the BSM, it has little to no value outside a VERY LIMITED > geographic and temporal region. No one more than a few hundred > meters from a given vehicle cares where it is, and even if it knew, > within a few tenths of a second, it would be yesterday’s news! There > is NO thought that broadcasting BSMs through networks makes any sense > at all. That DOES NOT mean that logging a few for transmission to a > TMC to be used for traffic management and efficiency applications > won’t happen. But that is NOT an IP broadcast. There is simply NO > WAY all (or even a miniscule fraction thereof) BSMs transmitted are > going to end up traversing IP networks. The network(s) can’t handle > all the USELESS information! > > > > RR > > > > -----Original Message----- From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com > ] > > Sent: Wednesday, May 25, 2016 11:56 PM To: dickroy@alum.mit.edu > Cc: its@ietf.org > Subject: Re: [its] latest charter text - title of items "IPv6 over > 802.11p" > > > > Dick, thanks for the reply. > > > > Le 26/05/2016 à 08:44, Dick Roy a écrit : > >> > >> > >> -----Original Message----- From: Alexandre Petrescu > >> [mailto:alexandre.petrescu@gmail.com >> ] > Sent: Wednesday, May 25, 2016 > >> 1:51 AM To: dickroy@alum.mit.edu ; >> its@ietf.org > Subject: Re: [its] > >> latest charter text - title of items "IPv6 over 802.11p" > >> > >> Le 25/05/2016 à 00:49, Dick Roy a écrit : > >>> Any mention of messages and/or message types that could or >>> should > >>> or might or can't or whatever be sent using this "new IP > >>> functionality" is out of scope. IPv6 connectivity in highly > >>> transient environments is the goal. Just keep it simple! > >> > >> I fully agree. That's why "DSRC" in the title is not simple at >> all. > >> > >>> Saying you are going to send BSMs using IPv6 is going to > >>> needlessly ruffle some big feathers! > >> > >> I agree. Sending BSM over IPv6 over 802.11p may be an activity >> for > >> later, if proven necessary. [RR>] Whether or not it happens has NO > >> bearing on the work this group should be considering. It's a >> local > >> broadcast, and does not need IPv6 at all. > > > > Well, let us save this discussion for later. There are many aspects > > that need to be mentioned about advantages and inconvenients of a > > network layer-less local broadcast. > > */ /* > >> (BSM stands for "Basic Safety Message" and is defined by the >> Society > >> of Automotive Engineers in the standard J2735_201603 "DSRC Message > >> Set Dictionary", paying access; a BSM is however dissected by the > >> freely available open source wireshark tool, and some packet >> captures > >> are freely available open source at > >> http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files > >> >> > >> > >> > >> [RR>] NB: The BSM is an ASN.1 data object. It's ABSTRACT. > > > > Ok. > > > >> It can be and is encoded in a variety of ways. When encoded > >> according to what a few people believe to be the correct encoding >> for > >> US V2V deployments, > > > > I hope there is BSM interoperability at least within US V2V > deployments. > > That should me more than just what a few people believe. > > > > then yes, a wireshark tool programmed to decode > >> that particular encoding can dissect the contents. So when the >> rules > >> are finally set, if the encoding changes, so muist the wireshark > >> tools if they want to be able to "dissect the BSM". > > > > You mean the rules are undergoing change? > > > > Alex > > > >> > >> RR > >> > >> > >> Alex > >> > >>> > >>> RR > >>> > >>> -----Original Message----- From: Alexandre Petrescu > >>> [mailto:alexandre.petrescu@gmail.com >>> ] > Sent: Tuesday, May 24, 2016 > >>> 5:41 AM To: its@ietf.org Subject: Re: [its] >>> latest charter text - > >>> title of items "IPv6 over 802.11p" > >>> > >>> Hello ITSers, > >>> > >>> I discussed with people involved in GCDC, yogoko, and open >>> source > >>> of ETSI ITS CAM (github.com/alexvoronov/geonetworking > ), IEEE > >>> 802.11p (github.com/CTU-IIG/802.11p-linux > ) and SAE BSM at > >>> itsforge.net . > >>> > >>> At this time I believe the title of the work item number 2 >>> should > >>> be: > >>> > >>> "IPv6 over 802.11p" and not "IPv6 over DSRC". > >>> > >>> In this title the "DSRC" term was a source of confusion: - it > >>> means link-layer in some context but app-layer in other, - the > >>> authoritative source of definition of 'DSRC' seems to be SAE, >>> but > >>> not sure whether it's rather IEEE, or other - not sure where to > >>> look for it. > >>> > >>> On the contrary, '802.11p' is clearly defined as 'Outside the > >>> Context of a BSSID of 802.11' by IEEE. It always means >>> link-layer > >>> (there are no 802.11p applications - an application runs equally > >>> well on 802.11b as on 802.11p). > >>> > >>> I will modify the title in the work item charter proposal > >>> accordingly. > >>> > >>> This does not preclude that later we can work on "Transmission >>> of > >>> DSRC messages like BSM over IPv6 over 802.11p". > >>> > >>> Alex > >>> > >>> Le 18/05/2016 à 09:23, Alexandre Petrescu a écrit : > >>>> Well yes, it's a shared medium. > >>>> > >>>> But "IPv6-over-foo" documents are titled something like: > >>>> "Transmission of IPv6 Packets over Ethernet Networks" RFC > >>>> 2464 "Transmission of IPv6 Packets over IEEE 802.15.4 >>>> Networks" > >>>> RFC 4944 "Transmission of IPv6 Packets over ITU-T G.9959 > >>>> Networks" RFC 7428 > >>>> > >>>> What could DSRC in "IPv6 over DSRC" mean? The 802.11 OCB >>>> link? > >>>> 802.11p? The set of WAVE WSMP messages? > >>>> > >>>> I am tempted to believe that in this context "DSRC" means > >>>> "802.11 OCB". > >>>> > >>>> Alex > >>>> > >>>> > >>>> Le 18/05/2016 à 04:28, Rex Buddenberg a écrit : > >>>>> shared medium > >>>>> > >>>>> On Tue, 2016-05-17 at 16:31 +0200, Alexandre Petrescu wrote: > >>>>>> Hello, > >>>>>> > >>>>>> > >>>>>> Le 02/05/2016 à 15:48, Alexandre Petrescu a écrit : [...] > >>>>>>> > >>>>>>> 1. Informational RFC "ITS General Problem Area" >>>>>>> covering: > >>>>>>> - What is ITS? - Explain V2V, V2I, and related terms - >>>>>>> Why > >>>>>>> is IPv6 needed? - Explain why some traffic will not use > >>>>>>> IPv6 - Explain why other traffic will use IPv6 - > >>>>>>> Use-cases, illustrating the expected areas for initial > >>>>>>> focus - Informative references, relationship with other > >>>>>>> SDOs > >>>>>>> > >>>>>>> 2. Standards Track RFC "IPv6 over DSRC" > >>>>>> This particular mentioning of "IPv6 over DSRC" has raised >>>>>> a > >>>>>> number of questions. > >>>>>> > >>>>>> Do you think it is the appropriate title? > >>>>>> > >>>>>> Alex > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 3. Informational RFC "Problem Statement" covering: - > >>>>>>> Problem statement - Security considerations - Privacy > >>>>>>> considerations > >>>>>> _______________________________________________ its >>>>>> mailing > >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its > >>>>> > >>>> > >>>> _______________________________________________ its mailing >>>> list > >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its > >>> > >>> > >>> > >>> > >> > >> > >> > >> > > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > -- > > John Kenney > > Director and Principal Researcher > > Toyota InfoTechnology Center, USA > > 465 Bernardo Avenue > > Mountain View, CA 94043 > > Tel: 650-694-4160. Mobile: 650-224-6644 > From nobody Mon May 30 02:18:52 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CFC12D1E6 for ; Mon, 30 May 2016 02:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoanPUR0hkEn for ; Mon, 30 May 2016 02:18:49 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCBE12D1AF for ; Mon, 30 May 2016 02:18:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4U9Iki9031148 for ; Mon, 30 May 2016 11:18:46 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C6E7D20B585 for ; Mon, 30 May 2016 11:19:04 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B663020BBAC for ; Mon, 30 May 2016 11:19:04 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4U9Ijv5013427 for ; Mon, 30 May 2016 11:18:46 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: Date: Mon, 30 May 2016 11:18:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------24691D72B65E1FB85FF37C4D" Archived-At: Subject: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 09:18:51 -0000 This is a multi-part message in MIME format. --------------24691D72B65E1FB85FF37C4D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi ITSers, The latest charter text is at: http://tools.ietf.org/wg/its/trac Alex --------------24691D72B65E1FB85FF37C4D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi ITSers,

The latest charter text is at:

   http://tools.ietf.org/wg/its/trac

Alex

--------------24691D72B65E1FB85FF37C4D-- From nobody Mon May 30 09:57:14 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C191E12D14F for ; Mon, 30 May 2016 09:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3HWKeyiVLmq for ; Mon, 30 May 2016 09:57:10 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1A612D165 for ; Mon, 30 May 2016 09:57:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E3537309141 for ; Mon, 30 May 2016 12:57:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUi9cZThUfUT for ; Mon, 30 May 2016 12:57:07 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id D50C1308EF3; Mon, 30 May 2016 12:57:05 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_01F18269-9188-4C70-AB37-456A24DEF2B9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Mon, 30 May 2016 12:57:06 -0400 Message-Id: <809CBE22-CE6B-43AE-ADD3-0AE9CC327A0B@vigilsec.com> References: To: Alexandre Petrescu X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 16:57:13 -0000 --Apple-Mail=_01F18269-9188-4C70-AB37-456A24DEF2B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii With this proposed timeline, there would be no reason to meeting in = Berlin because none of the I-Ds will be ready for discussion for = adoption. Is that the intent? Russ On May 30, 2016, at 5:18 AM, Alexandre Petrescu = wrote: > Hi ITSers, >=20 > The latest charter text is at: >=20 > http://tools.ietf.org/wg/its/trac >=20 > Alex --Apple-Mail=_01F18269-9188-4C70-AB37-456A24DEF2B9 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii With this proposed timeline, there would be no reason to meeting in Berlin because none of the I-Ds will be ready for discussion for adoption.  Is that the intent?

Russ


On May 30, 2016, at 5:18 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

Hi ITSers,

The latest charter text is at:

   http://tools.ietf.org/wg/its/trac

Alex

--Apple-Mail=_01F18269-9188-4C70-AB37-456A24DEF2B9-- From nobody Mon May 30 20:02:00 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B0D12D15C for ; Mon, 30 May 2016 20:01:58 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7GxFCuyYf4i for ; Mon, 30 May 2016 20:01:56 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850B412D545 for ; Mon, 30 May 2016 20:01:51 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id z189so43931002itg.0 for ; Mon, 30 May 2016 20:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=G+tDvmfxigCK58/WUxLPj3xeIaPZeB9cqIwC9gV4Qzg=; b=DE2eiUeNANjH45pn52q/geZsr9dvIWLZuybntuFoGSdFjwnHVnAH2Isn63fQJUDoya yfzy3L2sx+rs7iEDjvt/rrew2jXhvTITmWitfb6mFgXw6C8qwm6IYq9AP0Nr0tz4AKtT 31N+pgpzT2AR2zToijfATpG1pONi4pDNX7SLPWr4JsCiH/y3bUBXvV3lr0Di3URSyQGP gP1ORDfvBM5F9toKguZJkte40f4QNUGF+TroIyuBs1H9YzFmyX6tgJ667dQ2OJlkqoJF ngGBnpR+o31c9K1Di4eu/3xCPSe8v9f5ChCZc56WEx4SK/5nMc9e4BMeeum9W6/E+EhY T0ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=G+tDvmfxigCK58/WUxLPj3xeIaPZeB9cqIwC9gV4Qzg=; b=JNhexI96M4MZeDl4yET+nJUijRsWypQEB7JuSM/vobZq8kTcCFo3u89I9QUz0u5J17 J6iPo9MPItEkrczq5MgmndgWsxGGFjHQHBIv5GASpwrl3g5ynQ81rNJerTvmgc4NaR0I uRou9D+vB7NEEOHtVc64W2K36XkG2H37J5FMfNu0tXZ3W7lDExtoK9ILdYegWZ8/c0+O CNhqGwWe7E0pfvpGyJx/JYg40ZAZ3FXwqDkii2Q5h/crL+CiFQLaOh8uJ4RE8l5HRP2c z0miuk0GDss2xYLC6Jm830yia4rWbY21sk9crwTNDoagEiEMzrlWPjcU2BdH7Lt79GD7 EDfQ== X-Gm-Message-State: ALyK8tLwn2XufayVqHt+QRKIe3sIGWx+7zDo5TY8gPn5O0XSBkrzcHHVcH7gjC5U7O6DGuuf0ammxrWl6t6qXQ== MIME-Version: 1.0 X-Received: by 10.36.134.3 with SMTP id u3mr10648456itd.23.1464663710877; Mon, 30 May 2016 20:01:50 -0700 (PDT) Received: by 10.79.122.77 with HTTP; Mon, 30 May 2016 20:01:50 -0700 (PDT) In-Reply-To: <809CBE22-CE6B-43AE-ADD3-0AE9CC327A0B@vigilsec.com> References: <809CBE22-CE6B-43AE-ADD3-0AE9CC327A0B@vigilsec.com> Date: Tue, 31 May 2016 11:01:50 +0800 Message-ID: From: Dapeng Liu To: Russ Housley Content-Type: multipart/alternative; boundary=94eb2c088ffc33d20a05341a98bb Archived-At: Cc: Alexandre Petrescu , "its@ietf.org" Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 03:01:59 -0000 --94eb2c088ffc33d20a05341a98bb Content-Type: text/plain; charset=UTF-8 Maybe we can change the wording to: XXX 2016 - WG call to adopt "ITS General Problem Area" draft Best Regards, Dapeng Liu 2016-05-31 0:57 GMT+08:00 Russ Housley : > With this proposed timeline, there would be no reason to meeting in Berlin > because none of the I-Ds will be ready for discussion for adoption. Is > that the intent? > > Russ > > > On May 30, 2016, at 5:18 AM, Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > > Hi ITSers, > > The latest charter text is at: > > http://tools.ietf.org/wg/its/trac > > Alex > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > -- ------ Best Regards, Dapeng Liu --94eb2c088ffc33d20a05341a98bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Maybe we can change the wording to:=C2=A0
XXX 2016=
 - WG call to adopt  "ITS General Probl=
em Area" draft

Best Regards,
Dapeng Liu

2016-05-31 0:57 GMT+08:00 Russ Housley <housley@vigilsec.com= >:
With t= his proposed timeline, there would be no reason to meeting in Berlin becaus= e none of the I-Ds will be ready for discussion for adoption.=C2=A0 Is that= the intent?

Ru= ss


<= div>On May 30, 2016, at 5:18 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com= > wrote:

=20 =20 =20

H= i ITSers,

The latest charter text i= s at:

=C2=A0=C2=A0 http://tools.ietf.org/wg/it= s/trac

Alex


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




--

------
Bes= t Regards,
Dapeng Liu
--94eb2c088ffc33d20a05341a98bb-- From nobody Tue May 31 08:38:43 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BB212D7E6 for ; Tue, 31 May 2016 08:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHwARvDW-Oz9 for ; Tue, 31 May 2016 08:38:40 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40C512D7E5 for ; Tue, 31 May 2016 08:38:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7D6AE309528 for ; Tue, 31 May 2016 11:38:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fosozN1viQvq for ; Tue, 31 May 2016 11:38:37 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 996C73001A2 for ; Tue, 31 May 2016 11:38:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Tue, 31 May 2016 11:38:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <809CBE22-CE6B-43AE-ADD3-0AE9CC327A0B@vigilsec.com> To: "its@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 15:38:42 -0000 Based on the discussion during the ITS Virtual BoF Session, I made a few = edits to the proposed charter text. The updated text can be seen here: https://trac.tools.ietf.org/wg/its/trac/ The changes can be seen here: = https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=3Ddiff&versi= on=3D12 Is this charter ready for sending to the INT AD and the rest of the = IESG? Russ From nobody Tue May 31 08:41:13 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520FC12D7E9 for ; Tue, 31 May 2016 08:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VWM_zlV51Th for ; Tue, 31 May 2016 08:41:06 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8368512D7E6 for ; Tue, 31 May 2016 08:41:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4VFewEu004928 for ; Tue, 31 May 2016 17:40:58 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2571520C673 for ; Tue, 31 May 2016 17:41:18 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1031F205286 for ; Tue, 31 May 2016 17:41:18 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4VFewvi030162 for ; Tue, 31 May 2016 17:40:58 +0200 To: its@ietf.org References: <809CBE22-CE6B-43AE-ADD3-0AE9CC327A0B@vigilsec.com> From: Alexandre Petrescu Message-ID: <6324980c-6f2b-92d3-1a6d-86c9b00b89e3@gmail.com> Date: Tue, 31 May 2016 17:40:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 15:41:12 -0000 Thanks for the updates. And the milestone discussion? Alex Le 31/05/2016 à 17:38, Russ Housley a écrit : > Based on the discussion during the ITS Virtual BoF Session, I made a few edits to the proposed charter text. > > The updated text can be seen here: > https://trac.tools.ietf.org/wg/its/trac/ > > The changes can be seen here: > https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=diff&version=12 > > Is this charter ready for sending to the INT AD and the rest of the IESG? > > Russ > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Tue May 31 08:44:42 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF6212B05C for ; Tue, 31 May 2016 08:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDJyL6GApVRT for ; Tue, 31 May 2016 08:44:37 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7288212D0B7 for ; Tue, 31 May 2016 08:44:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 767F7309527 for ; Tue, 31 May 2016 11:44:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXpSKMgpY-L2 for ; Tue, 31 May 2016 11:44:33 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 64A613001A2; Tue, 31 May 2016 11:44:32 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <6324980c-6f2b-92d3-1a6d-86c9b00b89e3@gmail.com> Date: Tue, 31 May 2016 11:44:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <74BDA1DA-97F8-433E-B8E2-545C51F54559@vigilsec.com> References: <809CBE22-CE6B-43AE-ADD3-0AE9CC327A0B@vigilsec.com> <6324980c-6f2b-92d3-1a6d-86c9b00b89e3@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: its@ietf.org Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 15:44:40 -0000 I now understand the approach that is bing suggested, and I do not think = any adjustments are needed to the milestones. Russ On May 31, 2016, at 11:40 AM, Alexandre Petrescu = wrote: > Thanks for the updates. >=20 > And the milestone discussion? >=20 > Alex >=20 > Le 31/05/2016 =E0 17:38, Russ Housley a =E9crit : >> Based on the discussion during the ITS Virtual BoF Session, I made a = few edits to the proposed charter text. >>=20 >> The updated text can be seen here: >> https://trac.tools.ietf.org/wg/its/trac/ >>=20 >> The changes can be seen here: >> = https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=3Ddiff&versi= on=3D12 >>=20 >> Is this charter ready for sending to the INT AD and the rest of the = IESG? >>=20 >> Russ >>=20 >>=20 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >>=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Tue May 31 09:01:06 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A9612D60D for ; Tue, 31 May 2016 09:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAHvf5VAM626 for ; Tue, 31 May 2016 09:01:03 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8265A12D610 for ; Tue, 31 May 2016 09:00:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4VG0ta8017196; Tue, 31 May 2016 18:00:55 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A4686201CAB; Tue, 31 May 2016 18:01:14 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8D74A201CA5; Tue, 31 May 2016 18:01:14 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4VG0s6J018187; Tue, 31 May 2016 18:00:54 +0200 To: Russ Housley References: <809CBE22-CE6B-43AE-ADD3-0AE9CC327A0B@vigilsec.com> <6324980c-6f2b-92d3-1a6d-86c9b00b89e3@gmail.com> <74BDA1DA-97F8-433E-B8E2-545C51F54559@vigilsec.com> From: Alexandre Petrescu Message-ID: Date: Tue, 31 May 2016 18:00:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <74BDA1DA-97F8-433E-B8E2-545C51F54559@vigilsec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: its@ietf.org Subject: Re: [its] latest charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 16:01:05 -0000 Le 31/05/2016 à 17:44, Russ Housley a écrit : > I now understand the approach that is bing suggested, and I do not > think any adjustments are needed to the milestones. Ok, let's go that way then. Alex > > Russ > > > On May 31, 2016, at 11:40 AM, Alexandre Petrescu > wrote: > >> Thanks for the updates. >> >> And the milestone discussion? >> >> Alex >> >> Le 31/05/2016 à 17:38, Russ Housley a écrit : >>> Based on the discussion during the ITS Virtual BoF Session, I >>> made a few edits to the proposed charter text. >>> >>> The updated text can be seen here: >>> https://trac.tools.ietf.org/wg/its/trac/ >>> >>> The changes can be seen here: >>> https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=diff&version=12 >>> >>> >>> Is this charter ready for sending to the INT AD and the rest of the IESG? >>> >>> Russ >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Tue May 31 09:32:27 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59E512D81B for ; Tue, 31 May 2016 09:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiVFve_LDkdp for ; Tue, 31 May 2016 09:32:23 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12F612D621 for ; Tue, 31 May 2016 09:32:22 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id e62so64409136ita.1 for ; Tue, 31 May 2016 09:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=xwa9DC6Xlloim8E9SMiN6EJGpAi4MNpiqh/UPPbJxGk=; b=lrNU3vlgPUC9AU+lywtglpEjBpKk9+R/e/JKKitWQ/znpce1TqZzedLTrxH9YhC1XI A1AM8uYHpV0jCwx83fu7+QFWYW+nNcwsxah6MY+oGaJbg/PMJfSb/WwIASLbPphtcEu7 FVr5hNF9IiBLEPshozhg94wbjiFAt4FUMO10KJ4e1zK1Y+8/WlygOKOIiWS9Q07V3Tcc zIljFo4Qb7hS0XS79214xbi6Tx2uO1yRwBbbL/OvZbLRX88Ju+npEiuNRY1GSd5y31z3 E3nrfcNvGdiCK9xIlYVkGldvRQCnTT6Fs4Sc0edjziMVnraSekAnuydpY1HQdDtxMcyY lD3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=xwa9DC6Xlloim8E9SMiN6EJGpAi4MNpiqh/UPPbJxGk=; b=V+lpViSz5qDaNu3QwXKkJ8hbIaydQvoE2zYpSOs5T1KfTOsBsVTkBhea53H3AAF6ps 1KImBW+QpazsUx06nf0oRpPpb0ktlFCavBrjt0HyZSNTHkR7vXppP9rDqoGDwp/VN9fr looE2W1wQflu3bHSMrf2LDDzf/QzKPlA8Dq+Iz7aPbKodUwguOQovBhjNIZM52maO+kn Sm0xhBz3znSynomg0TBB8RGjVmBmbVGfMbXmpoToUGCD20Nj51w2mDkOqF2hZIwovidO Ay93fWquTR/NxC+7ggh0nQHqrvAkVQgaMJqubmPRP7SzEq207nLFgJZ8NggBhvVUECSd w1Jg== X-Gm-Message-State: ALyK8tIphXG3KcRhlKG1+io4sBCincO60KhA1R6kgJT9jeXPksdv07/y8t3F85xBBBkFytOcPu6D+CK87VM+rQ== MIME-Version: 1.0 X-Received: by 10.36.25.203 with SMTP id b194mr3359824itb.67.1464712342138; Tue, 31 May 2016 09:32:22 -0700 (PDT) Received: by 10.79.122.77 with HTTP; Tue, 31 May 2016 09:32:22 -0700 (PDT) Date: Wed, 1 Jun 2016 00:32:22 +0800 Message-ID: From: Dapeng Liu To: Russ Housley , "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a1144b37cd9ff20053425ead1 Archived-At: Cc: Alexandre Petrescu , "its@ietf.org" Subject: [its] Meeting Minutes: ITS Virtual BOF Session X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 16:32:26 -0000 --001a1144b37cd9ff20053425ead1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Russ and Carlos: Thanks for chairing the virtual BOF meeting. Here is the meeting minutes. ___________________________________________________________________________= ____________________________________________________________________ *Meeting Minutes: ITS Virtual BOF Session* 1. Time: Tuesday, May 31, 2016 10:00 am =E2=80=93 11:00 am (Eastern Daylight Time (New York, GMT-04:00) ,= 1 hour Chairs: Russ Housley, Carlos Pignataro Attendees: 14; Russ Housley, Carlos Pignataro, Alexandre Petrescu, Dapeng Liu, Arnaud Kaiser, Carsten Bormann, Dino Farinacci, Fred Templin, Jong-Hyouk Lee, Michael Breuer, Mingpeng Qi, Sandra Cespedes, Thierry Ernst, Yongjing Zhang 2. Russ Housley (Chair): Introduce the meeting agenda. This meeting will focus on the charter text discussion, which will be sent to the AD. 2.1 Alexandre Petrescu presented =E2=80=9CFinalizing charter text and deliv= erables=E2=80=9D. 2.1.1 Charter text discussion =E2=80=A2 Latest charter version available at http :// tools.ietf.org/wg/its/trac =E2=80=A2 The charter text was newly written; it begins with general information of the background (V2Internet, V2V, V2I etc) and goes to very specific work items. =E2=80=A2 Carlos: the 3rd paragraph, T2T is IRTF effort. =E2=80=A2 Fred: At the end of 3rd paragraph, it mentioned DMM working= group, also suggest to add =E2=80=9Cand other mobility solutions=E2=80=9D. =E2=80=A2 Russ: By coordination with =E2=80=9Cother solutions=E2=80= =9D you mean co-existence? =E2=80=A2 Russ: At current stage, "not work on DTN(Delay-Tolerant Net= working) and ICN(Information-Centric Networking)" , might work on those in the future. 2.1.2 Deliverables =E2=80=A2 3 deliverables, 2 informational documents and 1 standard tr= ack RFC: =E2=80=A2 General problem area RFC: explain what is ITS, V2V, V2I, references, why IPv6 is used, relationship with other SDOs etc. =E2=80=A2 IPv6 over 802.11p RFC: =E2=80=9CIPv6 over foo=E2=80=9D docu= ment. =E2=80=A2 Problem statement RFC: problem statement, security consider= ation and privacy considerations. 2.1.3 Timeline: =E2=80=A2 6 milestones, group 2 by 2. This is discussion on the list.= The plan is to present candidate drafts in Berlin meeting and in Nov, need to form a team of people working on the draft. The timeline can be modified based on discussion. =E2=80=A2 Dapeng Liu: Need a meeting in Berlin, suggest to change the= wording to =E2=80=9CWG call to adopt..=E2=80=9D. =E2=80=A2 Russ: It is clarified and understands the plan now. Not nec= essarily to change. 2.1.4 Candidate drafts (Presented by Dapeng Liu) =E2=80=A2 Currently we have 4 candidate drafts, some of them has been presented in last meeting. Open to other contributors and drafts. =E2=80=A2 Remember to submit before submission deadline for July meet= ing. =E2=80=A2 Sandra: Working on a document for work item 1. =E2=80=A2 Thierry: Will work on IPv6 over 802.11p.. 3. Russ Housley (Chair): Discussion on who is willing to work on the drafts and review the drafts. =E2=80=A2 Russ: Need to make sure there will be enough people willing= to work on the drafts. For the first item: several drafts could be merged? =E2=80=A2 Alex: Yes, several drafts could be merged and maybe publish= new drafts. Several other people also willing to work on other 2 items. =E2=80=A2 Russ: Anyone want to review the drafts? =E2=80=A2 Alex: There are 3 developers would like to review work item= 2 drafts. =E2=80=A2 Dapeng Liu: Offline discussion with China Mobile, they have interest to review and contribute. Dino says in the chat room that he would like to review: =E2=80=9C(Dino from chat room): I am going to read the draf= ts, so I have requirements for solutions we can propose from the LISP working group= =E2=80=9D =E2=80=A2 Russ: How about the problem statement draft, anyone wants t= o review? =E2=80=A2 Dapeng Liu: Russ, you can review? =E2=80=A2 Russ Housley: Would like to review. =E2=80=A2 Alex: Arnaud would like to review. Two others in the chat r= oom. =E2=80=A2 Mingpeng Qi (from chat room): I will review problem stateme= nt draft and contribute some security considerations for the draft. =E2=80=A2 Thierry Ernst: I will also review the pb statements drafts.= I take the opportunity to say that other people from ISO TC204 will contribute through the IETF - ISO liaison I'm responsible with. 4. IPv6 over 802.11p (Presented by Alex) =E2=80=A2 Introduction of IPv6 over 802.11p. The meeting ended at 11:am Eastern Daylight Time. ___________________________________________________________________________= ____________________________________________________________________ ------ Best Regards, Dapeng Liu --001a1144b37cd9ff20053425ead1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Russ and Carlos:

Thank= s for chairing the virtual BOF meeting. Here is the meeting minutes.
<= div>

_________________________________________= ___________________________________________________________________________= ___________________________


Meeting Minutes: ITS Virtual BOF Session

1.=C2=A0= Time: Tuesday, May 31, 2016

10:00 am =E2=80=93 11:00 am=C2=A0=C2=A0(Eastern Daylight Time (New York, GMT-04:00)=C2=A0, 1 hour

Chairs: =C2=A0Russ=C2=A0Housley, Carlos Pignataro=

Attendees: 14;=C2=A0Russ=C2=A0Housley, Carlos Pignataro, Alexandre Petrescu, Dapeng Liu, Arnaud Kaiser, Carsten Bormann, Dino Farinacci, Fred Templin, Jong-Hyouk Lee, Michael Breuer, Mingpeng Qi, Sandra Cespedes, Thierry Ernst, Yongjing Zhang

=C2=A0

2. Russ = Housley (Chair): Introduce the meeting agenda. This meeting will focus on the charter text discussion, which will be sent to = the AD.

2.1 Alex= andre Petrescu presented =E2=80=9CFinalizing charter text and deliverables=E2=80=9D.

2.1.1 Ch= arter text discussion

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Latest charter version available at http://tools.ietf.org/wg/its/trac

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 The charter text was newly written; it begins with general information of the= background (V2Internet, V2V, V2I etc) and goes to very specific work items.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Carlos: the 3rd paragraph, T2T is IRTF effort.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Fred: At the end of 3rd paragraph, it mentioned DMM working group, also= suggest to add =E2=80=9Cand other mobility solutions=E2=80=9D.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Russ: By coordination with =E2=80=9Cother solutions=E2=80=9D you mean co-existe= nce?

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Russ: At c= urrent stage, "not work on DTN(Delay-Tolerant Networking) and ICN(Information-Centric Networking)" , might work on those in the future.

2.1.2 De= liverables

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 3 deliverables, 2 informational documents and 1 standard track RFC: =

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 General problem area RFC: explain what is ITS, V2V, V2I, references, why IPv6 is used, relationship with other SDOs etc.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 IPv6 over 802.11p RFC: =E2=80=9CIPv6 over foo=E2=80=9D document.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Problem statement RFC: problem statement, security consideration and privacy considerations.

2.1.3 Ti= meline:

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 6 milestones, group 2 by 2. This is discussion on the list. The plan is to present candidate drafts in Berlin meeting and in Nov, need to form a team of peo= ple working on the draft. The timeline can be modified based on discussion.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Dapeng Liu: Need a meeting in Berlin, suggest to change the wording to =E2=80=9C= WG call to adopt..=E2=80=9D.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Russ: It is clarified and understands the plan now. Not necessarily to change.

2.1.4 Ca= ndidate drafts (Presented by Dapeng Liu)

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Currently we have 4 candidate drafts, some of them has been presented in last meeti= ng. Open to other contributors and drafts.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Remember to submit before submission deadline for July meeting.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Sandra: Working on a document for work item 1.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Thierry: Will work on IPv6 over 802.11p..

3. Russ Housley (Chair): Discussion on who is willing to work on the drafts and review the drafts.

=E2=80=A2= =C2=A0 =C2=A0 =C2=A0 =C2=A0Russ:=C2= =A0Need to make sur= e there will be enough people willing to work on the drafts. For the first item: several drafts co= uld be merged?

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Alex: Yes, several = drafts could be merged and maybe publish new drafts. Several other people also willing to w= ork on other 2 items.

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Russ: Anyone want t= o review the drafts?

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Alex: There are 3 d= evelopers would like to review work item 2 drafts.

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Dapeng Liu: Offline= discussion with China Mobile, they have interest to review and contribute. Dino says in the chat room that he would like to review: =E2=80=9C(Dino from chat room): I a= m going to read the drafts, so I have requirements for solutions we can propose from t= he LISP working group=E2=80=9D

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Russ: How about the= problem statement draft, anyone wants to review?

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Dapeng Liu: Russ, y= ou can review?

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Russ Housley: Would= like to review.

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Alex: Arnaud would = like to review. Two others in the chat room.

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Mingpeng Qi (from c= hat room): I will review problem statement draft and contribute some security considerations for the draft.

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Thierry Ernst: I wi= ll also review the pb statements drafts. I take the opportunity to say that other people from ISO TC204 will contribute through the IETF - ISO liaison I'm responsible wi= th.

4. IPv6 ov= er 802.11p (Presented by Alex)

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Introduction of IPv= 6 over 802.11p.

=C2=A0

The meetin= g ended at 11:am Eastern Daylight Time.



_______________________________________________________________= ___________________________________________________________________________= _____

------
Best Regards,
Dapeng Liu
--001a1144b37cd9ff20053425ead1-- From nobody Tue May 31 16:09:04 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AAE12D8F6 for ; Tue, 31 May 2016 16:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 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, HK_NAME_FM_MR_MRS=1.5, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBNvDS3F0YeA for ; Tue, 31 May 2016 16:08:59 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB9F12D8F5 for ; Tue, 31 May 2016 16:08:59 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id h19so2633160ywc.0 for ; Tue, 31 May 2016 16:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+h2irFdBf+MCzJUk8iqa/rMLcRheEvD0Kg0luLA7ivI=; b=KuAjyGuZYX1bU93o+/ferE4VFeB4MwnDW556Ky7Tu0sVShsFYgum7tA8whJpjcBPIN ifdvbVtE4rckSzkUyKPOg3SzVsewAqBaR5iCO+Mmh/f15kqyygYP0johWQyESUtDnBq7 Mpc6/HLt2cuS0oEVpM3A79Idml4uoDkr+xWL+p1jGLekv7egBZEW/waUmlUAZJDjFtLh WgRiM6uSLEP9HSxeuWFynPOnLVVNF1Qc+vfL/sRn9RbKPoEXGh97411jc8P/66CiJI4X OPY4dFcSY4cPUA3x7RG4dKUSmQglwDuGmzF2ft0v2kunB3PFziSSzYJAyw8rHh8I0WdD DJxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+h2irFdBf+MCzJUk8iqa/rMLcRheEvD0Kg0luLA7ivI=; b=GQxtSYrVCh4TTicNsVEKK85Gq2Dcxhnk6rlgy3i79U7LxzFKMIXbJN3h+lHg0y15eK Y3PYB8klaoj2orI5O/0fq4soy8QzNlLWGmpuzwlwlTSnti/5x9DDtyh4RmSRgykRKD0o ncmTjGtJZI7RG6Q/ZVMYjhFm+Lcg0Tcqy/R3zb93H5Y4TqbXETOsUQ7Z5dR3zcRK3MAa G5BPJ1hXsKRNHFAudfXgQemnocnZSdacdyXMaQZdtl7PIKhuHigWIwhV0O47DjPM16R6 YHJfT8CJqMnKMC4tnrLNGDXq2eK6r6HE92bK9MQRKILA2cUI2DEvPQjRQyiPyOWi86iv ra4w== X-Gm-Message-State: ALyK8tLMOL2rPVwj3x7pHgnt2hcR9qT2aebxexI1L8ZPESo+8DzSK/HDPSJyslgtRSPKF/3c/uTsSp/fNiZvGQ== X-Received: by 10.129.54.16 with SMTP id d16mr400288ywa.41.1464736138687; Tue, 31 May 2016 16:08:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.212.76 with HTTP; Tue, 31 May 2016 16:08:29 -0700 (PDT) In-Reply-To: References: From: "Mr. Jaehoon Paul Jeong" Date: Wed, 1 Jun 2016 08:08:29 +0900 Message-ID: To: Dapeng Liu Content-Type: multipart/alternative; boundary=001a1142738c3c9d6d05342b75a9 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , Alexandre Petrescu , Russ Housley , "Mr. Jaehoon Paul Jeong" , "its@ietf.org" Subject: Re: [its] Meeting Minutes: ITS Virtual BOF Session X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 23:09:02 -0000 --001a1142738c3c9d6d05342b75a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I could not attend the last interim meeting due to some technical issue. I am working on the list of academic papers for IP-based V2V and V2I with Sandra Cespedes, Nabil Benamar, and J=C3=A9r=C3=B4me H=C3=A4rri. This will be a good foundation for our charter work. I am willing to work on item 1 and item 3 in our charter: Item 1: General problem area RFC: explain what is ITS, V2V, V2I, references, why IPv6 is used, relationship with other SDOs etc. Item 3: Problem statement RFC: problem statement, security consideration and privacy considerations. Thanks and see you in Berlin. Best Regards, Paul On Wed, Jun 1, 2016 at 1:32 AM, Dapeng Liu wrote: > Hello Russ and Carlos: > > Thanks for chairing the virtual BOF meeting. Here is the meeting minutes. > > > > _________________________________________________________________________= ______________________________________________________________________ > > > *Meeting Minutes: ITS Virtual BOF Session* > > 1. Time: Tuesday, May 31, 2016 > > 10:00 am =E2=80=93 11:00 am (Eastern Daylight Time (New York, GMT-04:00)= , 1 hour > > Chairs: Russ Housley, Carlos Pignataro > > Attendees: 14; Russ Housley, Carlos Pignataro, Alexandre Petrescu, Dapeng > Liu, Arnaud Kaiser, Carsten Bormann, Dino Farinacci, Fred Templin, > Jong-Hyouk Lee, Michael Breuer, Mingpeng Qi, Sandra Cespedes, Thierry > Ernst, Yongjing Zhang > > > > 2. Russ Housley (Chair): Introduce the meeting agenda. This meeting will > focus on the charter text discussion, which will be sent to the AD. > > 2.1 Alexandre Petrescu presented =E2=80=9CFinalizing charter text and > deliverables=E2=80=9D. > > 2.1.1 Charter text discussion > > =E2=80=A2 Latest charter version available at http > :// > tools.ietf.org/wg/its/trac > > =E2=80=A2 The charter text was newly written; it begins with genera= l > information of the background (V2Internet, V2V, V2I etc) and goes to very > specific work items. > > =E2=80=A2 Carlos: the 3rd paragraph, T2T is IRTF effort. > > =E2=80=A2 Fred: At the end of 3rd paragraph, it mentioned DMM worki= ng > group, also suggest to add =E2=80=9Cand other mobility solutions=E2=80=9D= . > > =E2=80=A2 Russ: By coordination with =E2=80=9Cother solutions=E2=80= =9D you mean > co-existence? > > =E2=80=A2 Russ: At current stage, "not work on DTN(Delay-Tolerant > Networking) and ICN(Information-Centric Networking)" , might work on thos= e > in the future. > > 2.1.2 Deliverables > > =E2=80=A2 3 deliverables, 2 informational documents and 1 standard = track > RFC: > > =E2=80=A2 General problem area RFC: explain what is ITS, V2V, V2I, > references, why IPv6 is used, relationship with other SDOs etc. > > =E2=80=A2 IPv6 over 802.11p RFC: =E2=80=9CIPv6 over foo=E2=80=9D do= cument. > > =E2=80=A2 Problem statement RFC: problem statement, security consid= eration > and privacy considerations. > > 2.1.3 Timeline: > > =E2=80=A2 6 milestones, group 2 by 2. This is discussion on the lis= t. The > plan is to present candidate drafts in Berlin meeting and in Nov, need to > form a team of people working on the draft. The timeline can be modified > based on discussion. > > =E2=80=A2 Dapeng Liu: Need a meeting in Berlin, suggest to change t= he > wording to =E2=80=9CWG call to adopt..=E2=80=9D. > > =E2=80=A2 Russ: It is clarified and understands the plan now. Not > necessarily to change. > > 2.1.4 Candidate drafts (Presented by Dapeng Liu) > > =E2=80=A2 Currently we have 4 candidate drafts, some of them has be= en > presented in last meeting. Open to other contributors and drafts. > > =E2=80=A2 Remember to submit before submission deadline for July me= eting. > > =E2=80=A2 Sandra: Working on a document for work item 1. > > =E2=80=A2 Thierry: Will work on IPv6 over 802.11p.. > > 3. Russ Housley (Chair): Discussion on who is willing to work on the > drafts and review the drafts. > > =E2=80=A2 Russ: Need to make sure there will be enough people willi= ng to > work on the drafts. For the first item: several drafts could be merged? > > =E2=80=A2 Alex: Yes, several drafts could be merged and maybe publi= sh new > drafts. Several other people also willing to work on other 2 items. > > =E2=80=A2 Russ: Anyone want to review the drafts? > > =E2=80=A2 Alex: There are 3 developers would like to review work it= em 2 > drafts. > > =E2=80=A2 Dapeng Liu: Offline discussion with China Mobile, they ha= ve > interest to review and contribute. Dino says in the chat room that he wou= ld > like to review: =E2=80=9C(Dino from chat room): I am going to read the dr= afts, so I > have requirements for solutions we can propose from the LISP working grou= p=E2=80=9D > > =E2=80=A2 Russ: How about the problem statement draft, anyone wants= to > review? > > =E2=80=A2 Dapeng Liu: Russ, you can review? > > =E2=80=A2 Russ Housley: Would like to review. > > =E2=80=A2 Alex: Arnaud would like to review. Two others in the chat= room. > > =E2=80=A2 Mingpeng Qi (from chat room): I will review problem state= ment > draft and contribute some security considerations for the draft. > > =E2=80=A2 Thierry Ernst: I will also review the pb statements draft= s. I > take the opportunity to say that other people from ISO TC204 will > contribute through the IETF - ISO liaison I'm responsible with. > > 4. IPv6 over 802.11p (Presented by Alex) > > =E2=80=A2 Introduction of IPv6 over 802.11p. > > > > The meeting ended at 11:am Eastern Daylight Time. > > > > _________________________________________________________________________= ______________________________________________________________________ > > ------ > Best Regards, > Dapeng Liu > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a1142738c3c9d6d05342b75a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
I could not attend the last interim meeting du= e to some technical issue.

I am working on the lis= t of academic papers for IP-based V2V and V2I with
Sandra Cespede= s, Nabil Benamar, and J=C3=A9r=C3=B4me H=C3=A4rri.
This will = be a good foundation for our charter work.

I am wi= lling to work on item 1 and item 3 in our charter:
Item 1: G= eneral problem area RFC: explain what is ITS, V2V, V2I, references, why IPv= 6 is used, relationship with other SDOs etc.
Item 3: Problem stat= ement RFC: problem statement, security consideration and privacy considerat= ions.

Thanks and see you in Berlin.

Best Regards,
Paul


On Wed, Jun 1, 2016 = at 1:32 AM, Dapeng Liu <maxpassion@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hello Russ and Carlos:<= /div>

Thanks for chairing the virtual BOF meeting. Here = is the meeting minutes.


___________= ___________________________________________________________________________= _________________________________________________________


Meeting Minutes: ITS Virtual BOF Session

1.=C2=A0= Time: Tuesday, May 31, 2016

10:00 am =E2=80=93 11:00 am=C2=A0=C2=A0(Eastern Daylight Time (New York, GMT-04:00)=C2=A0, 1 hour

Chairs: =C2=A0Russ=C2=A0Housley, Carlos Pignataro=

Attendees: 14;=C2=A0Russ=C2=A0Housley, Carlos Pignataro, Alexandre Petrescu, Dapeng Liu, Arnaud Kaiser, Carsten Bormann, Dino Farinacci, Fred Templin, Jong-Hyouk Lee, Michael Breuer, Mingpeng Qi, Sandra Cespedes, Thierry Ernst, Yongjing Zhang

=C2=A0

2. Russ = Housley (Chair): Introduce the meeting agenda. This meeting will focus on the charter text discussion, which will be sent to = the AD.

2.1 Alex= andre Petrescu presented =E2=80=9CFinalizing charter text and deliverables=E2=80=9D.

2.1.1 Ch= arter text discussion

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Latest charter version available at http://tools.ietf.org/wg/its/trac

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 The charter text was newly written; it begins with general information of the= background (V2Internet, V2V, V2I etc) and goes to very specific work items.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Carlos: the 3rd paragraph, T2T is IRTF effort.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Fred: At the end of 3rd paragraph, it mentioned DMM working group, also= suggest to add =E2=80=9Cand other mobility solutions=E2=80=9D.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Russ: By coordination with =E2=80=9Cother solutions=E2=80=9D you mean co-existe= nce?

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Russ: At c= urrent stage, "not work on DTN(Delay-Tolerant Networking) and ICN(Information-Centric Networking)" , might work on those in the future.

2.1.2 De= liverables

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 3 deliverables, 2 informational documents and 1 standard track RFC: =

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 General problem area RFC: explain what is ITS, V2V, V2I, references, why IPv6 is used, relationship with other SDOs etc.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 IPv6 over 802.11p RFC: =E2=80=9CIPv6 over foo=E2=80=9D document.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Problem statement RFC: problem statement, security consideration and privacy considerations.

2.1.3 Ti= meline:

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 6 milestones, group 2 by 2. This is discussion on the list. The plan is to present candidate drafts in Berlin meeting and in Nov, need to form a team of peo= ple working on the draft. The timeline can be modified based on discussion.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Dapeng Liu: Need a meeting in Berlin, suggest to change the wording to =E2=80=9C= WG call to adopt..=E2=80=9D.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Russ: It is clarified and understands the plan now. Not necessarily to change.

2.1.4 Ca= ndidate drafts (Presented by Dapeng Liu)

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Currently we have 4 candidate drafts, some of them has been presented in last meeti= ng. Open to other contributors and drafts.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Remember to submit before submission deadline for July meeting.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Sandra: Working on a document for work item 1.

=E2=80=A2=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Thierry: Will work on IPv6 over 802.11p..

3. Russ Housley (Chair): Discussion on who is willing to work on the drafts and review the drafts.

=E2=80=A2= =C2=A0 =C2=A0 =C2=A0 =C2=A0Russ:=C2= =A0Need to make sur= e there will be enough people willing to work on the drafts. For the first item: several drafts co= uld be merged?

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Alex: Yes, several = drafts could be merged and maybe publish new drafts. Several other people also willing to w= ork on other 2 items.

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Russ: Anyone want t= o review the drafts?

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Alex: There are 3 d= evelopers would like to review work item 2 drafts.

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Dapeng Liu: Offline= discussion with China Mobile, they have interest to review and contribute. Dino says in the chat room that he would like to review: =E2=80=9C(Dino from chat room): I a= m going to read the drafts, so I have requirements for solutions we can propose from t= he LISP working group=E2=80=9D

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Russ: How about the= problem statement draft, anyone wants to review?

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Dapeng Liu: Russ, y= ou can review?

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Russ Housley: Would= like to review.

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Alex: Arnaud would = like to review. Two others in the chat room.

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Mingpeng Qi (from c= hat room): I will review problem statement draft and contribute some security considerations for the draft.

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Thierry Ernst: I wi= ll also review the pb statements drafts. I take the opportunity to say that other people from ISO TC204 will contribute through the IETF - ISO liaison I'm responsible wi= th.

4. IPv6 ov= er 802.11p (Presented by Alex)

=E2=80=A2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Introduction of IPv= 6 over 802.11p.

=C2=A0

The meetin= g ended at 11:am Eastern Daylight Time.



________________________________________= ___________________________________________________________________________= ____________________________

------
Best Regards,
Dapeng Liu

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




--
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) J= eong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwa= n 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
--001a1142738c3c9d6d05342b75a9--