From nobody Thu Jul 7 10:33:58 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2999312B042 for ; Thu, 7 Jul 2016 10:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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, 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 X-RYLE8lA5a0 for ; Thu, 7 Jul 2016 10:33:55 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D9412D1A7 for ; Thu, 7 Jul 2016 10:33:46 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id i12so20039190ywa.1 for ; Thu, 07 Jul 2016 10:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=apGNlPHMLigNtBSeUzNWO0H/WFlsuXBnp1vB8OAQE8o=; b=njo0ukevhRhMuuOXT+jAUQYY8E39U95mZMFGgaiU5FYDm0JL6SzsOtGbiniAT6Ij41 bM/XiuDuEuigvTjUQerTfUY/tt/VMnlYrb+LeqXxuOImU4N8bAE1kJ0sanRQrvKQuKoy mtPRWqhjydtEk7R036W+D9NJwqc/7WEf4m1SClsLwaq3HRuWy2vcwW8AmWTI2BJfgR2Q tNOapcH//Ws/5ozPCEtZb4I5+RtXzb/CVdwASDXk3m9H9nn8h6HuIbGlQhYrrcNQHueY Rxvs4lGgXrecmsokbSWyyCy1RI4bWBfXswrcELT6wThZB4HJCDQDXk2KoN7IuJmWnbc6 w1Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=apGNlPHMLigNtBSeUzNWO0H/WFlsuXBnp1vB8OAQE8o=; b=dnK+IBblDBUaVBIkukK5KN1rRhtkoLHhN1HzGkJ4eQ+16llwUF9DB4F+8KPZ5xWN4P A5OqANsQB18D29xUqCIhc2pPo3wVrVGlJ6IgacYlJl3BI/yi3l1HWNLtbb21pscno3mt hu1wObT/p6eNiReuPjWQpgT8FwrIa++wJBksUDUq6upbTmgWl50NwdyErkxrZJ8TBSla QETusrdXTyhv1qnNBWti8Ek76hsX7tzcIbFKsxD3cEzBGapYw+82Ws4awKjEDvv1EEmB M4D1T4LmUzAOYD5WDhwdOHQuBUd3T/Gm95RaWWlts9nEajvYMTuuAA8uvAjdpWv7INZI nGKg== X-Gm-Message-State: ALyK8tIzDfb+gIQledYQLV2iHPhAZVRy8zhGz25RJMSU4K9yf92+f374P391qhc2GPjn72/ANlQLAJnmeniWgw== X-Received: by 10.13.223.136 with SMTP id i130mr323793ywe.189.1467912825937; Thu, 07 Jul 2016 10:33:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.231.134 with HTTP; Thu, 7 Jul 2016 10:33:16 -0700 (PDT) From: "Mr. Jaehoon Paul Jeong" Date: Fri, 8 Jul 2016 02:33:16 +0900 Message-ID: To: "its@ietf.org" Content-Type: multipart/alternative; boundary=001a114e43cc8d4c0d05370f16b0 Archived-At: Subject: [its] A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 17:33:57 -0000 --001a114e43cc8d4c0d05370f16b0 Content-Type: text/plain; charset=UTF-8 Hi all, I have posted a new its I-D: - Title Survey on IP-based Vehicular Networking for Intelligent Transportation Systems - File https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey-00 - Abstract This document surveys the IP-based vehicular networks, which are considered a key component of Intelligent Transportation Systems (ITS). The main topics of vehicular networking are vehicle-to- vehicle (V2V), vehicle-to-infrastructure (V2I), and infrastructure- to-vehicle (I2V) networking. Vehicular networks deal with some critical aspects, such as IP address autoconfiguration, routing, handover, and mobility management. This document summarizes and analyzes the previous research activities that use IPv4 or IPv6 for vehicular networking" In this draft, we show the survey on IP-based Vehicular Networking for Intelligent Transportation Systems. This draft will be a good foundation to figure out the state-of-the-art schemes for IP-based vehicular networking, so we can use it for "ITS General Problem Area" that is one of work items in our its group: https://trac.tools.ietf.org/wg/its/trac/ It will be great for you to take a look at this I-D and give us comments or suggestions. Thanks. Best Regards, Paul -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a114e43cc8d4c0d05370f16b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
I have posted a new its I-D:
<= div>- Title
=C2=A0 =C2=A0Survey on IP-based Vehicular Networking = for Intelligent Transportation Systems=C2=A0

- Fil= e

- Abstrac= t
=C2=A0 =C2=A0This document surveys the IP-based vehicular netwo= rks, which are
=C2=A0 =C2=A0considered a key component of Intelli= gent Transportation Systems
=C2=A0 =C2=A0(ITS).=C2=A0 The main to= pics of vehicular networking are vehicle-to-
=C2=A0 =C2=A0vehicle= (V2V), vehicle-to-infrastructure (V2I), and infrastructure-
=C2= =A0 =C2=A0to-vehicle (I2V) networking.=C2=A0 Vehicular networks deal with s= ome
=C2=A0 =C2=A0critical aspects, such as IP address autoconfigu= ration, routing,
=C2=A0 =C2=A0handover, and mobility management.= =C2=A0 This document summarizes and
=C2=A0 =C2=A0analyzes the pre= vious research activities that use IPv4 or IPv6 for
=C2=A0 =C2=A0= vehicular networking"

In this draft, we show = the survey on IP-based Vehicular Networking=C2=A0
for Intelligent= Transportation Systems.=C2=A0
This draft will be a good foundati= on to figure out the state-of-the-art
schemes for IP-based vehicu= lar networking, so we can use it for
"ITS General Problem Ar= ea" that is one of work items in our its group:

It will be great for you to take a look= at this I-D and give us comments or suggestions.

= Thanks.

Best Regards,
Paul
--
<= div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon= (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Su= ngkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2= =A0pauljeong@skku.edu
Personal Homepage: http://iotlab.s= kku.edu/people-jaehoon-jeong.php
--001a114e43cc8d4c0d05370f16b0-- From nobody Fri Jul 8 01:55: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 E3DED12D513 for ; Fri, 8 Jul 2016 01:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 f8hxWhc_sMrl for ; Fri, 8 Jul 2016 01:55:22 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4852312D103 for ; Fri, 8 Jul 2016 01:55:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 2D1C2F42; Fri, 8 Jul 2016 10:55:21 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8HYpb4uVntHb; Fri, 8 Jul 2016 10:55:21 +0200 (CEST) Received: from [192.168.80.64] (unknown [212.128.32.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: josesanta) by xenon23.um.es (Postfix) with ESMTPSA id AB028F3F; Fri, 8 Jul 2016 10:55:20 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4CD4DE8C-3212-40C4-A063-3FD2AC9518E4" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: =?utf-8?Q?Jos=C3=A9_Santa_Lozano?= In-Reply-To: Date: Fri, 8 Jul 2016 10:55:19 +0200 Message-Id: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> References: To: "Mr. Jaehoon Paul Jeong" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 08:55:26 -0000 --Apple-Mail=_4CD4DE8C-3212-40C4-A063-3FD2AC9518E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Paul, Thanks for the work. Please consider the next comments and suggestions = of papers to add: 1- I think it would be interesting to also include a section about = security. Even though you have added a small note at the end of the = document, I think that probably some works in the area could arise. =46rom= our side we propose the next paper to add: Pedro J. Fern=C3=A1ndez, Jos=C3=A9 Santa, Fernando Bernal, Antonio F. = Skarmeta. Securing Vehicular IPv6 Communications. IEEE Transactions on = Dependable and Secure Computing, vol. 13, no. 1, pp. 46-58, 2016. In this paper we evaluate the usage of IPSec in vehicular (to = infrastructure) communications. 2- In the same line I think the document lacks in more evaluation = deployment works in the scientific literature. For sure, some of the = currently included papers include evaluations, but I think a concrete = section or an update with paper of this line would be beneficial to = people to understand the feasibility of IPv6 in vehicular = communications. =46rom our side we propose the next one: Jos=C3=A9 Santa, Pedro J. Fern=C3=A1ndez, Fernando Pere=C3=B1iguez, = Antonio F. Skarmeta. Deployment of Vehicular Networks in Highways Using = 802.11p and IPv6 Technologies. International Journal of Ad Hoc and = Ubiquitous Computing, in press these days, 2016. In this paper we present the work carried out in frames of the FOTsis = project to deploy real IPv6 vehicle-to-infrastructure networks around = Europe, together with the main evaluations performed. 3- In the document there is a lack in mentioning the synergy between = currently standardized architecture at ISO/ETSI and the usage of IPv6. = However, IEEE WAVE has been cited multitude of times. Our next paper = could help to improve this needed part of the document, which could be = probably added in the mobility management section: Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Fernando Bernal, = Pedro J. Fern=C3=A1ndez, Rafael Mar=C3=ADn-L=C3=B3pez, Antonio F. = Skarmeta. A Framework for Supporting Network Continuity in Vehicular = IPv6 Communications. IEEE Intelligent Transportation Systems Magazine, = vol. 6, no. 4, pp. 17-34, doi: 10.1109/MITS.2013.2274876, 2014. In this work we present an architecture that complements the ETSI/ISO = communication architecture by using IPv6 (IETF) technologies. 4- In all of our papers we transmit IPv6 packets over IEEE 802.11p, but = we have also tested the possibility of also sending ETSI CAM/DENM = messages over this platform by using UDP. This approach could be = interesting for the IETF ITS group. I am not completely sure about the = place to add this contribution, but in this case I doubt about the need = to create a new section, given that I am not sure if there are many = other works in this line. Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Antonio Morag=C3=B3= n, Antonio F. Skarmeta. Experimental Evaluation of CAM and DENM = Messaging Services in Vehicular Communications. Transportation Research = Part C: Emerging Technologies, vol. 2014, pp. 98-120, doi: = http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014. In this work we provide an implementation of the ETSI messaging = algorithm over our IPv6-o-11p basis. Please, let me know if you need further text, depending on the interest = you find in my previous suggestions. Regards, --=20 Jos=C3=A9 Santa Lozano Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones Facultad de Inform=C3=A1tica Universidad de Murcia 30100 Murcia, Spain Telf: +34-868-888771 / +34-868-884455 Fax: +34-868-884151 Web: http://ants.inf.um.es/~josesanta > El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong = escribi=C3=B3: >=20 > Hi all, > I have posted a new its I-D: > - Title > Survey on IP-based Vehicular Networking for Intelligent = Transportation Systems=20 >=20 > - File > = https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey-00= >=20 > - Abstract > This document surveys the IP-based vehicular networks, which are > considered a key component of Intelligent Transportation Systems > (ITS). The main topics of vehicular networking are vehicle-to- > vehicle (V2V), vehicle-to-infrastructure (V2I), and infrastructure- > to-vehicle (I2V) networking. Vehicular networks deal with some > critical aspects, such as IP address autoconfiguration, routing, > handover, and mobility management. This document summarizes and > analyzes the previous research activities that use IPv4 or IPv6 for > vehicular networking" >=20 > In this draft, we show the survey on IP-based Vehicular Networking=20 > for Intelligent Transportation Systems.=20 > This draft will be a good foundation to figure out the = state-of-the-art > schemes for IP-based vehicular networking, so we can use it for > "ITS General Problem Area" that is one of work items in our its group: > https://trac.tools.ietf.org/wg/its/trac/ >=20 > It will be great for you to take a look at this I-D and give us = comments or suggestions. >=20 > Thanks. >=20 > Best Regards, > Paul > --=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 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_4CD4DE8C-3212-40C4-A063-3FD2AC9518E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Paul,

Thanks for the work. Please consider the next = comments and suggestions of papers to add:

1-= I think it would be interesting to also include a section about security. Even though you have added a small note at the = end of the document, I think that probably some works in the area = could arise. =46rom our side we propose the next paper to add:

Pedro J. Fern=C3=A1ndez, Jos=C3=A9 Santa, = Fernando Bernal, Antonio F. Skarmeta. Securing Vehicular = IPv6 Communications. IEEE Transactions on Dependable and Secure = Computing, vol. 13, no. 1, pp. 46-58, 2016.

In this paper we evaluate the usage of = IPSec in vehicular (to infrastructure) communications.

2- In the same line I = think the document lacks in more evaluation deployment = works in the scientific literature. For sure, some of the currently = included papers include evaluations, but I think a concrete section or = an update with paper of this line would be beneficial to people to = understand the feasibility of IPv6 in vehicular communications. =46rom = our side we propose the next one:

Jos=C3=A9 Santa, Pedro J. Fern=C3=A1ndez,= Fernando Pere=C3=B1iguez, Antonio F. Skarmeta. Deployment of = Vehicular Networks in Highways Using 802.11p and IPv6 = Technologies. International Journal of Ad Hoc and Ubiquitous = Computing, in press these days, 2016.

In this paper we present the work = carried out in frames of the FOTsis project to deploy real IPv6 = vehicle-to-infrastructure networks around Europe, together with the main = evaluations performed.

3- In the document there is a lack in mentioning the synergy = between currently standardized architecture at ISO/ETSI = and the usage of IPv6. However, IEEE WAVE has been cited multitude = of times. Our next paper could help to improve this needed part of the = document, which could be probably added in the mobility management = section:

Jos=C3=A9= Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Fernando Bernal, Pedro J. = Fern=C3=A1ndez, Rafael Mar=C3=ADn-L=C3=B3pez, Antonio = F. Skarmeta. A Framework for Supporting Network Continuity in = Vehicular IPv6 Communications. IEEE Intelligent Transportation = Systems Magazine, vol. 6, no. 4, pp. 17-34, doi: = 10.1109/MITS.2013.2274876, 2014.

In this work we present an architecture = that complements the ETSI/ISO communication architecture by using IPv6 = (IETF) technologies.

4- In all of our papers we transmit IPv6 packets over IEEE = 802.11p, but we have also tested the possibility of also sending ETSI CAM/DENM messages over this platform by using UDP. This = approach could be interesting for the IETF ITS group. I am not = completely sure about the place to add this contribution, but in this = case I doubt about the need to create a new section, given that I am not = sure if there are many other works in this line.

Jos=C3=A9 Santa, Fernando = Pere=C3=B1iguez-Garc=C3=ADa, Antonio Morag=C3=B3n, Antonio F. = Skarmeta. Experimental Evaluation of CAM and DENM Messaging = Services in Vehicular Communications. Transportation Research Part C: = Emerging Technologies, vol. 2014, pp. 98-120, doi: http://dx.doi.org/10.1016/j.trc.2014.05.006, = 2014.

In this = work we provide an implementation of the ETSI messaging algorithm over = our IPv6-o-11p basis.

Please, let me know if you need further text, depending on = the interest you find in my previous suggestions.
Regards,

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



El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> escribi=C3=B3:
Hi all,
I have posted a new its I-D:
- Title
   Survey on IP-based = Vehicular Networking for Intelligent Transportation Systems 

- File
   https://tools.ietf.org/html/draft-jeong-its-vehicular-networkin= g-survey-00

- Abstract
   This document surveys the IP-based vehicular = networks, which are
   considered a key = component of Intelligent Transportation Systems
  =  (ITS).  The main topics of vehicular networking are = vehicle-to-
   vehicle (V2V), = vehicle-to-infrastructure (V2I), and infrastructure-
  =  to-vehicle (I2V) networking.  Vehicular networks deal with = some
   critical aspects, such as IP address = autoconfiguration, routing,
   handover, and = mobility management.  This document summarizes and
   analyzes the previous research activities that = use IPv4 or IPv6 for
   vehicular networking"

In this draft, we show the survey on IP-based = Vehicular Networking 
for Intelligent Transportation = Systems. 
This draft will be a good foundation to = figure out the state-of-the-art
schemes for IP-based = vehicular networking, so we can use it for
"ITS General = Problem Area" that is one of work items in our its group:
https://trac.tools.ietf.org/wg/its/trac/

It will be great for you to take a look at this I-D and give = us comments or suggestions.

Thanks.

Best Regards,
Paul
-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) = Jeong, Ph.D.
Assistant Professor
Department = of Software
Sungkyunkwan University
Office: = +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

= --Apple-Mail=_4CD4DE8C-3212-40C4-A063-3FD2AC9518E4-- From nobody Fri Jul 8 12:29: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 BA61712D0DC for ; Fri, 8 Jul 2016 12:29:33 -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 ulymCElgizZe for ; Fri, 8 Jul 2016 12:29:31 -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 55D1112D0AF for ; Fri, 8 Jul 2016 12:29:31 -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 u68JTTjI026319 for ; Fri, 8 Jul 2016 21:29:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 75ACE209813 for ; Fri, 8 Jul 2016 21:29:29 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6CAAF2095F0 for ; Fri, 8 Jul 2016 21:29:29 +0200 (CEST) Received: from [132.166.84.71] ([132.166.84.71]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u68JTS0E007112 for ; Fri, 8 Jul 2016 21:29:29 +0200 References: <20160708192608.32189.87306.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <20160708192608.32189.87306.idtracker@ietfa.amsl.com> Message-ID: <4a8e89da-93ca-4a03-f947-44ae2a6d7ff8@gmail.com> Date: Fri, 8 Jul 2016 21:29:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160708192608.32189.87306.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [its] Fwd: I-D Action: draft-haerri-ipv6-over-80211ocb-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: Fri, 08 Jul 2016 19:29:34 -0000 Hi, I just submitted this Internet Draft about IPv6-over-80211-OCB. It is a work together with my co-authors and we agree on many aspects. The distinctive aspect of this compared to other IPv6-over-80211-OCB draft is that it discusses security of IPv6 in vehicular communications context to more extent. Alex -------- Message transféré -------- Sujet : I-D Action: draft-haerri-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul 2016 12:26:08 -0700 De : internet-drafts@ietf.org Répondre à : internet-drafts@ietf.org Pour : i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transmission of IPv6 Packets over IEEE 802.11-OCB Networks Authors : Jérôme Härri Alexandre Petrescu Christian Huitema Filename : draft-haerri-ipv6-over-80211ocb-00.txt Pages : 11 Date : 2016-07-08 Abstract: This document describes the mechanisms required by IPv6 to be transmitted on IEEE 802.11 OCB networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haerri-ipv6-over-80211ocb/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-haerri-ipv6-over-80211ocb-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 From nobody Fri Jul 8 12:32:39 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C10D12D16F for ; Fri, 8 Jul 2016 12:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE8MvaxlNZuw for ; Fri, 8 Jul 2016 12:32:36 -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 E019112D0AD for ; Fri, 8 Jul 2016 12:32:35 -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 u68JWY71026812 for ; Fri, 8 Jul 2016 21:32:34 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5590B20989A for ; Fri, 8 Jul 2016 21:32:34 +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 4CAAE20987E for ; Fri, 8 Jul 2016 21:32:34 +0200 (CEST) Received: from [132.166.84.71] ([132.166.84.71]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u68JWYk8031793 for ; Fri, 8 Jul 2016 21:32:34 +0200 References: <20160708162843.32083.71266.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <20160708162843.32083.71266.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 8 Jul 2016 21:32:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160708162843.32083.71266.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [its] Fwd: I-D Action: draft-lee-its-ipv6-over-80211ocb-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: Fri, 08 Jul 2016 19:32:38 -0000 Hi, I have just submitted this Internet Draft about IPv6 over 802.11-OCB. The main aspect is that it tells what is the MTU size, and presents two possible Frame Formats noticed in ITS trials. Alex -------- Message transféré -------- Sujet : I-D Action: draft-lee-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul 2016 09:28:43 -0700 De : internet-drafts@ietf.org Répondre à : internet-drafts@ietf.org Pour : i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transmission of IPv6 Packets over the IEEE 802.11p OCB Mode Authors : Jong-Hyouk Lee Alexandre Petrescu Filename : draft-lee-its-ipv6-over-80211ocb-00.txt Pages : 5 Date : 2016-07-08 Abstract: This document describes the transmission of IPv6 packets over the IEEE 802.11p OCB mode. In particular it sets the MTU parameter and describes two alternative frame formats. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-lee-its-ipv6-over-80211ocb/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-lee-its-ipv6-over-80211ocb-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 From nobody Fri Jul 8 12:34: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 C901712D134 for ; Fri, 8 Jul 2016 12:33:58 -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 LgCjRfWjY13H for ; Fri, 8 Jul 2016 12:33:56 -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 6D40312D0AC for ; Fri, 8 Jul 2016 12:33:56 -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 u68JXswn013207 for ; Fri, 8 Jul 2016 21:33:54 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 266B520989A for ; Fri, 8 Jul 2016 21:33:54 +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 1DB7D2096B6 for ; Fri, 8 Jul 2016 21:33:54 +0200 (CEST) Received: from [132.166.84.71] ([132.166.84.71]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u68JXrZK032249 for ; Fri, 8 Jul 2016 21:33:53 +0200 References: <20160708155547.32197.48846.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <20160708155547.32197.48846.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 8 Jul 2016 21:33:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160708155547.32197.48846.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-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: Fri, 08 Jul 2016 19:33:59 -0000 Hi, I have just submitted this Internet Draft I co-author with Thierry Ernst. The distinctive aspect is that it tries to suggest the way MAC and IPv6 multicast is used on an IPv6-over-80211-OCB links. Alex -------- Message transféré -------- Sujet : I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul 2016 08:55:47 -0700 De : internet-drafts@ietf.org Répondre à : internet-drafts@ietf.org Pour : i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transmission of IPv6 Packets over IEEE 802.11-OCB Networks Authors : Thierry Ernst Alexandre Petrescu Filename : draft-ernst-its-ipv6-over-80211ocb-00.txt Pages : 5 Date : 2016-07-08 Abstract: In this document the mapping of multicast IPv6 addresses to MAC addresses of 802.11-OCB is proposed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ernst-its-ipv6-over-80211ocb/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ernst-its-ipv6-over-80211ocb-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 From nobody Fri Jul 8 14:34:49 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFB012D936 for ; Fri, 8 Jul 2016 14:34:47 -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 wdBXAp7qu_52 for ; Fri, 8 Jul 2016 14:34:45 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B787F12D92D for ; Fri, 8 Jul 2016 14:34:44 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id t190so16156096pfb.3 for ; Fri, 08 Jul 2016 14:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:references:cc:to; bh=NsHp7oSm+C3QJsGLN5+/RbTBM/Kj0ls7KbDSMLENZ+I=; b=NMozg7QbkCb8wJwU5mrEnzJp6MUjP4nxKUdW869Qel5lMIHPH8n8hkfyGqNWneQDaH Ogn3REiJoGb61oKC5rqZvkrKq2VM8JLpDhGtab4WCH2zA+lTjbTTTF/ZEW1rfk2s12bj Y4fZZ0XSM8XEZRD0jrMgYkR8ktMdVR87aV8oXUwmsoyCuI2OYYsGFx6vQqYmaOpLPk/s I7GTBVq4qjkkJASq5JwHrouFhMSDwdZU9nBBYIon8YJc6udd0UknRIwnPuoBQR3Xom7F G5U1WBJ2mmaA9uc55o6QAOWa1Evdthszu3kloKCSDCNF9OoeukxUJUB2NaGKzU06yjF6 Pd5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:cc:to; bh=NsHp7oSm+C3QJsGLN5+/RbTBM/Kj0ls7KbDSMLENZ+I=; b=eRtY/ByNEhzGcUFtX6msGxKNFz9ByCdI3Sily/DW/EVqa6Q/QsPxYJ6914DDeVemcu OimwzGBVBXn42J3o+ss7ZvkMFtkcSIgtvgA6JF5IstHeJYlVYU+RwpxWH/5fa+nc9isO lwn86WFtEen4rFR5Jeo+E2b8f6ayKC5zZiWLh1x8wYxUpTJPvZOCthx5zLmwq1TKqmo+ y/adiAlazoXEh+vbH3CPq1xpDCChs/wzbG10LCxklgnUwwNnkczOxNnmbDIRDow5fPjm TW/SqpXo7m/FFQw0VCSVRboiMbfCSTqpoT+jH6v7RSzlPK5JC2a9wNPmmoG73cv9aISc 0mpw== X-Gm-Message-State: ALyK8tLvDn3lfhtTgX62dNB359RWATIs1dky0KSPTBjSzZrAAOdjiVbh/v2DC9UNNgApxQ== X-Received: by 10.98.93.216 with SMTP id n85mr13467652pfj.36.1468013684188; Fri, 08 Jul 2016 14:34:44 -0700 (PDT) Received: from [172.17.150.57] ([211.217.43.21]) by smtp.gmail.com with ESMTPSA id h4sm6832322pfk.47.2016.07.08.14.34.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Jul 2016 14:34:43 -0700 (PDT) From: Jong-Hyouk Lee Content-Type: multipart/alternative; boundary="Apple-Mail=_9BEA2EEB-D671-4458-826A-305CA6642295" Message-Id: <7D309F07-89F9-4252-96F3-E4FD2B3B2FBC@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Sat, 9 Jul 2016 06:34:40 +0900 References: <20160708162843.32083.85157.idtracker@ietfa.amsl.com> To: its@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Alexandre Petrescu Subject: [its] Fwd: New Version Notification for draft-lee-its-ipv6-over-80211ocb-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: Fri, 08 Jul 2016 21:34:48 -0000 --Apple-Mail=_9BEA2EEB-D671-4458-826A-305CA6642295 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all A short and initial work regarding the transmission of IPv6 packets over = the IEEE 802.11p OCB Mode has been submitted: = https://tools.ietf.org/html/draft-lee-its-ipv6-over-80211ocb-00 = We're = going to update it continuously.=20 Thx. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-lee-its-ipv6-over-80211ocb-00.txt > Date: July 9, 2016 at 01:28:43 GMT+9 > To: "Jong-Hyouk Lee" , "Alexandre Petrescu" = , "Alexandre Petrescu" = >=20 >=20 > A new version of I-D, draft-lee-its-ipv6-over-80211ocb-00.txt > has been successfully submitted by Alexandre Petrescu and posted to = the > IETF repository. >=20 > Name: draft-lee-its-ipv6-over-80211ocb > Revision: 00 > Title: Transmission of IPv6 Packets over the IEEE = 802.11p OCB Mode > Document date: 2016-07-08 > Group: Individual Submission > Pages: 5 > URL: = https://www.ietf.org/internet-drafts/draft-lee-its-ipv6-over-80211ocb-00.t= xt > Status: = https://datatracker.ietf.org/doc/draft-lee-its-ipv6-over-80211ocb/ > Htmlized: = https://tools.ietf.org/html/draft-lee-its-ipv6-over-80211ocb-00 >=20 >=20 > Abstract: > This document describes the transmission of IPv6 packets over the > IEEE 802.11p OCB mode. In particular it sets the MTU parameter and > describes two alternative frame formats. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 --Apple-Mail=_9BEA2EEB-D671-4458-826A-305CA6642295 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all

A = short and initial work regarding the transmission of IPv6 packets over = the IEEE 802.11p OCB Mode has been submitted: https://tools.ietf.org/html/draft-lee-its-ipv6-over-80211ocb-00=  We're going to update it continuously. 

Thx.
= --
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-lee-its-ipv6-over-80211ocb-00.txt
Date: = July 9, 2016 at 01:28:43 = GMT+9
To: = "Jong-Hyouk Lee" <jonghyouk@smu.ac.kr>, "Alexandre Petrescu" <Alexandre.Petrescu@cea.fr>, "Alexandre Petrescu" = <alexandre.petrescu@cea.fr>

A new version of I-D, = draft-lee-its-ipv6-over-80211ocb-00.txt
has been = successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name: = draft-lee-its-ipv6-over-80211ocb
Revision: 00
Title:= = Transmission of IPv6 Packets over the IEEE 802.11p OCB Mode
Document date: 2016-07-08
Group:= = Individual Submission
Pages: 5
URL: =            https://www.ietf.org/internet-drafts/draft-lee-its-ipv6-over-80= 211ocb-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-lee-its-ipv6-over-80211o= cb/
Htmlized:       https://tools.ietf.org/html/draft-lee-its-ipv6-over-80211ocb-00=


Abstract:
=   This document describes the transmission of IPv6 packets = over the
  IEEE 802.11p OCB mode.  In = particular it sets the MTU parameter and
=   describes two alternative frame formats.




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.

The IETF Secretariat





= --Apple-Mail=_9BEA2EEB-D671-4458-826A-305CA6642295-- From nobody Mon Jul 11 05:22: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 2AF0D1288B8 for ; Mon, 11 Jul 2016 05:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.333 X-Spam-Level: X-Spam-Status: No, score=-4.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWYvWNvrb-OH for ; Mon, 11 Jul 2016 05:22:01 -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 AC76612B034 for ; Mon, 11 Jul 2016 05:22:00 -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 u6BCLwL1025332 for ; Mon, 11 Jul 2016 14:21:58 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C457820A1B6 for ; Mon, 11 Jul 2016 14:21:58 +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 BB8E220A1B4 for ; Mon, 11 Jul 2016 14:21:58 +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 u6BCLwTX014577 for ; Mon, 11 Jul 2016 14:21:58 +0200 To: its@ietf.org References: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> From: Alexandre Petrescu Message-ID: <327b204c-02eb-0a5a-0029-5d72e2aef69c@gmail.com> Date: Mon, 11 Jul 2016 14:21:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] CAM as UDP payload of IPv6 over 802.11p (was: A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems") X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 12:22:03 -0000 Hello José, Thank you for the message. There are many aspects you said that need to be considered. Let me reply to just one now. Le 08/07/2016 à 10:55, José Santa Lozano a écrit : [...] > 4- In all of our papers we transmit IPv6 packets over IEEE 802.11p, > but we have also tested the possibility of also sending ETSI > *CAM/DENM* messages over this platform by using UDP. This approach > could be interesting for the IETF ITS group. I am not completely sure > about the place to add this contribution, but in this case I doubt > about the need to create a new section, given that I am not sure if > there are many other works in this line. > > José Santa, Fernando Pereñiguez-García, Antonio Moragón, Antonio F. > Skarmeta. Experimental Evaluation of CAM and DENM Messaging Services > in Vehicular Communications. Transportation Research Part C: > Emerging Technologies, vol. 2014, pp. 98-120, doi: > http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014. > > In this work we provide an implementation of the ETSI messaging > algorithm over our IPv6-o-11p basis. > > Please, let me know if you need further text, depending on the > interest you find in my previous suggestions. The freely-avaliable paper is very important. It is probably the best example mentioning CAM being transported as payload of IPv6 over 802.11p. Literally it says: > CAM and DENM messages are exchanged between MR [MobileRouter] and AR > [AccessRouter] using UDP datagrams that are destined to the > well-known IPv6 multicast address referring to all the nodes present > on the local network segment (ff02::1). The use of this transport is > based on the fact that there is no sense in using a > connection-oriented transport since vehicles enter sporadically in > an AR communication range. It is a highly desirable behaviour exposing application-layer working together with a network layer over a link layer. Do you happen to have a packet dump available for this operation? (ideally in monitor mode). See more packet dumps in 802.11-OCB context at http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files What is the maximum size of a UDP packet thus sent? (other reports mention a max for CAM message of 102 bytes; others 300 bytes; they all fit within 802.11-OCB definition of max MTU 1500 bytes, but I want to make sure; also do you know at what size will 802.11OCB start to fragment - this can be seen in the wireshark monitor mode, 802.11 Data header, Flags "More Fragments"?) What is the src MAC address used? Because there may be a privacy worry of listeners along roads identifying which car uses which Organizational Unique Identifier. What is the dst MAC address used? The MAC address 33-33-0-0-0-0-1 is expected, but also are ff-ff-ff-ff-ff-ff, and "01-00-5E-" and "01-80-C2-". There is a need to decide which one of these to use, or maybe request a new one. This will help writing a single "IPv6-over-802.11-OCB" document which is the first goal in this group. Alex > > Regards, > > -- José Santa Lozano Dept. Ingeniería de la Información y las > Comunicaciones Facultad de Informática Universidad de Murcia 30100 > Murcia, Spain Telf: +34-868-888771 / +34-868-884455 Fax: > +34-868-884151 Web: http://ants.inf.um.es/~josesanta > > > >> El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong >> > escribió: >> >> Hi all, I have posted a new its I-D: - Title Survey on IP-based >> Vehicular Networking for Intelligent Transportation Systems >> >> - File >> >> https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey-00 >> >> >> >> >> - Abstract >> This document surveys the IP-based vehicular networks, which are >> considered a key component of Intelligent Transportation Systems >> (ITS). The main topics of vehicular networking are vehicle-to- >> vehicle (V2V), vehicle-to-infrastructure (V2I), and >> infrastructure- to-vehicle (I2V) networking. Vehicular networks >> deal with some critical aspects, such as IP address >> autoconfiguration, routing, handover, and mobility management. This >> document summarizes and analyzes the previous research activities >> that use IPv4 or IPv6 for vehicular networking" >> >> In this draft, we show the survey on IP-based Vehicular Networking >> for Intelligent Transportation Systems. This draft will be a good >> foundation to figure out the state-of-the-art schemes for IP-based >> vehicular networking, so we can use it for "ITS General Problem >> Area" that is one of work items in our its group: >> https://trac.tools.ietf.org/wg/its/trac/ >> >> It will be great for you to take a look at this I-D and give us >> comments or suggestions. >> >> Thanks. >> >> Best Regards, Paul -- =========================== Mr. Jaehoon >> (Paul) Jeong, Ph.D. Assistant Professor Department of Software >> Sungkyunkwan University Office: +82-31-299-4957 Email: >> jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: >> http://iotlab.skku.edu/people-jaehoon-jeong.php >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Mon Jul 11 09:49: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 70BFD12D599 for ; Mon, 11 Jul 2016 09:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1-5iMXDgxbu for ; Mon, 11 Jul 2016 09:49:07 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 3CCC312D0F6 for ; Mon, 11 Jul 2016 09:49:07 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id i12so96900467ywa.1 for ; Mon, 11 Jul 2016 09:49:07 -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=akB6a0VfFgMPSN/fBcd01p2sgdWXlyI38sD8XRcPPjk=; b=XWyErmThy5niPYKe+pAQO35NT2D9CENDZJrwyR6H8Hqx1+ZNQCUZdyb7KuoyAiiC6Y eG5qPd/acGGiwFqsyhUzosX/ABGARr0kk8YlscuNMQPOiN18KCB1x68O7+zFu1vuZMsw V80yHSX4YT9edN4sBeJdBhMEz/W9u6pLHCd3foKgBk9vaqvcNcYNR8urPkB3TZTFPyB9 eN72YReo/cgfRxZqCP/D9ZFqxxNeQ9lgHTxwtdgGeeEX+zNfIYy1UKB3HUGWX9zJdP/K ifN1ICtPMW2GFTcoga/nYlXljK9Te3fdC+2pwk2skiBq7f6IPOb6pXp8TCF8t5qDd+3a kHxg== 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=akB6a0VfFgMPSN/fBcd01p2sgdWXlyI38sD8XRcPPjk=; b=BfOR+PAZfYnE4KrjfUZjaxBW1AHNL4jKgmdRT2uC4eYlwQGE/w/HZhaECMYBm+pKv/ 70TSKmwvzAy3FI6WOQcY7FeDaesmDgNiSTEhVXCKSDWtcBYjyeu8i+SCVIta3767jElB tcHvF7epWSvJSyfBCEdRClVsapRNBj/WXNpiPsxouOaHiW0MNxyMcR1X3HzZcMG8FVjG LZ6JucO6APv56Fgg6hkZIzhxCZ6Km4J4OGWRMwqv2loz9M+46EdTEJHub5oR2qcweA/o yXCXu5MpJjUi/M5eP778CkKub1ZQUF6UJfDwX8sajhCLyYOOUF+gDz5fGx3DyJVnDdWx Zy1Q== X-Gm-Message-State: ALyK8tJBY1IqIpKUgZUVbKq2wlyt5nFsh43pO35TlfKPkd2AeKcDVJAmj+qCC2IlIzwPw/gZAEAdyv+KE5E5Gg== X-Received: by 10.13.252.66 with SMTP id m63mr14742673ywf.128.1468255746321; Mon, 11 Jul 2016 09:49:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.231.134 with HTTP; Mon, 11 Jul 2016 09:48:36 -0700 (PDT) In-Reply-To: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> References: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> From: "Mr. Jaehoon Paul Jeong" Date: Tue, 12 Jul 2016 01:48:36 +0900 Message-ID: To: =?UTF-8?Q?Jos=C3=A9_Santa_Lozano?= Content-Type: multipart/alternative; boundary=94eb2c06ac483309b805375eee7a Archived-At: Cc: "its@ietf.org" Subject: Re: [its] A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 16:49:10 -0000 --94eb2c06ac483309b805375eee7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jose, Thanks for your good comments and suggestions. My answers are inline below: On Fri, Jul 8, 2016 at 5:55 PM, Jos=C3=A9 Santa Lozano wr= ote: > Dear Paul, > > Thanks for the work. Please consider the next comments and suggestions of > papers to add: > > 1- I think it would be interesting to also include a section about > *security*. Even though you have added a small note at the end of the > document, I think that probably some works in the area could arise. From > our side we propose the next paper to add: > > Pedro J. Fern=C3=A1ndez, Jos=C3=A9 Santa, Fernando Bernal, Antonio F. > Skarmeta. Securing Vehicular IPv6 Communications. IEEE Transactions on > Dependable and Secure Computing, vol. 13, no. 1, pp. 46-58, 2016. > > In this paper we evaluate the usage of IPSec in vehicular (to > infrastructure) communications. > =3D> We authors are planning to add more papers (including your paper) for security and privacy to the next revision. > > 2- In the same line I think the document lacks in more *evaluation > deployment* works in the scientific literature. For sure, some of the > currently included papers include evaluations, but I think a concrete > section or an update with paper of this line would be beneficial to peopl= e > to understand the feasibility of IPv6 in vehicular communications. From o= ur > side we propose the next one: > > Jos=C3=A9 Santa, Pedro J. Fern=C3=A1ndez, Fernando Pere=C3=B1iguez, Anton= io F. > Skarmeta. Deployment of Vehicular Networks in Highways Using 802.11p and > IPv6 Technologies. International Journal of Ad Hoc and Ubiquitous > Computing, in press these days, 2016. > > In this paper we present the work carried out in frames of the FOTsis > project to deploy real IPv6 vehicle-to-infrastructure networks around > Europe, together with the main evaluations performed. > =3D> Sure. I agree that the evaluation for deployment is important. After reviewing your paper, we will consider to include your above paper into the next revision. > > 3- In the document there is a lack in mentioning the synergy between > currently standardized architecture at *ISO/ETSI and the usage of IPv6*. > However, IEEE WAVE has been cited multitude of times. Our next paper coul= d > help to improve this needed part of the document, which could be probably > added in the mobility management section: > > Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Fernando Bernal, P= edro J. > Fern=C3=A1ndez, Rafael Mar=C3=ADn-L=C3=B3pez, Antonio F. Skarmeta. A Fram= ework for > Supporting Network Continuity in Vehicular IPv6 Communications. > IEEE Intelligent Transportation Systems Magazine, vol. 6, no. 4, pp. 17-3= 4, > doi: 10.1109/MITS.2013.2274876, 2014. > > =3D> After reviewing your paper, we will also consider to include this paper in the next revision. > In this work we present an architecture that complements the ETSI/ISO > communication architecture by using IPv6 (IETF) technologies. > =3D> It seems like this work will be able to broaden the vehicular network architecture along with IEEE WAVE Standards. > > 4- In all of our papers we transmit IPv6 packets over IEEE 802.11p, but w= e > have also tested the possibility of also sending ETSI *CAM/DENM* messages > over this platform by using UDP. This approach could be interesting for t= he > IETF ITS group. I am not completely sure about the place to add this > contribution, but in this case I doubt about the need to create a new > section, given that I am not sure if there are many other works in this > line. > > Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Antonio Morag=C3= =B3n, Antonio F. > Skarmeta. Experimental Evaluation of CAM and DENM Messaging Services in > Vehicular Communications. Transportation Research Part C: > Emerging Technologies, vol. 2014, pp. 98-120, doi: > http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014. > > In this work we provide an implementation of the ETSI messaging algorithm > over our IPv6-o-11p basis. > > =3D> After reviewing the above paper, we will consider to include this paper to the next revision. > Please, let me know if you need further text, depending on the interest > you find in my previous suggestions. > =3D> Through the review of all of your papers, I will ask you further tex= t if needed. Thanks. Best Regards, Paul > Regards, > > -- > Jos=C3=A9 Santa Lozano > Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones > Facultad de Inform=C3=A1tica > Universidad de Murcia > 30100 Murcia, Spain > Telf: +34-868-888771 / +34-868-884455 > Fax: +34-868-884151 > Web: http://ants.inf.um.es/~josesanta > > > > El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong > escribi=C3=B3: > > Hi all, > I have posted a new its I-D: > - Title > Survey on IP-based Vehicular Networking for Intelligent Transportation > Systems > > - File > > https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey-0= 0 > > - Abstract > This document surveys the IP-based vehicular networks, which are > considered a key component of Intelligent Transportation Systems > (ITS). The main topics of vehicular networking are vehicle-to- > vehicle (V2V), vehicle-to-infrastructure (V2I), and infrastructure- > to-vehicle (I2V) networking. Vehicular networks deal with some > critical aspects, such as IP address autoconfiguration, routing, > handover, and mobility management. This document summarizes and > analyzes the previous research activities that use IPv4 or IPv6 for > vehicular networking" > > In this draft, we show the survey on IP-based Vehicular Networking > for Intelligent Transportation Systems. > This draft will be a good foundation to figure out the state-of-the-art > schemes for IP-based vehicular networking, so we can use it for > "ITS General Problem Area" that is one of work items in our its group: > https://trac.tools.ietf.org/wg/its/trac/ > > It will be great for you to take a look at this I-D and give us comments > or suggestions. > > Thanks. > > Best Regards, > Paul > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --94eb2c06ac483309b805375eee7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jose,
Thanks for your good comments and suggestions= .

My answers are inline below:

On Fri, Jul 8, 2016 = at 5:55 PM, Jos=C3=A9 Santa Lozano <josesanta@um.es> wrote:
Dear Paul,

Tha= nks for the work. Please consider the next comments and suggestions of pape= rs to add:

1- I think it would be interesting to also include a sect= ion about security. Even though you have added a small note at the e= nd of the document, I think that probably some=C2=A0works in the area could= arise. From our side we propose the next paper to add:

Pedro J. Fer= n=C3=A1ndez, Jos=C3=A9 Santa, Fernando Bernal, Antonio F. Skarmeta.=C2=A0Se= curing Vehicular IPv6=C2=A0Communications. IEEE Transactions on Dependable = and Secure Computing, vol. 13, no. 1, pp. 46-58, 2016.

I= n this paper we evaluate the usage of IPSec in vehicular (to infrastructure= ) communications.

=C2=A0=3D>= We authors are planning to add more papers (including your paper) for secu= rity and privacy to the next revision.

2- In the same line I think the d= ocument lacks in more evaluation deployment works in the scientific = literature. For sure, some of the currently included papers include evaluat= ions, but I think a concrete section or an update with paper of this line w= ould be beneficial to people to understand the feasibility of IPv6 in vehic= ular communications. From our side we propose the next one:

<= /div>
Jos=C3=A9 Santa, Pedro J. Fern=C3=A1ndez, Fernando Pere=C3=B1igue= z, Antonio F. Skarmeta.=C2=A0Deployment of Vehicular Networks in Highways U= sing 802.11p and IPv6 Technologies.=C2=A0International Journal of Ad Hoc an= d Ubiquitous Computing, in press these days, 2016.

In this paper we present the work carried out in frames of the FOTsis proj= ect to deploy real IPv6 vehicle-to-infrastructure networks around Europe, t= ogether with the main evaluations performed.
<= br>
=C2=A0=3D> Sure. I agree that the evaluation for deploymen= t is important.=C2=A0
=C2=A0 =C2=A0 =C2=A0 After reviewing your p= aper, we will consider to include your above paper into the next revision.<= /div>

3- In the document there is a lack in mentioning the synergy between cur= rently standardized architecture at ISO/ETSI and the usage of IPv6. = However, IEEE WAVE has been cited multitude of times. Our next paper could = help to improve this needed part of the document, which could be probably a= dded in the mobility management section:

Jos=C3=A9= Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Fernando Bernal, Pedro J. Fer= n=C3=A1ndez, Rafael Mar=C3=ADn-L=C3=B3pez, Antonio F.=C2=A0Skarmeta.=C2=A0A= Framework for Supporting Network Continuity in Vehicular IPv6 Communicatio= ns. IEEE=C2=A0Intelligent Transportation Systems Magazine, vol. 6, no. 4, p= p. 17-34, doi: 10.1109/MITS.2013.2274876, 2014.

<= /blockquote>
=C2=A0=3D>=C2=A0=C2=A0 After reviewing your paper, we w= ill also consider to include this paper in the next revision.
=C2= =A0 =C2=A0=C2=A0
=
In this work we present an architecture that complements th= e ETSI/ISO communication architecture by using IPv6 (IETF) technologies.
=C2=A0=3D> It seems like this work will be ab= le to broaden the vehicular network architecture along with IEEE WAVE Stand= ards.

4- In all of our papers we transmit IPv6 packets over IEEE 802.11p= , but we have also tested the possibility of also sending ETSI CAM/DENM<= /b> messages over this platform by using UDP. This approach could be intere= sting for the IETF ITS group. I am not completely sure about the place to a= dd this contribution, but in this case I doubt about the need to create a n= ew section, given that I am not sure if there are many other works in this = line.

Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Ga= rc=C3=ADa, Antonio Morag=C3=B3n, Antonio F. Skarmeta.=C2=A0Experimental Eva= luation of CAM=C2=A0and DENM Messaging Services in Vehicular Communications= . Transportation Research Part C: Emerging=C2=A0Technologies, vol. 2014, pp= . 98-120, doi: http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014.
<= div>
In this work we provide an implementation of the ETSI me= ssaging algorithm over our IPv6-o-11p basis.

=C2=A0=3D> After reviewing the above paper, we will consid= er to include this paper to the next revision.=C2=A0
=C2=A0=C2=A0=
= Please, let me know if you need further text, depending on the interest you= find in my previous suggestions.

=C2=A0=3D> =C2=A0Through the review of all of your papers, I will ask= you further text if needed.

=C2=A0 =C2=A0 =C2=A0 = =C2=A0Thanks.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Best Rega= rds,=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0Paul


Rega= rds,

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



<= /span>
El 7 jul 2016, a las= 19:33, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> escribi=C3=B3:

Hi= all,
I have posted a new its I-D:
- Title
=C2=A0 =C2=A0Survey on = IP-based Vehicular Networking for Intelligent Transportation Systems=C2=A0<= br>
- File
=C2=A0 =C2=A0https://tools.i= etf.org/html/draft-jeong-its-vehicular-networking-survey-00

- Ab= stract
=C2=A0 =C2=A0This document surveys the IP-based vehicular network= s, which are
=C2=A0 =C2=A0considered a key component of Intelligent Tran= sportation Systems
=C2=A0 =C2=A0(ITS).=C2=A0 The main topics of vehicula= r networking are vehicle-to-
=C2=A0 =C2=A0vehicle (V2V), vehicle-to-infr= astructure (V2I), and infrastructure-
=C2=A0 =C2=A0to-vehicle (I2V) netw= orking.=C2=A0 Vehicular networks deal with some
=C2=A0 =C2=A0critical as= pects, such as IP address autoconfiguration, routing,
=C2=A0 =C2=A0hando= ver, and mobility management.=C2=A0 This document summarizes and
=C2=A0 = =C2=A0analyzes the previous research activities that use IPv4 or IPv6 for=C2=A0 =C2=A0vehicular networking"

In this draft, we show the= survey on IP-based Vehicular Networking=C2=A0
for Intelligent Transport= ation Systems.=C2=A0
This draft will be a good foundation to figure out = the state-of-the-art
schemes for IP-based vehicular networking, so we ca= n use it for
"ITS General Problem Area" that is one of work it= ems in our its group:
https://trac.tools.ietf.org/wg/its/trac/

It= will be great for you to take a look at this I-D and give us comments or s= uggestions.

Thanks.

Best Regards,
Paul
--=C2=A0
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department= of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email= :=C2=A0jaehoon.= paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage:=C2=A0http://iotlab.sk= ku.edu/people-jaehoon-jeong.php
_______= ________________________________________
its mailing list
its@ietf.org
https://www.ietf.or= g/mailman/listinfo/its




--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.<= br>Assistant Professor
Department of Software
Sungkyunkwan University=
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@s= kku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-= jeong.php
--94eb2c06ac483309b805375eee7a-- From nobody Mon Jul 11 23:18: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 5EBD912B075 for ; Mon, 11 Jul 2016 23:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 K4qie-ZOy_iP for ; Mon, 11 Jul 2016 23:18:10 -0700 (PDT) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 56C5412B019 for ; Mon, 11 Jul 2016 23:18:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 158002E44; Tue, 12 Jul 2016 08:18:08 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0hE00UtbRVuP; Tue, 12 Jul 2016 08:18:07 +0200 (CEST) Received: from [192.168.1.36] (151.red-88-20-183.staticip.rima-tde.net [88.20.183.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: josesanta) by xenon22.um.es (Postfix) with ESMTPSA id 10CD324F3; Tue, 12 Jul 2016 08:18:04 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F97B2AC1-25AB-4B8D-951D-8687C8CE3034" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Jos=C3=A9_Santa_Lozano?= In-Reply-To: <327b204c-02eb-0a5a-0029-5d72e2aef69c@gmail.com> Date: Tue, 12 Jul 2016 08:18:03 +0200 Message-Id: References: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> <327b204c-02eb-0a5a-0029-5d72e2aef69c@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: its@ietf.org Subject: Re: [its] CAM as UDP payload of IPv6 over 802.11p (was: A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems") 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, 12 Jul 2016 06:18:14 -0000 --Apple-Mail=_F97B2AC1-25AB-4B8D-951D-8687C8CE3034 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Alexandre, According to the information we have of our tests, these are the values = you request: - The size of the UDP packet finally created is 36 bytes (UDP header+ = UDP payload). This is quite far from the theoretical 1500 bytes usually = taken as MTU, so we did not experience fragmentation. Ir our case, the = CAM messages created were quite simple for testing purposes. The fields = considered are detailed in the paper. - The source MAC address of the final frames was the MAC of the MR or = the AR. Hence, yes, it is a privacy weakness, but this paper was not = focused on security. - The destination MAC used we think it was the one used for IPv6 = multicasting, so 33:33=85 (we are searching for the dump files) Regards, --=20 Jos=E9 Santa Lozano Dept. Ingenier=EDa de la Informaci=F3n y las Comunicaciones Facultad de Inform=E1tica Universidad de Murcia 30100 Murcia, Spain Telf: +34-868-888771 / +34-868-884455 Fax: +34-868-884151 Web: http://ants.inf.um.es/~josesanta > El 11 jul 2016, a las 14:21, Alexandre Petrescu = escribi=F3: >=20 > Hello Jos=E9, >=20 > Thank you for the message. There are many aspects you said that need = to > be considered. Let me reply to just one now. >=20 > Le 08/07/2016 =E0 10:55, Jos=E9 Santa Lozano a =E9crit : > [...] >> 4- In all of our papers we transmit IPv6 packets over IEEE 802.11p, >> but we have also tested the possibility of also sending ETSI >> *CAM/DENM* messages over this platform by using UDP. This approach >> could be interesting for the IETF ITS group. I am not completely sure >> about the place to add this contribution, but in this case I doubt >> about the need to create a new section, given that I am not sure if >> there are many other works in this line. >>=20 >> Jos=E9 Santa, Fernando Pere=F1iguez-Garc=EDa, Antonio Morag=F3n, = Antonio F. >> Skarmeta. Experimental Evaluation of CAM and DENM Messaging Services >> in Vehicular Communications. Transportation Research Part C: >> Emerging Technologies, vol. 2014, pp. 98-120, doi: >> http://dx.doi.org/10.1016/j.trc.2014.05.006 = , 2014. >>=20 >> In this work we provide an implementation of the ETSI messaging >> algorithm over our IPv6-o-11p basis. >>=20 >> Please, let me know if you need further text, depending on the >> interest you find in my previous suggestions. >=20 > The freely-avaliable paper is very important. It is probably the > best example mentioning CAM being transported as payload > of IPv6 over 802.11p. Literally it says: >> CAM and DENM messages are exchanged between MR [MobileRouter] and AR >> [AccessRouter] using UDP datagrams that are destined to the >> well-known IPv6 multicast address referring to all the nodes present >> on the local network segment (ff02::1). The use of this transport is >> based on the fact that there is no sense in using a >> connection-oriented transport since vehicles enter sporadically in >> an AR communication range. >=20 > It is a highly desirable behaviour exposing application-layer working > together with a network layer over a link layer. >=20 > Do you happen to have a packet dump available for this operation? = (ideally in monitor mode). See more packet dumps in 802.11-OCB context = at = http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-fil= es = >=20 > What is the maximum size of a UDP packet thus sent? (other reports = mention a max for CAM message of 102 bytes; others 300 bytes; they all = fit within 802.11-OCB definition of max MTU 1500 bytes, but I want to = make sure; also do you know at what size will 802.11OCB start to = fragment - this can be seen in the wireshark monitor mode, 802.11 Data = header, Flags "More Fragments"?) >=20 > What is the src MAC address used? Because there may be a privacy = worry of listeners along roads identifying which car uses which = Organizational Unique Identifier. >=20 > What is the dst MAC address used? The MAC address 33-33-0-0-0-0-1 is = expected, but also are ff-ff-ff-ff-ff-ff, and "01-00-5E-" and = "01-80-C2-". There is a need to decide which one of these to use, or = maybe request a new one. >=20 > This will help writing a single "IPv6-over-802.11-OCB" document which = is the first goal in this group. >=20 > Alex >=20 >>=20 >> Regards, >>=20 >> -- Jos=E9 Santa Lozano Dept. Ingenier=EDa de la Informaci=F3n y las >> Comunicaciones Facultad de Inform=E1tica Universidad de Murcia 30100 >> Murcia, Spain Telf: +34-868-888771 / +34-868-884455 Fax: >> +34-868-884151 Web: http://ants.inf.um.es/~josesanta = >>=20 >>=20 >>=20 >>> El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong >>> = >> = escribi=F3: >>>=20 >>> Hi all, I have posted a new its I-D: - Title Survey on IP-based >>> Vehicular Networking for Intelligent Transportation Systems >>>=20 >>> - File >>>=20 >>> = https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey-00= >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 > - Abstract >>> This document surveys the IP-based vehicular networks, which are >>> considered a key component of Intelligent Transportation Systems >>> (ITS). The main topics of vehicular networking are vehicle-to- >>> vehicle (V2V), vehicle-to-infrastructure (V2I), and >>> infrastructure- to-vehicle (I2V) networking. Vehicular networks >>> deal with some critical aspects, such as IP address >>> autoconfiguration, routing, handover, and mobility management. This >>> document summarizes and analyzes the previous research activities >>> that use IPv4 or IPv6 for vehicular networking" >>>=20 >>> In this draft, we show the survey on IP-based Vehicular Networking >>> for Intelligent Transportation Systems. This draft will be a good >>> foundation to figure out the state-of-the-art schemes for IP-based >>> vehicular networking, so we can use it for "ITS General Problem >>> Area" that is one of work items in our its group: >>> https://trac.tools.ietf.org/wg/its/trac/ >>>=20 >>> It will be great for you to take a look at this I-D and give us >>> comments or suggestions. >>>=20 >>> Thanks. >>>=20 >>> Best Regards, Paul -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. Jaehoon >>> (Paul) Jeong, Ph.D. Assistant Professor Department of Software >>> Sungkyunkwan University Office: +82-31-299-4957 Email: >>> jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: >>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 >>=20 >> _______________________________________________ its mailing list >> its@ietf.org = https://www.ietf.org/mailman/listinfo/its = >>=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its = --Apple-Mail=_F97B2AC1-25AB-4B8D-951D-8687C8CE3034 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear Alexandre,

According to the information we have of our tests, these are = the values you request:

- The size of the UDP packet finally created is 36 bytes (UDP = header+ UDP payload). This is quite far from the theoretical 1500 bytes = usually taken as MTU, so we did not experience fragmentation. Ir our = case, the CAM messages created were quite simple for testing purposes. = The fields considered are detailed in the paper.

- The source MAC address of the final = frames was the MAC of the MR or the AR. Hence, yes, it is a privacy = weakness, but this paper was not focused on security.

- The destination MAC = used we think it was the one used for IPv6 multicasting, so 33:33=85 (we = are searching for the dump files)

Regards,

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



El 11 jul 2016, a las 14:21, Alexandre Petrescu <alexandre.petrescu@gmail.com> escribi=F3:

Hello Jos=E9,

Thank you for the message.  There are many = aspects you said that need to
be considered.  Let me reply to just = one now.

Le 08/07/2016 =E0 = 10:55, Jos=E9 Santa Lozano a =E9crit :
[...]
4- In all of our papers we transmit IPv6 packets over = IEEE 802.11p,
but we have also tested the possibility of = also sending ETSI
*CAM/DENM* messages over this platform = by using UDP. This approach
could be interesting for the = IETF ITS group. I am not completely sure
about the place = to add this contribution, but in this case I doubt
about = the need to create a new section, given that I am not sure if
there are many other works in this line.

Jos=E9 Santa, Fernando Pere=F1iguez-Garc=EDa, Antonio = Morag=F3n, Antonio F.
Skarmeta. Experimental Evaluation of = CAM and DENM Messaging Services
in Vehicular = Communications. Transportation Research Part C:
Emerging = Technologies, vol. 2014, pp. 98-120, doi:
http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014.

In this work we provide an implementation of = the ETSI messaging
algorithm over our IPv6-o-11p basis.

Please, let me know if you need further text, = depending on the
interest you find in my previous = suggestions.

The freely-avaliable paper is very = important.  It is probably the
best example mentioning CAM being = transported as payload
of IPv6 over 802.11p.  Literally it = says:
CAM and = DENM messages are exchanged between MR [MobileRouter] and AR
[AccessRouter] using UDP datagrams that are destined to = the
well-known IPv6 multicast address referring to all the = nodes present
on the local network segment (ff02::1). The = use of this transport is
based on the fact that there is = no sense in using a
connection-oriented transport since = vehicles enter sporadically in
an AR communication = range.

It is a highly desirable behaviour = exposing application-layer working
together with a network layer over a link = layer.

Do you happen to = have a packet dump available for this operation? (ideally in monitor = mode).  See more packet dumps in 802.11-OCB context at http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/= 44-test-files

What is the maximum = size of a UDP packet thus sent?  (other reports mention a max for = CAM message of 102 bytes; others 300 bytes; they all fit within = 802.11-OCB definition of max MTU 1500 bytes, but I want to make sure; = also do you know at what size will 802.11OCB start to fragment - this = can be seen in the wireshark monitor mode, 802.11 Data header, Flags = "More Fragments"?)

What is the src MAC = address used?  Because there may be a privacy worry of listeners = along roads identifying which car uses which Organizational Unique = Identifier.

What is the dst MAC = address used?  The MAC address 33-33-0-0-0-0-1 is expected, but = also are ff-ff-ff-ff-ff-ff, and "01-00-5E-" and "01-80-C2-".  There = is a need to decide which one of these to use, or maybe request a new = one.

This will help = writing a single "IPv6-over-802.11-OCB" document which is the first goal = in this group.

Alex


Regards,

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



El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong
<jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>> escribi=F3:

Hi all, I have posted a new its I-D: - Title = Survey on IP-based
Vehicular Networking for Intelligent = Transportation Systems

- File

https://tools.ietf.org/html/draft-jeong-its-vehicular-networkin= g-survey-00





- Abstract
This document = surveys the IP-based vehicular networks, which are
considered a key component of Intelligent Transportation = Systems
(ITS).  The main topics of vehicular = networking are vehicle-to-
vehicle (V2V), = vehicle-to-infrastructure (V2I), and
infrastructure- = to-vehicle (I2V) networking.  Vehicular networks
deal = with some critical aspects, such as IP address
autoconfiguration, routing, handover, and mobility = management. This
document summarizes and analyzes the = previous research activities
that use IPv4 or IPv6 for = vehicular networking"

In this draft, we = show the survey on IP-based Vehicular Networking
for = Intelligent Transportation Systems. This draft will be a good
foundation to figure out the state-of-the-art schemes for = IP-based
vehicular networking, so we can use it for "ITS = General Problem
Area" that is one of work items in our its = group:
https://trac.tools.ietf.org/wg/its/trac/

It will be great for you to take a look at this I-D and give = us
comments or suggestions.

Thanks.

Best Regards, Paul -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon
(Paul) Jeong, Ph.D. Assistant Professor = Department of Software
Sungkyunkwan University Office: = +82-31-299-4957 Email:
jaehoon.paul@gmail.com, = pauljeong@skku.edu Personal Homepage:
http://iotlab.skku.edu/people-jaehoon-jeong.php
_______________________________________________ its mailing = list
its@ietf.org = https://www.ietf.org/mailman/listinfo/its



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

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

= --Apple-Mail=_F97B2AC1-25AB-4B8D-951D-8687C8CE3034-- From nobody Tue Jul 12 06:06: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 18BA412DA3E for ; Tue, 12 Jul 2016 06:06:15 -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 r6rAXddk_dK0 for ; Tue, 12 Jul 2016 06:06:10 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9290212D8DA for ; Tue, 12 Jul 2016 05:59: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 u6CCxUgt008572 for ; Tue, 12 Jul 2016 14:59:30 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6DF88205813 for ; Tue, 12 Jul 2016 14:59:30 +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 64B31205808 for ; Tue, 12 Jul 2016 14:59:30 +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 u6CCxU8J004665 for ; Tue, 12 Jul 2016 14:59:30 +0200 To: its@ietf.org References: <20160708192608.32189.87306.idtracker@ietfa.amsl.com> <4a8e89da-93ca-4a03-f947-44ae2a6d7ff8@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 12 Jul 2016 14:59:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <4a8e89da-93ca-4a03-f947-44ae2a6d7ff8@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] Fwd: I-D Action: draft-haerri-ipv6-over-80211ocb-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, 12 Jul 2016 13:06:15 -0000 Sorry, I forgot to add "-its-" to this filename. But it is obviously dedicated to this group. Alex Le 08/07/2016 à 21:29, Alexandre Petrescu a écrit : > Hi, > > I just submitted this Internet Draft about IPv6-over-80211-OCB. > > It is a work together with my co-authors and we agree on many aspects. > > The distinctive aspect of this compared to other IPv6-over-80211-OCB > draft is that it discusses security of IPv6 in vehicular communications > context to more extent. > > Alex > > > -------- Message transféré -------- > Sujet : I-D Action: draft-haerri-ipv6-over-80211ocb-00.txt > Date : Fri, 8 Jul 2016 12:26:08 -0700 > De : internet-drafts@ietf.org > Répondre à : internet-drafts@ietf.org > Pour : i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Transmission of IPv6 Packets over IEEE > 802.11-OCB Networks > Authors : Jérôme Härri > Alexandre Petrescu > Christian Huitema > Filename : draft-haerri-ipv6-over-80211ocb-00.txt > Pages : 11 > Date : 2016-07-08 > > Abstract: > This document describes the mechanisms required by IPv6 to be > transmitted on IEEE 802.11 OCB networks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haerri-ipv6-over-80211ocb/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-haerri-ipv6-over-80211ocb-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 > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Tue Jul 12 08:46: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 8E49A12D158 for ; Tue, 12 Jul 2016 08:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 Hhcg9Eux41WU for ; Tue, 12 Jul 2016 08:46:13 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59C212D858 for ; Tue, 12 Jul 2016 08:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2974; q=dns/txt; s=iport; t=1468338049; x=1469547649; h=from:to:subject:date:message-id:mime-version; bh=Rhk6iTaoibcBKTA6JIXKfO7jPjwujRD+zfy+JCRV5Sk=; b=OY0wnCfJDWYpEwZgJH0yK2sqVbLj3nRYAc0RjYPituPo/lhcMW/xcHFq welJavpoGyNmKqITH5FzmVVG9z6X9wULEjr4sY9/VCj32TXjIDcr8gUvN ohvUOZBkPepO1gDyPFsipvJEQdYRlWF78q8K4LIiPGqCGbLVruqA8v47k E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAgA6DoVX/4QNJK1cgz5WgQKzf4UEg?= =?us-ascii?q?XkihhSBGTgUAQEBAQEBAWUcC4RjI2gBDAE9AgQwJwSIQw6hH49ijw0BAQEBAQE?= =?us-ascii?q?EAQEBAQEBAQEaBYYqgXgIhmARAYMdK4IvBZNdhT4Bhg6IRYFqhFmIa5ATAR42g?= =?us-ascii?q?3GIXjZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,352,1464652800"; d="scan'208,217";a="296956357" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jul 2016 15:40:49 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6CFemvY029960 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 12 Jul 2016 15:40:49 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 12 Jul 2016 11:40:48 -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.1210.000; Tue, 12 Jul 2016 11:40:48 -0400 From: "Carlos Pignataro (cpignata)" To: "its@ietf.org" Thread-Topic: ITS Berlin Draft Agenda Thread-Index: AQHR3FPDn+tXDt0RhEOYYu73bzC+Aw== Date: Tue, 12 Jul 2016 15:40:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.32.20] Content-Type: multipart/alternative; boundary="_000_FDCF3D6E5AF44844846E12A40AD29C32ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [its] ITS Berlin Draft Agenda 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, 12 Jul 2016 15:46:14 -0000 --_000_FDCF3D6E5AF44844846E12A40AD29C32ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldlIGp1c3QgcG9zdGVkIGEgZHJhZnQgYWdlbmRhIGZvciB0aGUgQm9GIHNlc3Npb24g aW4gQmVybGluOyBpdCBjYW4gYmUgZm91bmQgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9tZWV0aW5nLzk2L2FnZW5kYS9pdHMvLg0KDQpXZSBhcmUgc3RydWN0dXJpbmcgdGhlIG1lZXRp bmcgaW4gdGhvc2UgZm91ciBhcmVhcywgd2l0aCBhIHNwZWNpYWwgZm9jdXMgb24gdGhlIOKAnElQ djYgb3ZlciA4MDIuMTFw4oCdIGJsb2NrLg0KDQpJZiB5b3UgaGF2ZSBjb21tZW50cyBvbiB0aGUg YWdlbmRhLCBwbGVhc2Ugc2hhcmUgdGhvc2Ugb24gdGhlIGxpc3QuDQoNCklmIHlvdSB3b3VsZCBs aWtlIHRvIHJlcXVlc3QgYSB0aW1lc2xvdCBmb3IgdGhlIOKAnGlmIHRpbWUgcGVybWl0c+KAnSBi bG9jaywgcGxlYXNlIGVtYWlsIFJ1c3MgYW5kIEkgKGluY2x1ZGluZyBzdWJqZWN0LCBkcmFmdCwg YW5kIHRpbWUgcmVxdWVzdGVkKS4gSXQgd2lsbCBiZSBjb25zaWRlcmVkIGJ1dCBzdWJqZWN0IHRv IGZhbGxpbmcgb2ZmIHRoZSBhZ2VuZGEgaWYgd2UgdGhlIEJvRiBzcGVuZHMgbW9yZSB0aW1lIG9u IHRoZSBwcmV2aW91cyBibG9ja3MuDQoNClRoYW5rcyENCg0K4oCUIENhcmxvcyAmIFJ1c3MuDQo= --_000_FDCF3D6E5AF44844846E12A40AD29C32ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8DC519B98A090E49B4AE850C8AE02D8E@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSBqdXN0IHBvc3RlZCBhIGRyYWZ0 IGFnZW5kYSBmb3IgdGhlIEJvRiBzZXNzaW9uIGluIEJlcmxpbjsgaXQgY2FuIGJlIGZvdW5kIGF0 Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk2L2Fn ZW5kYS9pdHMvIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcv OTYvYWdlbmRhL2l0cy88L2E+LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2UgYXJlIHN0cnVjdHVyaW5nIHRoZSBtZWV0aW5nIGluIHRo b3NlIGZvdXIgYXJlYXMsIHdpdGggYSBzcGVjaWFsIGZvY3VzIG9uIHRoZSDigJxJUHY2IG92ZXIg ODAyLjExcOKAnSBibG9jay48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPklmIHlvdSBoYXZlIGNvbW1lbnRzIG9uIHRoZSBhZ2VuZGEsIHBs ZWFzZSBzaGFyZSB0aG9zZSBvbiB0aGUgbGlzdC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklmIHlvdSB3b3VsZCBsaWtlIHRvIHJlcXVl c3QgYSB0aW1lc2xvdCBmb3IgdGhlIOKAnGlmIHRpbWUgcGVybWl0c+KAnSBibG9jaywgcGxlYXNl IGVtYWlsIFJ1c3MgYW5kIEkgKGluY2x1ZGluZyBzdWJqZWN0LCBkcmFmdCwgYW5kIHRpbWUgcmVx dWVzdGVkKS4gSXQgd2lsbCBiZSBjb25zaWRlcmVkIGJ1dCBzdWJqZWN0IHRvIGZhbGxpbmcgb2Zm IHRoZSBhZ2VuZGEgaWYgd2UgdGhlIEJvRiBzcGVuZHMgbW9yZSB0aW1lIG9uIHRoZQ0KIHByZXZp b3VzIGJsb2Nrcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPlRoYW5rcyE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlCBDYXJsb3MgJmFtcDsgUnVzcy48L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_FDCF3D6E5AF44844846E12A40AD29C32ciscocom_-- From nobody Tue Jul 12 09:05: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 E13DE12D16C for ; Tue, 12 Jul 2016 09:05:57 -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 YaQooufKqFMA for ; Tue, 12 Jul 2016 09:05:56 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F005812D16D for ; Tue, 12 Jul 2016 09:05:55 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id i5so31541732wmg.0 for ; Tue, 12 Jul 2016 09:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=exrXDvKNeKuGfr2+UCcwx9YI4Z0UZAQV/bPaPdeCOqQ=; b=cmEbOV0OTPwzVcJssyDIAeApOza3uXK0mC+dn4VHJOg264wiBuXBWNMzNuYstHsgLW 1pRcm8pvOG98zSct5Jc2nJP0pavJlE5gg32B9HFNc9wDtH47LXH+4MnfZIXfnjSr7P69 9Y6Nm4fVSOPGmwNFOu7DjtjQ7vaUHbENN8+XsZVeyhDFKe3O7dgD1hH8v3cD+xvnDK1l UDCJWRnMC5bV4WrxWsUMBpxMnTMuK4ocxOnhGVxID/Ci+2BHeaqCYaIlVyxIVBaMUUrC ZN09ek38ttPq1H1wmKpgpyMqWebvKpS1Sn+sQOr0eMd0HQwGKWpuB6yapBtby/pFcQcg 9ASw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=exrXDvKNeKuGfr2+UCcwx9YI4Z0UZAQV/bPaPdeCOqQ=; b=hqC4bbGUA1QoKsSV91Ai+Q8Ac37/Wkqg3VR3M+Q7oS+YHFMzIMN0S9SMo9tJ86F94I +d3jonJkuuBP3CVK4cjmrdBh+NE1pTyUxM5OkzVV9ClzusrE0Gdom2Zb2BACoof+rW9i 5U9aBxIC7itM7rPi3nlDpIW/58VeE3TfNektyvGoKSU4bjguVaAF56Ahgv3upnVJaTjD bH1Knpbd8TB059qlVG65J+XqK/FIje2bwKWdqFhPy0hvdvHkvL+hIVCwM9gNdiIDQBES ng8beCQvwRrlKQnOgeFV5j+Oz3ycm9KIQL5ogCVV30EWdfgsB2U8knHl45jBU7ssRC2j Fb3w== X-Gm-Message-State: ALyK8tK2HpCuoOYReyy1kzt2ytLpf743/zllRMcJgWX97zqAyYSoYR2hkDjp47/5jKTukssEfGxpBt19Rd3RuQ== X-Received: by 10.28.9.213 with SMTP id 204mr22587401wmj.88.1468339554297; Tue, 12 Jul 2016 09:05:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.51.14 with HTTP; Tue, 12 Jul 2016 09:05:53 -0700 (PDT) From: Dapeng Liu Date: Wed, 13 Jul 2016 00:05:53 +0800 Message-ID: To: "its@ietf.org" Content-Type: multipart/alternative; boundary=001a11443e308b2c2b05377271ac Archived-At: Subject: [its] Fwd: New Version Notification for draft-petrescu-its-problem-03.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, 12 Jul 2016 16:05:58 -0000 --001a11443e308b2c2b05377271ac Content-Type: text/plain; charset=UTF-8 Hello all, We have submitted a new version of ITS problem statement draft. This version only fix some editorial errors. We are planning to include the problems statement of IPv6 ver 802.11p in the next version. Thanks, Dapeng Liu ---------- Forwarded message ---------- A new version of I-D, draft-petrescu-its-problem-03.txt has been successfully submitted by Dapeng Liu and posted to the IETF repository. Name: draft-petrescu-its-problem Revision: 03 Title: Problem Statement for IP in ITS use cases C-ACC and Platooning Document date: 2016-07-08 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-petrescu-its-problem-03.txt Status: https://datatracker.ietf.org/doc/draft-petrescu-its-problem/ Htmlized: https://tools.ietf.org/html/draft-petrescu-its-problem-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-petrescu-its-problem-03 Abstract: Two vehicle-to-vehicle communications use cases are discussed, namely Cooperative Adaptive Cruise Control (C-ACC) and Platooning. For these two use cases, the problems are identified that pertain to development with Internet protocols and connectivity. 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. The IETF Secretariat -- ------ Best Regards, Dapeng Liu --001a11443e308b2c2b05377271ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

We have submitted a new vers= ion of ITS problem statement draft. This version only fix some editorial er= rors.
We are planning to include the problems statement of IPv6 v= er 802.11p in the next version.

Thanks,
= Dapeng Liu
---------- Forwarded message -----= -----

A new version of I-D, draft-petrescu-its-problem-03.txt
has been successfully submitted by Dapeng Liu and posted to the
IETF repository.

Name:		draft-petrescu-its-problem
Revision:	03
Title:		Problem Statement for IP in ITS use cases C-ACC and Platooning
Document date:	2016-07-08
Group:		Individual Submission
Pages:		8
URL:            https://www.ietf.org/internet-dra=
fts/draft-petrescu-its-problem-03.txt
Status:         https://datatracker.ietf.org/doc/draft-petr=
escu-its-problem/
Htmlized:       https://tools.ietf.org/html/draft-petrescu-its=
-problem-03
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddr=
aft-petrescu-its-problem-03

Abstract:
   Two vehicle-to-vehicle communications use cases are discussed, namely
   Cooperative Adaptive Cruise Control (C-ACC) and Platooning.  For
   these two use cases, the problems are identified that pertain to
   development with Internet protocols and connectivity.

                                                                           =
      =20


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.

The IETF Secretariat
=20




--

------Best Regards,
Dapeng Liu
--001a11443e308b2c2b05377271ac-- From nobody Tue Jul 12 10:06:31 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D326A12D576 for ; Tue, 12 Jul 2016 10:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 S2_QF3FNei9k for ; Tue, 12 Jul 2016 10:06:26 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 29A2112D1B7 for ; Tue, 12 Jul 2016 10:06:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id C156743B14; Tue, 12 Jul 2016 19:06:24 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CkYYAlnGqRzu; Tue, 12 Jul 2016 19:06:24 +0200 (CEST) Received: from [192.168.1.36] (151.red-88-20-183.staticip.rima-tde.net [88.20.183.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: josesanta) by xenon21.um.es (Postfix) with ESMTPSA id 5318143B09; Tue, 12 Jul 2016 19:06:19 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E053BE74-31BF-4CEB-953F-D47BD61F96B0" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Jos=C3=A9_Santa_Lozano?= In-Reply-To: <45E6E584EBE2495EA455CD1487970A80@SRA5> Date: Tue, 12 Jul 2016 19:06:19 +0200 Message-Id: References: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> <45E6E584EBE2495EA455CD1487970A80@SRA5> To: dickroy@alum.mit.edu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Mr. Jaehoon Paul Jeong" , its@ietf.org Subject: Re: [its] A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems" 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, 12 Jul 2016 17:06:30 -0000 --Apple-Mail=_E053BE74-31BF-4CEB-953F-D47BD61F96B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dick, Probably our system did not pass any interop test, but this was not the = purpose of the research. Our intention was to implement and test a proof = of concept, and we are not pursuing a final system to be put in the = market. I simply noticed that this work could be of interest for the = group. Having said that, if this imply that I should rephrase the usage = of =E2=80=9CETSI CAM/DENM=E2=80=9D, I do not have any problem. We used = packets that could not be totally compliant. Regards, --=20 Jos=C3=A9 Santa Lozano Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones Facultad de Inform=C3=A1tica Universidad de Murcia 30100 Murcia, Spain Telf: +34-868-888771 / +34-868-884455 Fax: +34-868-884151 Web: http://ants.inf.um.es/~josesanta > El 12 jul 2016, a las 9:14, Dick Roy escribi=C3=B3= : >=20 > Jose, > =20 > Perhaps you could explain in a bit more detail what you mean by = =E2=80=9Calso sending ETSI CAM/DENM messages over this platform by using = UDP=E2=80=9D. As per previous postings, this is a very involved = procedure if you intend it to be compliant to =E2=80=9Ccurrent = thinking=E2=80=9D, and I am pretty sure you are not thinking along those = lines. > =20 > RR > =20 > From: Jos=C3=A9 Santa Lozano [mailto:josesanta@um.es]=20 > Sent: Friday, July 8, 2016 1:55 AM > To: Mr. Jaehoon Paul Jeong > Cc: its@ietf.org > Subject: Re: [its] A New I-D on "Survey on IP-based Vehicular = Networking for Intelligent Transportation Systems" > =20 > Dear Paul, >=20 > Thanks for the work. Please consider the next comments and suggestions = of papers to add: >=20 > 1- I think it would be interesting to also include a section about = security. Even though you have added a small note at the end of the = document, I think that probably some works in the area could arise. =46rom= our side we propose the next paper to add: >=20 > Pedro J. Fern=C3=A1ndez, Jos=C3=A9 Santa, Fernando Bernal, Antonio F. = Skarmeta. Securing Vehicular IPv6 Communications. IEEE Transactions on = Dependable and Secure Computing, vol. 13, no. 1, pp. 46-58, 2016. > =20 > In this paper we evaluate the usage of IPSec in vehicular (to = infrastructure) communications. > =20 > 2- In the same line I think the document lacks in more evaluation = deployment works in the scientific literature. For sure, some of the = currently included papers include evaluations, but I think a concrete = section or an update with paper of this line would be beneficial to = people to understand the feasibility of IPv6 in vehicular = communications. =46rom our side we propose the next one: > =20 > Jos=C3=A9 Santa, Pedro J. Fern=C3=A1ndez, Fernando Pere=C3=B1iguez, = Antonio F. Skarmeta. Deployment of Vehicular Networks in Highways Using = 802.11p and IPv6 Technologies. International Journal of Ad Hoc and = Ubiquitous Computing, in press these days, 2016. > =20 > In this paper we present the work carried out in frames of the FOTsis = project to deploy real IPv6 vehicle-to-infrastructure networks around = Europe, together with the main evaluations performed. > =20 > 3- In the document there is a lack in mentioning the synergy between = currently standardized architecture at ISO/ETSI and the usage of IPv6. = However, IEEE WAVE has been cited multitude of times. Our next paper = could help to improve this needed part of the document, which could be = probably added in the mobility management section: > =20 > Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Fernando = Bernal, Pedro J. Fern=C3=A1ndez, Rafael Mar=C3=ADn-L=C3=B3pez, Antonio = F. Skarmeta. A Framework for Supporting Network Continuity in Vehicular = IPv6 Communications. IEEE Intelligent Transportation Systems Magazine, = vol. 6, no. 4, pp. 17-34, doi: 10.1109/MITS.2013.2274876, 2014. > =20 > In this work we present an architecture that complements the ETSI/ISO = communication architecture by using IPv6 (IETF) technologies. > =20 > 4- In all of our papers we transmit IPv6 packets over IEEE 802.11p, = but we have also tested the possibility of also sending ETSI CAM/DENM = messages over this platform by using UDP. This approach could be = interesting for the IETF ITS group. I am not completely sure about the = place to add this contribution, but in this case I doubt about the need = to create a new section, given that I am not sure if there are many = other works in this line. > =20 > Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Antonio = Morag=C3=B3n, Antonio F. Skarmeta. Experimental Evaluation of CAM and = DENM Messaging Services in Vehicular Communications. Transportation = Research Part C: Emerging Technologies, vol. 2014, pp. 98-120, doi: = http://dx.doi.org/10.1016/j.trc.2014.05.006 = , 2014. > =20 > In this work we provide an implementation of the ETSI messaging = algorithm over our IPv6-o-11p basis. > =20 > Please, let me know if you need further text, depending on the = interest you find in my previous suggestions. > =20 > Regards, >=20 > --=20 > Jos=C3=A9 Santa Lozano > Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones > Facultad de Inform=C3=A1tica > Universidad de Murcia > 30100 Murcia, Spain > Telf: +34-868-888771 / +34-868-884455 > Fax: +34-868-884151 > Web: http://ants.inf.um.es/~josesanta = >=20 >=20 >=20 > El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong = > escribi=C3=B3: >=20 > Hi all, > I have posted a new its I-D: > - Title > Survey on IP-based Vehicular Networking for Intelligent = Transportation Systems=20 >=20 > - File > = https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey-00= = >=20 > - Abstract > This document surveys the IP-based vehicular networks, which are > considered a key component of Intelligent Transportation Systems > (ITS). The main topics of vehicular networking are vehicle-to- > vehicle (V2V), vehicle-to-infrastructure (V2I), and infrastructure- > to-vehicle (I2V) networking. Vehicular networks deal with some > critical aspects, such as IP address autoconfiguration, routing, > handover, and mobility management. This document summarizes and > analyzes the previous research activities that use IPv4 or IPv6 for > vehicular networking" >=20 > In this draft, we show the survey on IP-based Vehicular Networking=20 > for Intelligent Transportation Systems.=20 > This draft will be a good foundation to figure out the = state-of-the-art > schemes for IP-based vehicular networking, so we can use it for > "ITS General Problem Area" that is one of work items in our its group: > https://trac.tools.ietf.org/wg/its/trac/ >=20 > It will be great for you to take a look at this I-D and give us = comments or suggestions. >=20 > Thanks. >=20 > Best Regards, > Paul > --=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 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_E053BE74-31BF-4CEB-953F-D47BD61F96B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dick,

Probably our system did not pass any interop test, but this = was not the purpose of the research. Our intention was to implement and = test a proof of concept, and we are not pursuing a final system to be = put in the market. I simply noticed that this work could be of interest = for the group. Having said that, if this imply that I should rephrase = the usage of =E2=80=9CETSI CAM/DENM=E2=80=9D, I do not have any problem. = We used packets that could not be totally compliant.

Regards,

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



El 12 jul 2016, a las 9:14, Dick Roy <dickroy@alum.mit.edu> escribi=C3=B3:

Jose,
 
Perhaps you could explain in a bit more detail what = you mean by =E2=80=9Calso sending ETSI CAM/DENM messages over this platform = by using UDP=E2=80=9D. As per previous postings, this is a very = involved procedure if you intend it to be compliant to =E2=80=9Ccurrent = thinking=E2=80=9D, and I am pretty sure you are not thinking along those = lines.
 
RR
 
From: Jos=C3=A9 = Santa Lozano [mailto:josesanta@um.es] 
Sent: Friday, July 8, 2016 1:55 = AM
To: Mr. Jaehoon Paul Jeong
Cc: its@ietf.org
Subject: Re: [its] A New I-D on = "Survey on IP-based Vehicular Networking for Intelligent Transportation = Systems"
 
Dear Paul,

Thanks for the work. Please consider the next comments and = suggestions of papers to add:

1- I think it = would be interesting to also include a section about security. Even though = you have added a small note at the end of the document, I think that = probably some works in the area could arise. =46rom our side we = propose the next paper to add:

Pedro J. = Fern=C3=A1ndez, Jos=C3=A9 Santa, Fernando Bernal, Antonio F. = Skarmeta. Securing Vehicular IPv6 Communications. IEEE = Transactions on Dependable and Secure Computing, vol. 13, no. 1, pp. = 46-58, 2016.
 
In this paper we = evaluate the usage of IPSec in vehicular (to infrastructure) = communications.
 
2- In the same = line I think the document lacks in more evaluation = deployment works in the scientific = literature. For sure, some of the currently included papers include = evaluations, but I think a concrete section or an update with paper of = this line would be beneficial to people to understand the feasibility of = IPv6 in vehicular communications. =46rom our side we propose the next = one:
 
Jos=C3=A9 Santa, = Pedro J. Fern=C3=A1ndez, Fernando Pere=C3=B1iguez, Antonio F. = Skarmeta. Deployment of Vehicular Networks in Highways Using = 802.11p and IPv6 Technologies. International Journal of Ad Hoc and = Ubiquitous Computing, in press these days, 2016.
 
In this paper we = present the work carried out in frames of the FOTsis project to deploy = real IPv6 vehicle-to-infrastructure networks around Europe, together with the main evaluations = performed.
 
3- In the = document there is a lack in mentioning the synergy between currently = standardized architecture at ISO/ETSI and the usage of = IPv6. However, IEEE WAVE has been cited multitude of times. = Our next paper could help to improve this needed part of the document, = which could be probably added in the mobility management section:
 
Jos=C3=A9 Santa, = Fernando Pere=C3=B1iguez-Garc=C3=ADa, Fernando Bernal, Pedro J. = Fern=C3=A1ndez, Rafael Mar=C3=ADn-L=C3=B3pez, Antonio = F. Skarmeta. A Framework for Supporting Network Continuity in = Vehicular IPv6 Communications. IEEE Intelligent Transportation = Systems Magazine, vol. 6, no. 4, pp. 17-34, doi: = 10.1109/MITS.2013.2274876, 2014.
 
In this work we = present an architecture that complements the ETSI/ISO communication = architecture by using IPv6 (IETF) technologies.
 
4- In all of our = papers we transmit IPv6 packets over IEEE 802.11p, but we have also = tested the possibility of also sending ETSI CAM/DENM messages over this platform = by using UDP. This approach could be interesting for the IETF ITS group. = I am not completely sure about the place to add this contribution, but = in this case I doubt about the need to create a new section, given that = I am not sure if there are many other works in this line.
 
Jos=C3=A9 Santa, = Fernando Pere=C3=B1iguez-Garc=C3=ADa, Antonio Morag=C3=B3n, Antonio F. = Skarmeta. Experimental Evaluation of CAM and DENM Messaging Services in Vehicular = Communications. Transportation Research Part C: = Emerging Technologies, vol. 2014, pp. 98-120, doi: http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014.
 
In this work we = provide an implementation of the ETSI messaging algorithm over our = IPv6-o-11p basis.
 
Please, let me = know if you need further text, depending on the interest you find in my = previous suggestions.
 

Regards,

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



El 7 jul 2016, a las 19:33, Mr. = Jaehoon Paul Jeong <jaehoon.paul@gmail.com> escribi=C3=B3:
Hi all,
I have posted a new its I-D:
- Title
   Survey on IP-based = Vehicular Networking for Intelligent Transportation Systems 

- File
   https://tools.ietf.org/html/draft-jeong-its-vehicular-networkin= g-survey-00

- Abstract
   This document surveys the IP-based vehicular = networks, which are
   considered a key = component of Intelligent Transportation Systems
  =  (ITS).  The main topics of vehicular networking are = vehicle-to-
   vehicle (V2V), = vehicle-to-infrastructure (V2I), and infrastructure-
  =  to-vehicle (I2V) networking.  Vehicular networks deal with = some
   critical aspects, such as IP address = autoconfiguration, routing,
   handover, and = mobility management.  This document summarizes and
   analyzes the previous research activities that = use IPv4 or IPv6 for
   vehicular networking"

In this draft, we show the survey on IP-based = Vehicular Networking 
for Intelligent Transportation = Systems. 
This draft will be a good foundation to = figure out the state-of-the-art
schemes for IP-based = vehicular networking, so we can use it for
"ITS General = Problem Area" that is one of work items in our its group:
https://trac.tools.ietf.org/wg/its/trac/

It will be great for you to take a look at this I-D and give = us comments or suggestions.

Thanks.

Best Regards,
Paul
-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) = Jeong, Ph.D.
Assistant Professor
Department = of Software
Sungkyunkwan University
Office: = +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

= --Apple-Mail=_E053BE74-31BF-4CEB-953F-D47BD61F96B0-- From nobody Tue Jul 12 10:26:31 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8599B12D594 for ; Tue, 12 Jul 2016 10:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 dpV9JHE-fa97 for ; Tue, 12 Jul 2016 10:26:27 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1BF12D17B for ; Tue, 12 Jul 2016 10:26:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 824E443B0E; Tue, 12 Jul 2016 19:26:25 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8wOsdkp2BIWj; Tue, 12 Jul 2016 19:26:25 +0200 (CEST) Received: from [192.168.1.36] (151.red-88-20-183.staticip.rima-tde.net [88.20.183.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: josesanta) by xenon21.um.es (Postfix) with ESMTPSA id C4EA143B03; Tue, 12 Jul 2016 19:26:21 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E64EE021-29FD-46F6-8013-D231E1534505" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Jos=C3=A9_Santa_Lozano?= In-Reply-To: Date: Tue, 12 Jul 2016 19:26:20 +0200 Message-Id: <2393DF60-0ED8-45E2-898C-3C2363FC9B3F@um.es> References: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> <327b204c-02eb-0a5a-0029-5d72e2aef69c@gmail.com> To: dickroy@alum.mit.edu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: hjfischer@fischer-tech.eu, Alexandre Petrescu , knut.evensen@q-free.com, its@ietf.org Subject: Re: [its] CAM as UDP payload of IPv6 over 802.11p (was: A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems") 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, 12 Jul 2016 17:26:30 -0000 --Apple-Mail=_E64EE021-29FD-46F6-8013-D231E1534505 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please, see in line. > El 12 jul 2016, a las 8:52, Dick Roy escribi=C3=B3= : >=20 > =20 > =20 > From: Jos=C3=A9 Santa Lozano [mailto:josesanta@um.es = ]=20 > Sent: Monday, July 11, 2016 11:18 PM > To: Alexandre Petrescu > Cc: its@ietf.org > Subject: Re: [its] CAM as UDP payload of IPv6 over 802.11p (was: A New = I-D on "Survey on IP-based Vehicular Networking for Intelligent = Transportation Systems") > =20 > Dear Alexandre, > =20 > According to the information we have of our tests, these are the = values you request: > =20 > - The size of the UDP packet finally created is 36 bytes (UDP header+ = UDP payload).=20 > [RR>] FTR =E2=80=A6 UDP is a transport layer protocol, and PDUs = exchanged at that layer are called segments; packets are layer 3 PDUs. > This is quite far from the theoretical 1500 bytes usually taken as = MTU, > [RR>] For information, 1500 is the =E2=80=9Cframe=E2=80=9D limit two = layers lower (at the ethernet MAC / data link layer). =20 Thanks for this clarification. I though that talking in those terms was = clear for most of the participants. > so we did not experience fragmentation. Ir our case, the CAM messages = created were quite simple for testing purposes. The fields considered = are detailed in the paper. > [RR>] CAM messages generated at the CAM application will be on the = order of 400 bytes (this FPDU size includes the certificates). I have = no idea how your UDP segments including a representative CAM FPDU can be = 36 bytes unless they are empty.=20 As said, we tried to stick to the standard available at that moment, = only including the minimum information, but this was not essential for = our research, as I said in my previous mail. Sorry for any inconvenience = that this could cause. The packets created are detailed in the paper. > =20 > - The source MAC address of the final frames was the MAC of the MR or = the AR. Hence, yes, it is a privacy weakness, but this paper was not = focused on security. > [RR>] I do not understand. First, I think you mean transmitter = address since it=E2=80=99s an 802.11 frame without a source address = (ToDS and FromDS are both 0); it has only a transmitter and receiver = address and a BSSID (addr 3 field) which currently in 5.9GHz operations = in the US and Europe is constrained to be the wildcard (i.e. broadcast) = BSSID of all 1=E2=80=99s. Secondly, ARs are in RSUs not OBUs, and hence = do NOT tx CAMs.=20 You are right, our AR did not send CAMs, but for us both units comply = the same platform and they were configured to send DENM in other tests. = In this case the same MAC addressing procedure is used. > Third, the 5.9GHz CIs will be tumbling MAC addresses (and all other = identifiers simultaneously but that=E2=80=99s another story) to preserve = anonymity (at some level). We have gone to great lengths to eliminate = such weakness in the standards and products that have been and are being = built. =20 > =20 > - The destination MAC used we think it was the one used for IPv6 = multicasting, so 33:33=E2=80=A6 (we are searching for the dump files) > =20 > [RR>] I don=E2=80=99t understand this. IP addresses are layer 3 = addresses; MAC addresses are layer 2 addresses. What is meant by =E2=80=9C= a layer 2 address used for layer 3 addressing=E2=80=9D? =20 When a layer-3 packet is sent to a multicast address, the stack must = decide the MAC address to include in the layer-2 frame. > Either way, sending CAMs and DENMs to any MAC address other than the = layer 2 broadcast address of all 1=E2=80=99s is not likely to be = compliant going forward (check SAE J2945/1 for example).=20 That is something we did not deal with. > =20 > Hope this is helpful. > =20 > RR > =20 > Regards, > =20 > --=20 > Jos=C3=A9 Santa Lozano > Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones > Facultad de Inform=C3=A1tica > Universidad de Murcia > 30100 Murcia, Spain > Telf: +34-868-888771 / +34-868-884455 > Fax: +34-868-884151 > Web: http://ants.inf.um.es/~josesanta = > =20 > =20 > =20 >> El 11 jul 2016, a las 14:21, Alexandre Petrescu = > = escribi=C3=B3: >> =20 >> Hello Jos=C3=A9, >>=20 >> Thank you for the message. There are many aspects you said that need = to >> be considered. Let me reply to just one now. >>=20 >> Le 08/07/2016 =C3=A0 10:55, Jos=C3=A9 Santa Lozano a =C3=A9crit : >> [...] >>=20 >> 4- In all of our papers we transmit IPv6 packets over IEEE 802.11p, >> but we have also tested the possibility of also sending ETSI >> *CAM/DENM* messages over this platform by using UDP. This approach >> could be interesting for the IETF ITS group. I am not completely sure >> about the place to add this contribution, but in this case I doubt >> about the need to create a new section, given that I am not sure if >> there are many other works in this line. >>=20 >> Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Antonio = Morag=C3=B3n, Antonio F. >> Skarmeta. Experimental Evaluation of CAM and DENM Messaging Services >> in Vehicular Communications. Transportation Research Part C: >> Emerging Technologies, vol. 2014, pp. 98-120, doi: >> http://dx.doi.org/10.1016/j.trc.2014.05.006 = , 2014. >>=20 >> In this work we provide an implementation of the ETSI messaging >> algorithm over our IPv6-o-11p basis. >>=20 >> Please, let me know if you need further text, depending on the >> interest you find in my previous suggestions. >>=20 >> The freely-avaliable paper is very important. It is probably the >> best example mentioning CAM being transported as payload >> of IPv6 over 802.11p. Literally it says: >>=20 >> CAM and DENM messages are exchanged between MR [MobileRouter] and AR >> [AccessRouter] using UDP datagrams that are destined to the >> well-known IPv6 multicast address referring to all the nodes present >> on the local network segment (ff02::1). The use of this transport is >> based on the fact that there is no sense in using a >> connection-oriented transport since vehicles enter sporadically in >> an AR communication range. >>=20 >> It is a highly desirable behaviour exposing application-layer working >> together with a network layer over a link layer. >>=20 >> Do you happen to have a packet dump available for this operation? = (ideally in monitor mode). See more packet dumps in 802.11-OCB context = at = http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-fil= es = >>=20 >> What is the maximum size of a UDP packet thus sent? (other reports = mention a max for CAM message of 102 bytes; others 300 bytes; they all = fit within 802.11-OCB definition of max MTU 1500 bytes, but I want to = make sure; also do you know at what size will 802.11OCB start to = fragment - this can be seen in the wireshark monitor mode, 802.11 Data = header, Flags "More Fragments"?) >>=20 >> What is the src MAC address used? Because there may be a privacy = worry of listeners along roads identifying which car uses which = Organizational Unique Identifier. >>=20 >> What is the dst MAC address used? The MAC address 33-33-0-0-0-0-1 is = expected, but also are ff-ff-ff-ff-ff-ff, and "01-00-5E-" and = "01-80-C2-". There is a need to decide which one of these to use, or = maybe request a new one. >>=20 >> This will help writing a single "IPv6-over-802.11-OCB" document which = is the first goal in this group. >>=20 >> Alex >>=20 >>=20 >>=20 >> Regards, >>=20 >> -- Jos=C3=A9 Santa Lozano Dept. Ingenier=C3=ADa de la Informaci=C3=B3n = y las >> Comunicaciones Facultad de Inform=C3=A1tica Universidad de Murcia = 30100 >> Murcia, Spain Telf: +34-868-888771 / +34-868-884455 Fax: >> +34-868-884151 Web: http://ants.inf.um.es/~josesanta = >>=20 >>=20 >>=20 >>=20 >> El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong >> = >> = escribi=C3=B3: >>=20 >> Hi all, I have posted a new its I-D: - Title Survey on IP-based >> Vehicular Networking for Intelligent Transportation Systems >>=20 >> - File >>=20 >> = https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey-00= = >>=20 >>=20 >>=20 >>=20 >> - Abstract >>=20 >>> This document surveys the IP-based vehicular networks, which are >>> considered a key component of Intelligent Transportation Systems >>> (ITS). The main topics of vehicular networking are vehicle-to- >>> vehicle (V2V), vehicle-to-infrastructure (V2I), and >>> infrastructure- to-vehicle (I2V) networking. Vehicular networks >>> deal with some critical aspects, such as IP address >>> autoconfiguration, routing, handover, and mobility management. This >>> document summarizes and analyzes the previous research activities >>> that use IPv4 or IPv6 for vehicular networking" >>>=20 >>> In this draft, we show the survey on IP-based Vehicular Networking >>> for Intelligent Transportation Systems. This draft will be a good >>> foundation to figure out the state-of-the-art schemes for IP-based >>> vehicular networking, so we can use it for "ITS General Problem >>> Area" that is one of work items in our its group: >>> https://trac.tools.ietf.org/wg/its/trac/ = >>>=20 >>> It will be great for you to take a look at this I-D and give us >>> comments or suggestions. >>>=20 >>> Thanks. >>>=20 >>> Best Regards, Paul -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. Jaehoon >>> (Paul) Jeong, Ph.D. Assistant Professor Department of Software >>> Sungkyunkwan University Office: +82-31-299-4957 Email: >>> jaehoon.paul@gmail.com , = pauljeong@skku.edu Personal Homepage: >>> http://iotlab.skku.edu/people-jaehoon-jeong.php = >>> _______________________________________________ its mailing list >>> its@ietf.org = https://www.ietf.org/mailman/listinfo/its = >>=20 >>=20 >> _______________________________________________ its mailing list >> its@ietf.org = https://www.ietf.org/mailman/listinfo/its = >>=20 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its = > =20 --Apple-Mail=_E64EE021-29FD-46F6-8013-D231E1534505 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Please, see in line.


El 12 jul 2016, a las 8:52, Dick Roy <dickroy@alum.mit.edu> escribi=C3=B3:

 
 
From: Jos=C3=A9 = Santa Lozano [mailto:josesanta@um.es] 
Sent: Monday, July 11, 2016 11:18 = PM
To: Alexandre Petrescu
Cc: its@ietf.org
Subject: Re: [its] CAM as UDP payload of IPv6 over = 802.11p (was: A New I-D on "Survey on IP-based Vehicular Networking for = Intelligent Transportation Systems")
 
Dear = Alexandre,
 
According to the = information we have of our tests, these are the values you request:
 
- The size of the = UDP packet finally created is 36 bytes (UDP header+ UDP payload). 
[RR>] FTR =E2=80=A6 UDP is a transport layer protocol, and = PDUs exchanged at that layer are called segments; packets are layer 3 = PDUs.

This = is quite far from the theoretical 1500 bytes usually taken as MTU,
[RR>] For information, 1500 is the =E2=80=9Cframe=E2=80=9D = limit two layers lower (at the ethernet MAC / data link = layer).  
<= /div>

Thanks for = this clarification. I though that talking in those terms was clear for = most of the participants.

=

so we did not experience = fragmentation. Ir our case, the CAM messages created were quite = simple for testing purposes. The fields considered are detailed in the = paper.
[RR>] CAM messages generated at the CAM application will be on the = order of 400 bytes (this FPDU size includes the certificates).  I = have no idea how your UDP segments including a representative CAM FPDU can be 36 bytes unless = they are empty. 

As said, we tried to stick to the standard = available at that moment, only including the minimum information, but = this was not essential for our research, as I said in my previous mail. = Sorry for any inconvenience that this could cause. The packets created = are detailed in the paper.

 
- The source MAC = address of the final frames was the MAC of the MR or the AR. Hence, yes, = it is a privacy weakness, but this paper was not focused on = security.
[RR>] I do not understand.  First, I think you mean = transmitter address since it=E2=80=99s an 802.11 frame without a source = address (ToDS and FromDS are both 0); it has only a transmitter and = receiver address and a BSSID (addr 3 field) which currently in 5.9GHz = operations in the US and Europe is constrained to be the wildcard (i.e. = broadcast) BSSID of all 1=E2=80=99s.  Secondly, ARs are in RSUs not = OBUs, and hence do NOT tx CAMs.  =
=

You are right, our AR did not send CAMs, but for = us both units comply the same platform and they were configured to send = DENM in other tests. In this case the same MAC addressing procedure is = used.

Third, the 5.9GHz CIs will be = tumbling MAC addresses (and all other identifiers simultaneously but = that=E2=80=99s another story) to preserve anonymity (at some = level).  We have gone to great lengths to eliminate such weakness = in the standards and products that have been and are being = built.  
 
- The destination = MAC used we think it was the one used for IPv6 multicasting, so 33:33=E2=80= =A6 (we are searching for the dump files)
 
[RR>] I don=E2=80=99t understand this.  IP addresses = are layer 3 addresses; MAC addresses are layer 2 addresses. What is = meant by =E2=80=9Ca layer 2 address used for layer 3 addressing=E2=80=9D? =  

When a layer-3 packet is sent to a multicast = address, the stack must decide the MAC address to include in the layer-2 = frame.

Either way, sending CAMs and DENMs = to any MAC address other than the layer 2 broadcast address of all 1=E2=80= =99s is not likely to be compliant going forward (check SAE J2945/1 for = example). 
<= /div>

That is something we = did not deal with.

 
Hope this is helpful.
 
RR
  
Regards,
 
-- 
Jos=C3=A9 Santa Lozano
Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones
Facultad de Inform=C3=A1tica
Universidad de Murcia
30100 Murcia, Spain
Telf: +34-868-888771 / +34-868-884455
Fax: +34-868-884151
Web: http://ants.inf.um.es/~josesanta
 
 
 
El 11 jul 2016, a las 14:21, Alexandre Petrescu <alexandre.petrescu@gmail.com> escribi=C3=B3:
 
Hello Jos=C3=A9,

Thank you for the message.  There are many aspects you = said that need to
be considered.  Let me reply to just one now.

Le 08/07/2016 =C3=A0 10:55, Jos=C3=A9 Santa Lozano a =C3=A9crit= :
[...]

4- In all of our papers we transmit = IPv6 packets over IEEE 802.11p,
but we have also tested = the possibility of also sending ETSI
*CAM/DENM* messages = over this platform by using UDP. This approach
could be = interesting for the IETF ITS group. I am not completely sure
about the place to add this contribution, but in this case I = doubt
about the need to create a new section, given that I = am not sure if
there are many other works in this line.

Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3= =ADa, Antonio Morag=C3=B3n, Antonio F.
Skarmeta. = Experimental Evaluation of CAM and DENM Messaging = Services
in Vehicular Communications. Transportation = Research Part C:
Emerging Technologies, vol. 2014, pp. = 98-120, doi:
http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014.

In this work we provide an implementation of = the ETSI messaging
algorithm over our IPv6-o-11p basis.

Please, let me know if you need further text, = depending on the
interest you find in my previous = suggestions.

The freely-avaliable paper is very important.  It is = probably the
best example mentioning CAM being transported as = payload
of IPv6 over 802.11p.  Literally it says:

CAM and DENM messages are = exchanged between MR [MobileRouter] and AR
[AccessRouter] = using UDP datagrams that are destined to the
well-known = IPv6 multicast address referring to all the nodes present
on= the local network segment (ff02::1). The use of this transport is
based on the fact that there is no sense in using a
connection-oriented transport since vehicles enter = sporadically in
an AR communication range.

It is a highly desirable behaviour = exposing application-layer working
together with a network layer over a link = layer.

Do you happen to have a packet dump available for this = operation? (ideally in monitor mode).  See more packet dumps in = 802.11-OCB context at http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/= 44-test-files

What is the maximum size of a UDP packet thus sent? =  (other reports mention a max for CAM message of 102 bytes; others = 300 bytes; they all fit within 802.11-OCB definition of max MTU 1500 = bytes, but I want to make sure; also do you know at what size will = 802.11OCB start to fragment - this can be seen in the wireshark monitor = mode, 802.11 Data header, Flags "More Fragments"?)

What is the src MAC address used?  Because there may be = a privacy worry of listeners along roads identifying which car uses = which Organizational Unique Identifier.

What is the dst MAC address used?  The MAC address = 33-33-0-0-0-0-1 is expected, but also are ff-ff-ff-ff-ff-ff, and = "01-00-5E-" and "01-80-C2-".  There is a need to decide which one = of these to use, or maybe request a new one.

This will help writing a single "IPv6-over-802.11-OCB" = document which is the first goal in this group.

Alex



Regards,

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




El 7 jul = 2016, a las 19:33, Mr. Jaehoon Paul Jeong
<jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>> escribi=C3=B3:

Hi all, I have posted a new its I-D: - Title = Survey on IP-based
Vehicular Networking for Intelligent = Transportation Systems

- File

https://tools.ietf.org/html/draft-jeong-its-vehicular-networkin= g-survey-00




- Abstract

This = document surveys the IP-based vehicular networks, which are
considered a key component of Intelligent Transportation = Systems
(ITS).  The main topics of vehicular = networking are vehicle-to-
vehicle (V2V), = vehicle-to-infrastructure (V2I), and
infrastructure- = to-vehicle (I2V) networking.  Vehicular networks
deal = with some critical aspects, such as IP address
autoconfiguration, routing, handover, and mobility = management. This
document summarizes and analyzes the = previous research activities
that use IPv4 or IPv6 for = vehicular networking"

In this draft, we = show the survey on IP-based Vehicular Networking
for = Intelligent Transportation Systems. This draft will be a good
foundation to figure out the state-of-the-art schemes for = IP-based
vehicular networking, so we can use it for "ITS = General Problem
Area" that is one of work items in our its = group:
https://trac.tools.ietf.org/wg/its/trac/

It will be great for you to take a look at this I-D and give = us
comments or suggestions.

Thanks.

Best Regards, Paul -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon
(Paul) Jeong, Ph.D. Assistant Professor = Department of Software
Sungkyunkwan University Office: +82-31-299-4957 = Email:
jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage:
http://iotlab.skku.edu/people-jaehoon-jeong.php
_______________________________________________ its mailing = list
its@ietf.org https://www.ietf.org/mailman/listinfo/its




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


_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
 
=
= --Apple-Mail=_E64EE021-29FD-46F6-8013-D231E1534505-- From nobody Wed Jul 13 08:49:57 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2361D126FDC for ; Wed, 13 Jul 2016 08:49:56 -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 feG8vRN_tKrC for ; Wed, 13 Jul 2016 08:49:53 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0750412D14D for ; Wed, 13 Jul 2016 08:49:52 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id c2so20087794pfa.2 for ; Wed, 13 Jul 2016 08:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mm0soXvWTbUskxy9NlBb41dFeWVVYlihO+YUdH5zCas=; b=EwyrHNHyxbqyF02mRyC+hSXtQK/eoEkIlZiaGMqZblwJjqgD1TTHt9zg6pk/6/Qnz9 pewi0xO3n/vm6l/AqHZpPAwPwLyM/EhXkXJPWpFiOCS2rvFSaPtUNwDjCIbW+e0td8uK fMl+aoJZ9wg5I1Ruxd+TWzVAOtn1GldkjbmcLGqgXE1JavSvglFKpjKvJIw7S4E/dmxn G9C+yoU0b4U2Mbu0sKcU9TWjpOJkFE/5Iq107DOCq9ASrNQomgTAfqIsA+rn1xgfeLVq cygyiyG/ZaUMe6/rQj2LhuhuRhYVhFSUCpzrOYLYr77c459+raBUWJ8es+9fH+helX0G eCxA== 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=mm0soXvWTbUskxy9NlBb41dFeWVVYlihO+YUdH5zCas=; b=fkErli5NjR3Eb75783l2G4Z7Rbg1fKisxqBR5t/wIcsBWv8cNvZNhmIJeQ0we6CgVB FC1qEZUcYVrg6P9U7P6Xi6iPA6Xhxpk1baxgjba8OYuxmiJIJkohDtC9Q1dhRkeSP7nj 1LVXJ6rYipfScQJLj3btpjHoCkxIGYAwlCyVR87kGu85vdG1Qi0Kgb65x0K7TkXKXP0R 9TzZbtbT7QkxmOcFUJyqdnUt1e63qN1dQUyPBgGeuylKKXA4e7YLTf/pWvue9wZzzKGl di38dvhHry9d54mPnvHr2qwyeAzWqURI4aCkAOuetbMH4VT87B3MhCs2Xm3mBAIzpg5F vSXg== X-Gm-Message-State: ALyK8tJA9cugMKrL2YHXi2MLra2r/N0mK9Y9T8su9vuBYzrLofbdMOUaZtyWAhEcalFNIeXE6YJ1BuYug+8jww== X-Received: by 10.98.58.73 with SMTP id h70mr4496840pfa.125.1468424992355; Wed, 13 Jul 2016 08:49:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.220.135 with HTTP; Wed, 13 Jul 2016 08:49:51 -0700 (PDT) In-Reply-To: References: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> From: =?UTF-8?B?Qm9rb3IgTMOhc3psw7M=?= Date: Wed, 13 Jul 2016 17:49:51 +0200 Message-ID: To: "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary=94eb2c112a620c772a0537865642 Archived-At: Cc: "its@ietf.org" , =?UTF-8?Q?Jos=C3=A9_Santa_Lozano?= Subject: Re: [its] A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems" 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, 13 Jul 2016 15:49:56 -0000 --94eb2c112a620c772a0537865642 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Paul and All, besides Jose's suggestions I also would recommend an extension to section 7. (Mobility Management in Vehicular Networks). Solutions to efficiently support mobility in HetVNets seems to be important in the future, integrated solutions are required. Here you can find the preliminary results of our activities in this topic: N. Varga, L. Bokor and H. J. Fischer, "LDM-based dynamic network discovery and selection for IPv6 mobility management optimization in C-ITS environments," Models and Technologies for Intelligent Transportation Systems (MT-ITS), 2015 International Conference on, Budapest, 2015, pp. 483-490. doi: 10.1109/MTITS.2015.7223298 URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D7223298&isnumbe= r=3D7223230 Best regards, Laszlo -- L=C3=A1szl=C3=B3 BOKOR, Ph.D. Budapest University of Technology and Economics (BME) Department of Networked Systems and Services (HIT) Tel: +36-1-463-2048, Fax: +36-1-463-3263 web: http://medianets.hu/staff/laszlo-bokor/ 2016-07-11 18:48 GMT+02:00 Mr. Jaehoon Paul Jeong : > Hi Jose, > Thanks for your good comments and suggestions. > > My answers are inline below: > > On Fri, Jul 8, 2016 at 5:55 PM, Jos=C3=A9 Santa Lozano = wrote: > >> Dear Paul, >> >> Thanks for the work. Please consider the next comments and suggestions o= f >> papers to add: >> >> 1- I think it would be interesting to also include a section about >> *security*. Even though you have added a small note at the end of the >> document, I think that probably some works in the area could arise. From >> our side we propose the next paper to add: >> >> Pedro J. Fern=C3=A1ndez, Jos=C3=A9 Santa, Fernando Bernal, Antonio F. >> Skarmeta. Securing Vehicular IPv6 Communications. IEEE Transactions on >> Dependable and Secure Computing, vol. 13, no. 1, pp. 46-58, 2016. >> >> In this paper we evaluate the usage of IPSec in vehicular (to >> infrastructure) communications. >> > > =3D> We authors are planning to add more papers (including your paper) f= or > security and privacy to the next revision. > >> >> 2- In the same line I think the document lacks in more *evaluation >> deployment* works in the scientific literature. For sure, some of the >> currently included papers include evaluations, but I think a concrete >> section or an update with paper of this line would be beneficial to peop= le >> to understand the feasibility of IPv6 in vehicular communications. From = our >> side we propose the next one: >> >> Jos=C3=A9 Santa, Pedro J. Fern=C3=A1ndez, Fernando Pere=C3=B1iguez, Anto= nio F. >> Skarmeta. Deployment of Vehicular Networks in Highways Using 802.11p and >> IPv6 Technologies. International Journal of Ad Hoc and Ubiquitous >> Computing, in press these days, 2016. >> >> In this paper we present the work carried out in frames of the FOTsis >> project to deploy real IPv6 vehicle-to-infrastructure networks around >> Europe, together with the main evaluations performed. >> > > =3D> Sure. I agree that the evaluation for deployment is important. > After reviewing your paper, we will consider to include your above > paper into the next revision. > >> >> 3- In the document there is a lack in mentioning the synergy between >> currently standardized architecture at *ISO/ETSI and the usage of IPv6*. >> However, IEEE WAVE has been cited multitude of times. Our next paper cou= ld >> help to improve this needed part of the document, which could be probabl= y >> added in the mobility management section: >> >> Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Fernando Bernal, = Pedro J. >> Fern=C3=A1ndez, Rafael Mar=C3=ADn-L=C3=B3pez, Antonio F. Skarmeta. A Fra= mework for >> Supporting Network Continuity in Vehicular IPv6 Communications. >> IEEE Intelligent Transportation Systems Magazine, vol. 6, no. 4, pp. 17-= 34, >> doi: 10.1109/MITS.2013.2274876, 2014. >> >> =3D> After reviewing your paper, we will also consider to include thi= s > paper in the next revision. > > >> In this work we present an architecture that complements the ETSI/ISO >> communication architecture by using IPv6 (IETF) technologies. >> > =3D> It seems like this work will be able to broaden the vehicular netwo= rk > architecture along with IEEE WAVE Standards. > >> >> 4- In all of our papers we transmit IPv6 packets over IEEE 802.11p, but >> we have also tested the possibility of also sending ETSI *CAM/DENM* >> messages over this platform by using UDP. This approach could be >> interesting for the IETF ITS group. I am not completely sure about the >> place to add this contribution, but in this case I doubt about the need = to >> create a new section, given that I am not sure if there are many other >> works in this line. >> >> Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Antonio Morag=C3= =B3n, Antonio F. >> Skarmeta. Experimental Evaluation of CAM and DENM Messaging Services in >> Vehicular Communications. Transportation Research Part C: >> Emerging Technologies, vol. 2014, pp. 98-120, doi: >> http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014. >> >> In this work we provide an implementation of the ETSI messaging algorith= m >> over our IPv6-o-11p basis. >> >> =3D> After reviewing the above paper, we will consider to include this > paper to the next revision. > > >> Please, let me know if you need further text, depending on the interest >> you find in my previous suggestions. >> > > =3D> Through the review of all of your papers, I will ask you further t= ext > if needed. > > Thanks. > > Best Regards, > Paul > > >> Regards, >> >> -- >> Jos=C3=A9 Santa Lozano >> Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones >> Facultad de Inform=C3=A1tica >> Universidad de Murcia >> 30100 Murcia, Spain >> Telf: +34-868-888771 / +34-868-884455 >> Fax: +34-868-884151 >> Web: http://ants.inf.um.es/~josesanta >> >> >> >> El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong < >> jaehoon.paul@gmail.com> escribi=C3=B3: >> >> Hi all, >> I have posted a new its I-D: >> - Title >> Survey on IP-based Vehicular Networking for Intelligent Transportatio= n >> Systems >> >> - File >> >> https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey-= 00 >> >> - Abstract >> This document surveys the IP-based vehicular networks, which are >> considered a key component of Intelligent Transportation Systems >> (ITS). The main topics of vehicular networking are vehicle-to- >> vehicle (V2V), vehicle-to-infrastructure (V2I), and infrastructure- >> to-vehicle (I2V) networking. Vehicular networks deal with some >> critical aspects, such as IP address autoconfiguration, routing, >> handover, and mobility management. This document summarizes and >> analyzes the previous research activities that use IPv4 or IPv6 for >> vehicular networking" >> >> In this draft, we show the survey on IP-based Vehicular Networking >> for Intelligent Transportation Systems. >> This draft will be a good foundation to figure out the state-of-the-art >> schemes for IP-based vehicular networking, so we can use it for >> "ITS General Problem Area" that is one of work items in our its group: >> https://trac.tools.ietf.org/wg/its/trac/ >> >> It will be great for you to take a look at this I-D and give us comments >> or suggestions. >> >> Thanks. >> >> Best Regards, >> Paul >> -- >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Assistant Professor >> Department of Software >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> >> > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --94eb2c112a620c772a0537865642 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Paul and All,

besides Jose's s= uggestions I also would recommend an extension to section 7. (Mobility Mana= gement in Vehicular Networks). Solutions to efficiently support mobility in= HetVNets seems to be important in the future, integrated solutions are req= uired. Here you can find the preliminary results of our activities in this = topic:

N. Varga, L. Bokor and H. J. Fischer, = "LDM-based dynamic network discovery and selection for IPv6 mobility m= anagement optimization in C-ITS environments," Models and Technologies= for Intelligent Transportation Systems (MT-ITS), 2015 International Confer= ence on, Budapest, 2015, pp. 483-490.
doi: 10.1109/MTITS.2015.722= 3298

Best regards,
Laszlo

--
L=C3=A1szl=C3=B3 BOKOR, Ph.D.
= Budapest University of Technology and Economics (BME)
Department = of Networked Systems and Services (HIT)
Tel: +36-1-463-2048, Fax:= +36-1-463-3263



2016-07-11 18:48 GMT+02:00 Mr. Jaehoon Paul Jeong = <jaehoon.pau= l@gmail.com>:
Hi Jose,
Thanks for your good comments and suggestions.
<= br>
My answers are inline below:

On Fri, Jul 8,= 2016 at 5:55 PM, Jos=C3=A9 Santa Lozano <josesanta@um.es> wro= te:
Dear Paul,
<= br>Thanks for the work. Please consider the next comments and suggestions o= f papers to add:

1- I think it would be interesting to also include = a section about security. Even though you have added a small note at= the end of the document, I think that probably some=C2=A0works in the area= could arise. From our side we propose the next paper to add:

Pedro = J. Fern=C3=A1ndez, Jos=C3=A9 Santa, Fernando Bernal, Antonio F. Skarmeta.= =C2=A0Securing Vehicular IPv6=C2=A0Communications. IEEE Transactions on Dep= endable and Secure Computing, vol. 13, no. 1, pp. 46-58, 2016.

In this paper we evaluate the usage of IPSec in vehicular (to infras= tructure) communications.

=C2=A0=3D> We authors are planning to add more papers (including your = paper) for security and privacy to the next revision.

2= - In the same line I think the document lacks in more evaluation deploym= ent works in the scientific literature. For sure, some of the currently= included papers include evaluations, but I think a concrete section or an = update with paper of this line would be beneficial to people to understand = the feasibility of IPv6 in vehicular communications. From our side we propo= se the next one:

Jos=C3=A9 Santa, Pedro J. Fern=C3= =A1ndez, Fernando Pere=C3=B1iguez, Antonio F. Skarmeta.=C2=A0Deployment of = Vehicular Networks in Highways Using 802.11p and IPv6 Technologies.=C2=A0In= ternational Journal of Ad Hoc and Ubiquitous Computing, in press these days= , 2016.

In this paper we present the work carried = out in frames of the FOTsis project to deploy real IPv6 vehicle-to-infrastr= ucture networks around Europe, together with the main evaluations performed= .

=C2=A0=3D> Sure. I = agree that the evaluation for deployment is important.=C2=A0
=C2= =A0 =C2=A0 =C2=A0 After reviewing your paper, we will consider to include y= our above paper into the next revision.

3- In the docum= ent there is a lack in mentioning the synergy between currently standardize= d architecture at ISO/ETSI and the usage of IPv6. However, IEEE WAVE= has been cited multitude of times. Our next paper could help to improve th= is needed part of the document, which could be probably added in the mobili= ty management section:

Jos=C3=A9 Santa, Fernando P= ere=C3=B1iguez-Garc=C3=ADa, Fernando Bernal, Pedro J. Fern=C3=A1ndez, Rafae= l Mar=C3=ADn-L=C3=B3pez, Antonio F.=C2=A0Skarmeta.=C2=A0A Framework for Sup= porting Network Continuity in Vehicular IPv6 Communications. IEEE=C2=A0Inte= lligent Transportation Systems Magazine, vol. 6, no. 4, pp. 17-34, doi: 10.= 1109/MITS.2013.2274876, 2014.

=C2=A0=3D>=C2=A0=C2=A0 After reviewing your paper, we will also co= nsider to include this paper in the next revision.
=C2=A0 =C2=A0=C2=A0
In this work we present an architecture that compleme= nts the ETSI/ISO communication architecture by using IPv6 (IETF) technologi= es.
=C2=A0=3D> It seems like this wo= rk will be able to broaden the vehicular network architecture along with IE= EE WAVE Standards.

4- In all of our papers we transmit = IPv6 packets over IEEE 802.11p, but we have also tested the possibility of = also sending ETSI CAM/DENM messages over this platform by using UDP.= This approach could be interesting for the IETF ITS group. I am not comple= tely sure about the place to add this contribution, but in this case I doub= t about the need to create a new section, given that I am not sure if there= are many other works in this line.

Jos=C3=A9 Sant= a, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Antonio Morag=C3=B3n, Antonio F. S= karmeta.=C2=A0Experimental Evaluation of CAM=C2=A0and DENM Messaging Servic= es in Vehicular Communications. Transportation Research Part C: Emerging=C2= =A0Technologies, vol. 2014, pp. 98-120, doi: http://dx.doi.org/10.1016/j.trc= .2014.05.006, 2014.

In this work we provide an= implementation of the ETSI messaging algorithm over our IPv6-o-11p basis.<= /div>

=C2=A0=3D> After revi= ewing the above paper, we will consider to include this paper to the next r= evision.=C2=A0
=C2=A0=C2=A0
Please, let me know i= f you need further text, depending on the interest you find in my previous = suggestions.

=C2=A0=3D&g= t; =C2=A0Through the review of all of your papers, I will ask you further t= ext if needed.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks.<= /div>

=C2=A0 =C2=A0 =C2=A0 =C2=A0Best Regards,=C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0Paul


Regards,<= span>

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



El 7 jul 2016, a las 19:33, Mr. Jaehoon Pa= ul Jeong <ja= ehoon.paul@gmail.com> escribi=C3=B3:

Hi all,
I have posted= a new its I-D:
- Title
=C2=A0 =C2=A0Survey on IP-based Vehicular Net= working for Intelligent Transportation Systems=C2=A0

- File
=C2= =A0 =C2=A0https://tools.ietf.org/html/draft-j= eong-its-vehicular-networking-survey-00

- Abstract
=C2=A0 =C2= =A0This document surveys the IP-based vehicular networks, which are
=C2= =A0 =C2=A0considered a key component of Intelligent Transportation Systems<= br>=C2=A0 =C2=A0(ITS).=C2=A0 The main topics of vehicular networking are ve= hicle-to-
=C2=A0 =C2=A0vehicle (V2V), vehicle-to-infrastructure (V2I), a= nd infrastructure-
=C2=A0 =C2=A0to-vehicle (I2V) networking.=C2=A0 Vehic= ular networks deal with some
=C2=A0 =C2=A0critical aspects, such as IP a= ddress autoconfiguration, routing,
=C2=A0 =C2=A0handover, and mobility m= anagement.=C2=A0 This document summarizes and
=C2=A0 =C2=A0analyzes the = previous research activities that use IPv4 or IPv6 for
=C2=A0 =C2=A0vehi= cular networking"

In this draft, we show the survey on IP-based= Vehicular Networking=C2=A0
for Intelligent Transportation Systems.=C2= =A0
This draft will be a good foundation to figure out the state-of-the-= art
schemes for IP-based vehicular networking, so we can use it for
&= quot;ITS General Problem Area" that is one of work items in our its gr= oup:
https://trac.tools.ietf.org/wg/its/trac/

It will be great fo= r you to take a look at this I-D and give us comments or suggestions.
Thanks.

Best Regards,
Paul
--=C2=A0
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon= (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Su= ngkyunkwan University
Office: +82-31-299-4957
Email:=C2=A0jaehoon.paul@gmail.com= ,=C2=A0pauljeon= g@skku.edu
Personal Homepage:=C2=A0http://iotlab.skku.edu/people-= jaehoon-jeong.php
________________________________= _______________
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


--94eb2c112a620c772a0537865642-- From nobody Mon Jul 18 03:13:22 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A07312D7A3 for ; Mon, 18 Jul 2016 03:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 TIWyt6dPud1B for ; Mon, 18 Jul 2016 03:13:20 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 2F84412D7B0 for ; Mon, 18 Jul 2016 03:13:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 46FA3621B5 for ; Mon, 18 Jul 2016 06:13:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eLDQxwVEIOv2 for ; Mon, 18 Jul 2016 06:13:08 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-a0d9.meeting.ietf.org [31.133.160.217]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id B4D1062190 for ; Mon, 18 Jul 2016 06:13:07 -0400 (EDT) To: its@ietf.org From: Robert Moskowitz Message-ID: Date: Mon, 18 Jul 2016 12:12:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------4390D2AB0430EAB2AA34A5F2" Archived-At: Subject: [its] 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, 18 Jul 2016 10:13:21 -0000 This is a multi-part message in MIME format. --------------4390D2AB0430EAB2AA34A5F2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I am new to this list. I worked, a bit, on both IEEE 802.11p an 1609. I am currently working on a contract for General Motors on automotive Ethernet security (a little orthogonal to this work, perhaps. M0re 802.1 issues). In the draft you state: "In the future, some vehicle communications may not use IP for exchanging safety messages with other vehicles and infrastructure." IEEE 1609.3 does define IPv6 configuration, but does not mandate it. "5.3 Internet Protocol version 6 Support for IPv6 is conditionally mandatory as specified in 5.1. An IPv6 implementation shall comply with IETF RFC 2460. Related features defined in other RFCs are specified in 6.5. IP traffic is sent and received through the LLC sublayer as specified in 5.2." You have to have it, but don't have to use it. There will well be non-IP safety messages. I feel you need to fix this text in the charter. --------------4390D2AB0430EAB2AA34A5F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I am new to this list.  I worked, a bit, on both IEEE 802.11p an 1609.  I am currently working on a contract for General Motors on automotive Ethernet security (a little orthogonal to this work, perhaps.  M0re 802.1 issues).


In the draft you state:

"In the future, some vehicle communications may not use IP for exchanging safety messages with other vehicles and infrastructure."

IEEE 1609.3 does define IPv6 configuration, but does not mandate it.


"5.3 Internet Protocol version 6

Support for IPv6 is conditionally mandatory as specified in 5.1. An IPv6 implementation shall comply with IETF RFC 2460. Related features defined in other RFCs are specified in 6.5. IP traffic is sent and received through the LLC sublayer as specified in 5.2."


You have to have it, but don't have to use it.  There will well be non-IP safety messages.


I feel you need to fix this text in the charter.



--------------4390D2AB0430EAB2AA34A5F2-- From nobody Mon Jul 18 03:28:53 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C653412D82B for ; Mon, 18 Jul 2016 03:28:51 -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 RU2_rkT_w17f for ; Mon, 18 Jul 2016 03:28:49 -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 9E3F612D80B for ; Mon, 18 Jul 2016 03:28:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 80F32300577 for ; Mon, 18 Jul 2016 06:28:47 -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 10026) with ESMTP id E6WiTl3JJuhP for ; Mon, 18 Jul 2016 06:28:46 -0400 (EDT) Received: from [5.5.33.52] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 25A90300291; Mon, 18 Jul 2016 06:28:44 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_80076B31-2215-4A88-ACF1-8B51A3A3BF70" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Mon, 18 Jul 2016 06:28:43 -0400 Message-Id: References: To: Robert Moskowitz X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: its@ietf.org Subject: Re: [its] 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, 18 Jul 2016 10:28:52 -0000 --Apple-Mail=_80076B31-2215-4A88-ACF1-8B51A3A3BF70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Bob: I do not understand the text that you want changed. The current charter = text is here: https://trac.tools.ietf.org/wg/its/trac/. Can you propose = alternate text? More below... Russ On Jul 18, 2016, at 6:12 AM, Robert Moskowitz = wrote: > I am new to this list. I worked, a bit, on both IEEE 802.11p an 1609. = I am currently working on a contract for General Motors on automotive = Ethernet security (a little orthogonal to this work, perhaps. M0re = 802.1 issues). >=20 >=20 > In the draft you state: >=20 > "In the future, some vehicle communications may not use IP for = exchanging safety messages with other vehicles and infrastructure." >=20 > IEEE 1609.3 does define IPv6 configuration, but does not mandate it.=20= >=20 Right. You are confirming that the =93may not=94 is correct. >=20 > "5.3 Internet Protocol version 6 >=20 > Support for IPv6 is conditionally mandatory as specified in 5.1. An = IPv6 implementation shall comply with IETF RFC 2460. Related features = defined in other RFCs are specified in 6.5. IP traffic is sent and = received through the LLC sublayer as specified in 5.2." >=20 > You have to have it, but don't have to use it. There will well be = non-IP safety messages. >=20 > I feel you need to fix this text in the charter. >=20 Yes, there will be non-IP safety messages, and the are not part of our = scope. --Apple-Mail=_80076B31-2215-4A88-ACF1-8B51A3A3BF70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Bob:

I do not understand the text = that you want changed.  The current charter text is here: https://trac.tools.ietf.= org/wg/its/trac/.  Can you propose alternate = text?

More = below...

Russ


<= div>On Jul 18, 2016, at 6:12 AM, Robert Moskowitz <rgm-ietf@htt-consult.com> = wrote:

=20 =20

I am new to this = list.  I worked, a bit, on both IEEE 802.11p an 1609.  I am currently working on a contract for General = Motors on automotive Ethernet security (a little orthogonal to this work, perhaps.  M0re 802.1 issues).


In the draft you state:

"In the future, = some vehicle communications may not use IP for exchanging safety messages with other vehicles and infrastructure."

IEEE 1609.3 does define IPv6 configuration, = but does not mandate it.


Right.  You are = confirming that the =93may not=94 is correct.


"5.3 Internet Protocol version 6

Support for IPv6 is conditionally mandatory as specified in 5.1. An IPv6 implementation shall comply with IETF RFC 2460. Related features defined in other RFCs are specified in 6.5. IP traffic is sent and received through the LLC sublayer as specified in = 5.2."

You have to have it, but don't have to use it.  There = will well be non-IP safety messages.

I feel you need to fix this text = in the charter.

Yes, there will be non-IP = safety messages, and the are not part of our = scope.

= --Apple-Mail=_80076B31-2215-4A88-ACF1-8B51A3A3BF70-- From nobody Mon Jul 18 03:45: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 5656712D13B for ; Mon, 18 Jul 2016 03:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 R_cwJ5k9LNXZ for ; Mon, 18 Jul 2016 03:45:02 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 65F7B12D0F1 for ; Mon, 18 Jul 2016 03:45:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id EBA7262158; Mon, 18 Jul 2016 06:45:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZcI3m2Trrnja; Mon, 18 Jul 2016 06:44:55 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-a0d9.meeting.ietf.org [31.133.160.217]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 81F97621B5; Mon, 18 Jul 2016 06:44:54 -0400 (EDT) To: Russ Housley References: From: Robert Moskowitz Message-ID: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> Date: Mon, 18 Jul 2016 12:44:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CCA799C0C3178B8F6F79D432" Archived-At: Cc: its@ietf.org Subject: Re: [its] 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, 18 Jul 2016 10:45:04 -0000 This is a multi-part message in MIME format. --------------CCA799C0C3178B8F6F79D432 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 07/18/2016 12:28 PM, Russ Housley wrote: > Bob: > > I do not understand the text that you want changed. The current > charter text is here: https://trac.tools.ietf.org/wg/its/trac/. Can > you propose alternate text? From https://trac.tools.ietf.org/wg/its/trac/ "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." Replace with: "In the future, some vehicle communications will 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 gets the charter out of even mentioning that there is non-IP safety messages. I should also point out that for the text: "However, IPv6 on 802.11-OCB is not yet defined." 1609.3 DOES define IPv6 for WAVE over 802.11p. > > More below... > > Russ > > > On Jul 18, 2016, at 6:12 AM, Robert Moskowitz > > wrote: > >> I am new to this list. I worked, a bit, on both IEEE 802.11p an >> 1609. I am currently working on a contract for General Motors on >> automotive Ethernet security (a little orthogonal to this work, >> perhaps. M0re 802.1 issues). >> >> >> In the draft you state: >> >> "In the future, some vehicle communications may not use IP for >> exchanging safety messages with other vehicles and infrastructure." >> >> IEEE 1609.3 does define IPv6 configuration, but does not mandate it. >> > > Right. You are confirming that the “may not” is correct. So I turned the text around to drop mentioning of non-IP messages. > >> >> "5.3 Internet Protocol version 6 >> >> Support for IPv6 is conditionally mandatory as specified in 5.1. An >> IPv6 implementation shall comply with IETF RFC 2460. Related features >> defined in other RFCs are specified in 6.5. IP traffic is sent and >> received through the LLC sublayer as specified in 5.2." >> >> You have to have it, but don't have to use it. There will well be >> non-IP safety messages. >> >> I feel you need to fix this text in the charter. >> > Yes, there will be non-IP safety messages, and the are not part of our > scope. > think my change fixes the scope. --------------CCA799C0C3178B8F6F79D432 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 07/18/2016 12:28 PM, Russ Housley wrote:
Bob:

I do not understand the text that you want changed.  The current charter text is here: https://trac.tools.ietf.org/wg/its/trac/.  Can you propose alternate text?

From https://trac.tools.ietf.org/wg/its/trac/


"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."

Replace with:

"In the future, some vehicle communications will 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 gets the charter out of even mentioning that there is non-IP safety messages.


I should also point out that for the text:

"However, IPv6 on 802.11-OCB is not yet defined."

1609.3 DOES define IPv6 for WAVE over 802.11p.


More below...

Russ


On Jul 18, 2016, at 6:12 AM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:

I am new to this list.  I worked, a bit, on both IEEE 802.11p an 1609.  I am currently working on a contract for General Motors on automotive Ethernet security (a little orthogonal to this work, perhaps.  M0re 802.1 issues).


In the draft you state:

"In the future, some vehicle communications may not use IP for exchanging safety messages with other vehicles and infrastructure."

IEEE 1609.3 does define IPv6 configuration, but does not mandate it.


Right.  You are confirming that the “may not” is correct.

So I turned the text around to drop mentioning of non-IP messages.



"5.3 Internet Protocol version 6

Support for IPv6 is conditionally mandatory as specified in 5.1. An IPv6 implementation shall comply with IETF RFC 2460. Related features defined in other RFCs are specified in 6.5. IP traffic is sent and received through the LLC sublayer as specified in 5.2."

You have to have it, but don't have to use it.  There will well be non-IP safety messages.

I feel you need to fix this text in the charter.

Yes, there will be non-IP safety messages, and the are not part of our scope.


think my change fixes the scope.


--------------CCA799C0C3178B8F6F79D432-- From nobody Mon Jul 18 03:58:54 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 E68C912D89C for ; Mon, 18 Jul 2016 03:58:52 -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 0TX0OpqLGzdt for ; Mon, 18 Jul 2016 03:58:50 -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 0955312D895 for ; Mon, 18 Jul 2016 03:58: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 u6IAwmFa026632 for ; Mon, 18 Jul 2016 12:58:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1D449206270 for ; Mon, 18 Jul 2016 12:58:48 +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 13B5D20624E for ; Mon, 18 Jul 2016 12:58:48 +0200 (CEST) Received: from [132.166.84.142] ([132.166.84.142]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6IAwl6v030250 for ; Mon, 18 Jul 2016 12:58:47 +0200 To: its@ietf.org References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> From: Alexandre Petrescu Message-ID: Date: Mon, 18 Jul 2016 12:58:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] 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, 18 Jul 2016 10:58:53 -0000 Le 18/07/2016 à 12:44, Robert Moskowitz a écrit : > > > On 07/18/2016 12:28 PM, Russ Housley wrote: >> Bob: >> >> I do not understand the text that you want changed. The current >> charter text is here: https://trac.tools.ietf.org/wg/its/trac/. Can >> you propose alternate text? > > From https://trac.tools.ietf.org/wg/its/trac/ > > > "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." > > Replace with: > > "In the future, some vehicle communications will 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 gets the charter out of even mentioning that there is non-IP safety > messages. > > > I should also point out that for the text: > > "However, IPv6 on 802.11-OCB is not yet defined." > > 1609.3 DOES define IPv6 for WAVE over 802.11p. IETF does not yet define IPv6-over-80211-OCB (aka 802.11p). IETF has defined many other "IPv6-over-foo". Whereas 1609.3 may tell IPv6 were possible over 802.11p it also required an intermediate layer, whereas an IETF IPv6-over-80211-OCB would define direct operation over MAC. >> More below... >> >> Russ >> >> >> On Jul 18, 2016, at 6:12 AM, Robert Moskowitz >> <rgm-ietf@htt-consult.com> wrote: >> >>> I am new to this list. I worked, a bit, on both IEEE 802.11p an >>> 1609. I am currently working on a contract for General Motors on >>> automotive Ethernet security (a little orthogonal to this work, >>> perhaps. M0re 802.1 issues). >>> >>> >>> In the draft you state: >>> >>> "In the future, some vehicle communications may not use IP for >>> exchanging safety messages with other vehicles and infrastructure." >>> >>> IEEE 1609.3 does define IPv6 configuration, but does not mandate it. >>> >> >> Right. You are confirming that the “may not” is correct. > > So I turned the text around to drop mentioning of non-IP messages. > >> >>> >>> "5.3 Internet Protocol version 6 >>> >>> Support for IPv6 is conditionally mandatory as specified in 5.1. An >>> IPv6 implementation shall comply with IETF RFC 2460. Related features >>> defined in other RFCs are specified in 6.5. IP traffic is sent and >>> received through the LLC sublayer as specified in 5.2." >>> >>> You have to have it, but don't have to use it. There will well be >>> non-IP safety messages. >>> >>> I feel you need to fix this text in the charter. >>> >> Yes, there will be non-IP safety messages, and the are not part of our >> scope. >> > > think my change fixes the scope. I read. Alex > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Mon Jul 18 04:05:25 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9292C12D7B2 for ; Mon, 18 Jul 2016 04:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 1kYXxkcsX3tj for ; Mon, 18 Jul 2016 04:05:22 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 AE34C12D862 for ; Mon, 18 Jul 2016 04:05:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 93EBD621B1; Mon, 18 Jul 2016 07:05:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YaVsvmt7OFkp; Mon, 18 Jul 2016 07:05:12 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-a0d9.meeting.ietf.org [31.133.160.217]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id DD7B662180; Mon, 18 Jul 2016 07:05:11 -0400 (EDT) To: Alexandre Petrescu , its@ietf.org References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> From: Robert Moskowitz Message-ID: <1f22077d-e464-c39f-ba3e-b3c10ab24bc3@htt-consult.com> Date: Mon, 18 Jul 2016 13:05:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.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] 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, 18 Jul 2016 11:05:23 -0000 On 07/18/2016 12:58 PM, Alexandre Petrescu wrote: > > > Le 18/07/2016 à 12:44, Robert Moskowitz a écrit : >> >> >> On 07/18/2016 12:28 PM, Russ Housley wrote: >>> Bob: >>> >>> I do not understand the text that you want changed. The current >>> charter text is here: https://trac.tools.ietf.org/wg/its/trac/. Can >>> you propose alternate text? >> >> From https://trac.tools.ietf.org/wg/its/trac/ >> >> >> "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." >> >> Replace with: >> >> "In the future, some vehicle communications will 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 gets the charter out of even mentioning that there is non-IP safety >> messages. >> >> >> I should also point out that for the text: >> >> "However, IPv6 on 802.11-OCB is not yet defined." >> >> 1609.3 DOES define IPv6 for WAVE over 802.11p. > > IETF does not yet define IPv6-over-80211-OCB (aka 802.11p). > > IETF has defined many other "IPv6-over-foo". > > Whereas 1609.3 may tell IPv6 were possible over 802.11p it also > required an intermediate layer, whereas an IETF IPv6-over-80211-OCB > would define direct operation over MAC. I suspect that arguing 'over MAC' and 'over LLC' is a rathole. Look at what 802.15 is doing with 802.15.12 (I *think* it is .12, anyway) to address that it lost its LLC for 802.15.4 with the sundowning of 802.2. > >>> More below... >>> >>> Russ >>> >>> >>> On Jul 18, 2016, at 6:12 AM, Robert Moskowitz >>> <rgm-ietf@htt-consult.com> wrote: >>> >>>> I am new to this list. I worked, a bit, on both IEEE 802.11p an >>>> 1609. I am currently working on a contract for General Motors on >>>> automotive Ethernet security (a little orthogonal to this work, >>>> perhaps. M0re 802.1 issues). >>>> >>>> >>>> In the draft you state: >>>> >>>> "In the future, some vehicle communications may not use IP for >>>> exchanging safety messages with other vehicles and infrastructure." >>>> >>>> IEEE 1609.3 does define IPv6 configuration, but does not mandate it. >>>> >>> >>> Right. You are confirming that the “may not” is correct. >> >> So I turned the text around to drop mentioning of non-IP messages. >> >>> >>>> >>>> "5.3 Internet Protocol version 6 >>>> >>>> Support for IPv6 is conditionally mandatory as specified in 5.1. An >>>> IPv6 implementation shall comply with IETF RFC 2460. Related features >>>> defined in other RFCs are specified in 6.5. IP traffic is sent and >>>> received through the LLC sublayer as specified in 5.2." >>>> >>>> You have to have it, but don't have to use it. There will well be >>>> non-IP safety messages. >>>> >>>> I feel you need to fix this text in the charter. >>>> >>> Yes, there will be non-IP safety messages, and the are not part of our >>> scope. >>> >> >> think my change fixes the scope. > > I read. > > 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 From nobody Mon Jul 18 04:05:47 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B6212D68F for ; Mon, 18 Jul 2016 04:05:45 -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 9DYoYpxfPS8j for ; Mon, 18 Jul 2016 04:05:44 -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 D570B12D754 for ; Mon, 18 Jul 2016 04:05:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E040430056C for ; Mon, 18 Jul 2016 07:05: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 10026) with ESMTP id LR8RvrMOlBsF for ; Mon, 18 Jul 2016 07:05:37 -0400 (EDT) Received: from [5.5.33.52] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 4DF3F30029F; Mon, 18 Jul 2016 07:05:35 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_22622D46-A16A-40B9-A9AC-55A7610406C3" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> Date: Mon, 18 Jul 2016 07:05:29 -0400 Message-Id: References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: its@ietf.org Subject: Re: [its] 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, 18 Jul 2016 11:05:46 -0000 --Apple-Mail=_22622D46-A16A-40B9-A9AC-55A7610406C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Bob: Your suggestion is not compatible with specifications that I know about. = We need to coexist with non-IP safety messages. =20 We know that there a some non-IP safety messages. We will not be = specifying anything about them, except we need to recognize the sharing = of the link. We will not be specifying any IP safety messages. If they are = specified, it will be in some other effort. Russ On Jul 18, 2016, at 6:44 AM, Robert Moskowitz = wrote: > On 07/18/2016 12:28 PM, Russ Housley wrote: >=20 >> Bob: >>=20 >> I do not understand the text that you want changed. The current = charter text is here: https://trac.tools.ietf.org/wg/its/trac/. Can you = propose alternate text? >=20 > =46rom https://trac.tools.ietf.org/wg/its/trac/=20 >=20 >=20 > "In the future, some vehicle communications may not use IP for > exchanging safety messages with other vehicles and infrastructure. > Other vehicle communications may involve IP-based protocols, > especially when multiple applications need to share one data link." >=20 > Replace with: >=20 > "In the future, some vehicle communications will use IP for > exchanging safety messages with other vehicles and infrastructure. > Other vehicle communications may involve IP-based protocols, > especially when multiple applications need to share one data link." >=20 > This gets the charter out of even mentioning that there is non-IP = safety messages. >=20 >=20 > I should also point out that for the text: >=20 > "However, IPv6 on 802.11-OCB is not yet defined." >=20 > 1609.3 DOES define IPv6 for WAVE over 802.11p. >=20 >>=20 >> More below... >>=20 >> Russ >>=20 >>=20 >> On Jul 18, 2016, at 6:12 AM, Robert Moskowitz = wrote: >>=20 >>> I am new to this list. I worked, a bit, on both IEEE 802.11p an = 1609. I am currently working on a contract for General Motors on = automotive Ethernet security (a little orthogonal to this work, perhaps. = M0re 802.1 issues). >>>=20 >>>=20 >>> In the draft you state: >>>=20 >>> "In the future, some vehicle communications may not use IP for = exchanging safety messages with other vehicles and infrastructure." >>>=20 >>> IEEE 1609.3 does define IPv6 configuration, but does not mandate it.=20= >>=20 >> Right. You are confirming that the =93may not=94 is correct. >=20 > So I turned the text around to drop mentioning of non-IP messages. >=20 >>=20 >>>=20 >>>=20 >>> "5.3 Internet Protocol version 6 >>>=20 >>> Support for IPv6 is conditionally mandatory as specified in 5.1. An = IPv6 implementation shall comply with IETF RFC 2460. Related features = defined in other RFCs are specified in 6.5. IP traffic is sent and = received through the LLC sublayer as specified in 5.2." >>>=20 >>> You have to have it, but don't have to use it. There will well be = non-IP safety messages. >>>=20 >>> I feel you need to fix this text in the charter. >>>=20 >> Yes, there will be non-IP safety messages, and the are not part of = our scope. >>=20 >=20 > think my change fixes the scope. >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_22622D46-A16A-40B9-A9AC-55A7610406C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Bob:

Your suggestion is not = compatible with specifications that I know about.  We need to = coexist with non-IP safety messages.  

We = know that there a some non-IP safety messages.  We will not be = specifying anything about them, except we need to recognize the sharing = of the link.

We will not be specifying any IP = safety messages.  If they are specified, it will be in some other = effort.

Russ


On Jul 18, 2016, at 6:44 AM, Robert Moskowitz <rgm-ietf@htt-consult.com> = wrote:

=20 =20

On 07/18/2016 12:28 PM, = Russ Housley wrote:

Bob:

I do not understand the text that you want changed.  The current charter text is here: https://trac.tools.ietf.= org/wg/its/trac/.  Can you propose alternate text?

=46rom https://trac.tools.ietf.= org/wg/its/trac/


"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."

Replace with:

"In the future, some vehicle communications will 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 gets the charter out of even mentioning that there is non-IP safety messages.


I should also point out that for the text:

"However, IPv6 on 802.11-OCB is not yet defined."

1609.3 DOES define IPv6 for WAVE over 802.11p.


More below...

Russ


On Jul 18, 2016, at 6:12 AM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:

I am new to = this list.  I worked, a bit, on both IEEE 802.11p an 1609.  I am currently working on a = contract for General Motors on automotive Ethernet security (a little orthogonal to this work, perhaps.  M0re = 802.1 issues).


In the draft you state:

"In = the future, some vehicle communications may not use IP for exchanging safety messages with other vehicles and = infrastructure."

IEEE 1609.3 does define IPv6 configuration, but = does not mandate it.


Right.  You are confirming that the =93may not=94 is = correct.

So I turned the text around to drop mentioning of non-IP = messages.




"5.3 Internet Protocol version 6

Support for IPv6 is conditionally mandatory as specified in 5.1. An IPv6 implementation shall comply with IETF RFC 2460. Related features defined in other RFCs are specified in 6.5. IP traffic is sent and received through the LLC sublayer as specified in 5.2."

You = have to have it, but don't have to use it.  There will well be non-IP safety messages.

I feel you = need to fix this text in the charter.

Yes, there will be non-IP safety messages, and the are not part of our scope.


think my change fixes the scope.


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

= --Apple-Mail=_22622D46-A16A-40B9-A9AC-55A7610406C3-- From nobody Mon Jul 18 04:23: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 C71A612D8F3 for ; Mon, 18 Jul 2016 04:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 AxOIwLZ0oDiy for ; Mon, 18 Jul 2016 04:23:10 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 B464612D8EE for ; Mon, 18 Jul 2016 04:23:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 1F4146219C; Mon, 18 Jul 2016 07:23:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0Td1z3BfYmtX; Mon, 18 Jul 2016 07:22:59 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-a0d9.meeting.ietf.org [31.133.160.217]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 5B60B6219B; Mon, 18 Jul 2016 07:22:58 -0400 (EDT) To: Russ Housley References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> From: Robert Moskowitz Message-ID: Date: Mon, 18 Jul 2016 13:22:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------42BAE036D6C23C7139495EEE" Archived-At: Cc: its@ietf.org Subject: Re: [its] 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, 18 Jul 2016 11:23:13 -0000 This is a multi-part message in MIME format. --------------42BAE036D6C23C7139495EEE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 07/18/2016 01:05 PM, Russ Housley wrote: > Bob: > > Your suggestion is not compatible with specifications that I know > about. We need to coexist with non-IP safety messages. I think that is what the LLC is for? And the specification I am looking at is IEEE 1609.3-2010. Further when I scan 1609.3-2010, it calls out two Ethertypes, IPv6 (0x88DD) and WSMP (WAVE Short Message Protocol, 0x88DC). > > We know that there a some non-IP safety messages. We will not be > specifying anything about them, except we need to recognize the > sharing of the link. > > We will not be specifying any IP safety messages. If they are > specified, it will be in some other effort. > > Russ > > > On Jul 18, 2016, at 6:44 AM, Robert Moskowitz > > wrote: > >> On 07/18/2016 12:28 PM, Russ Housley wrote: >> >>> Bob: >>> >>> I do not understand the text that you want changed. The current >>> charter text is here: https://trac.tools.ietf.org/wg/its/trac/. Can >>> you propose alternate text? >> >> From https://trac.tools.ietf.org/wg/its/trac/ >> >> >> "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." >> >> Replace with: >> >> "In the future, some vehicle communications will 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 gets the charter out of even mentioning that there is non-IP >> safety messages. >> >> >> I should also point out that for the text: >> >> "However, IPv6 on 802.11-OCB is not yet defined." >> >> 1609.3 DOES define IPv6 for WAVE over 802.11p. >> >>> >>> More below... >>> >>> Russ >>> >>> >>> On Jul 18, 2016, at 6:12 AM, Robert Moskowitz >>> wrote: >>> >>>> I am new to this list. I worked, a bit, on both IEEE 802.11p an >>>> 1609. I am currently working on a contract for General Motors on >>>> automotive Ethernet security (a little orthogonal to this work, >>>> perhaps. M0re 802.1 issues). >>>> >>>> >>>> In the draft you state: >>>> >>>> "In the future, some vehicle communications may not use IP for >>>> exchanging safety messages with other vehicles and infrastructure." >>>> >>>> IEEE 1609.3 does define IPv6 configuration, but does not mandate it. >>>> >>> >>> Right. You are confirming that the “may not” is correct. >> >> So I turned the text around to drop mentioning of non-IP messages. >> >>> >>>> >>>> >>>> "5.3 Internet Protocol version 6 >>>> >>>> Support for IPv6 is conditionally mandatory as specified in 5.1. An >>>> IPv6 implementation shall comply with IETF RFC 2460. Related >>>> features defined in other RFCs are specified in 6.5. IP traffic is >>>> sent and received through the LLC sublayer as specified in 5.2." >>>> >>>> You have to have it, but don't have to use it. There will well be >>>> non-IP safety messages. >>>> >>>> I feel you need to fix this text in the charter. >>>> >>> Yes, there will be non-IP safety messages, and the are not part of >>> our scope. >>> >> >> think my change fixes the scope. >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > --------------42BAE036D6C23C7139495EEE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 07/18/2016 01:05 PM, Russ Housley wrote:
Bob:

Your suggestion is not compatible with specifications that I know about.  We need to coexist with non-IP safety messages. 

I think that is what the LLC is for?  And the specification I am looking at is IEEE 1609.3-2010.

Further when I scan 1609.3-2010, it calls out two Ethertypes, IPv6 (0x88DD) and WSMP (WAVE Short Message Protocol, 0x88DC).


We know that there a some non-IP safety messages.  We will not be specifying anything about them, except we need to recognize the sharing of the link.

We will not be specifying any IP safety messages.  If they are specified, it will be in some other effort.

Russ


On Jul 18, 2016, at 6:44 AM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:

On 07/18/2016 12:28 PM, Russ Housley wrote:

Bob:

I do not understand the text that you want changed.  The current charter text is here: https://trac.tools.ietf.org/wg/its/trac/.  Can you propose alternate text?

From https://trac.tools.ietf.org/wg/its/trac/


"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."

Replace with:

"In the future, some vehicle communications will 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 gets the charter out of even mentioning that there is non-IP safety messages.


I should also point out that for the text:

"However, IPv6 on 802.11-OCB is not yet defined."

1609.3 DOES define IPv6 for WAVE over 802.11p.


More below...

Russ


On Jul 18, 2016, at 6:12 AM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:

I am new to this list.  I worked, a bit, on both IEEE 802.11p an 1609.  I am currently working on a contract for General Motors on automotive Ethernet security (a little orthogonal to this work, perhaps.  M0re 802.1 issues).


In the draft you state:

"In the future, some vehicle communications may not use IP for exchanging safety messages with other vehicles and infrastructure."

IEEE 1609.3 does define IPv6 configuration, but does not mandate it.


Right.  You are confirming that the “may not” is correct.

So I turned the text around to drop mentioning of non-IP messages.




"5.3 Internet Protocol version 6

Support for IPv6 is conditionally mandatory as specified in 5.1. An IPv6 implementation shall comply with IETF RFC 2460. Related features defined in other RFCs are specified in 6.5. IP traffic is sent and received through the LLC sublayer as specified in 5.2."

You have to have it, but don't have to use it.  There will well be non-IP safety messages.

I feel you need to fix this text in the charter.

Yes, there will be non-IP safety messages, and the are not part of our scope.


think my change fixes the scope.


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


--------------42BAE036D6C23C7139495EEE-- From nobody Mon Jul 18 04:42:20 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F7D12D920 for ; Mon, 18 Jul 2016 04:42:19 -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 dsyeqfPyfAEu for ; Mon, 18 Jul 2016 04:42:17 -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 7D3A112D50B for ; Mon, 18 Jul 2016 04:41:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8D54230056C for ; Mon, 18 Jul 2016 07:41:53 -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 10026) with ESMTP id XtqGsXTUMV9m for ; Mon, 18 Jul 2016 07:41:52 -0400 (EDT) Received: from [5.5.33.52] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 96A14300265; Mon, 18 Jul 2016 07:41:51 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_59A3F2AC-F15B-446D-9C3B-EAB8609C16A5" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Mon, 18 Jul 2016 07:41:45 -0400 Message-Id: References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: its@ietf.org Subject: Re: [its] 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, 18 Jul 2016 11:42:19 -0000 --Apple-Mail=_59A3F2AC-F15B-446D-9C3B-EAB8609C16A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Robert: >> Your suggestion is not compatible with specifications that I know = about. We need to coexist with non-IP safety messages. =20 >=20 > I think that is what the LLC is for? And the specification I am = looking at is IEEE 1609.3-2010. >=20 > Further when I scan 1609.3-2010, it calls out two Ethertypes, IPv6 = (0x88DD) and WSMP (WAVE Short Message Protocol, 0x88DC). Yes, and we are going to specify the stuff that uses one of those = Ethertypes, but not the other. Maybe we should up-level the paragraph: OLD: 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. NEW: Some vehicle and infrastructure communications will use IP and others will not. Multiple applications need to share one data link, including non-IP-based protocols sharing the data link with IP-based protocols. Does that solve your concern? Russ --Apple-Mail=_59A3F2AC-F15B-446D-9C3B-EAB8609C16A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Robert:

Your = suggestion is not compatible with specifications that I know about. =  We need to coexist with non-IP safety messages.  

I think that is what the LLC = is for?  And the specification I am looking at is IEEE = 1609.3-2010.

Further when I scan = 1609.3-2010, it calls out two Ethertypes, IPv6 (0x88DD) and WSMP (WAVE = Short Message Protocol, = 0x88DC).

Yes, and we are going = to specify the stuff that uses one of those Ethertypes, but not the = other.  Maybe we should up-level the = paragraph:

OLD:

&nb= sp;  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.

NEW:

&n= bsp;  Some vehicle and infrastructure communications will use IP = and
   others will not.  Multiple applications = need to share one data link,
   including = non-IP-based protocols sharing the data link with
  =  IP-based protocols.

Does that solve = your = concern?

Russ

= --Apple-Mail=_59A3F2AC-F15B-446D-9C3B-EAB8609C16A5-- From nobody Mon Jul 18 05:20: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 255AC12D997 for ; Mon, 18 Jul 2016 05:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 wxJLqJdLr-hZ for ; Mon, 18 Jul 2016 05:20:11 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 1DE0A12D9AF for ; Mon, 18 Jul 2016 05:18:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4590962180; Mon, 18 Jul 2016 08:18:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JOFA7t7HzJLe; Mon, 18 Jul 2016 08:18:51 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [31.133.139.93]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 7F37C6215F; Mon, 18 Jul 2016 08:18:50 -0400 (EDT) To: Russ Housley References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> From: Robert Moskowitz Message-ID: <7e2d1572-9333-7d74-30ad-c47cd0d8512f@htt-consult.com> Date: Mon, 18 Jul 2016 14:18:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------33FB78180479C0111F137481" Archived-At: Cc: its@ietf.org Subject: Re: [its] 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, 18 Jul 2016 12:20:13 -0000 This is a multi-part message in MIME format. --------------33FB78180479C0111F137481 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 07/18/2016 01:41 PM, Russ Housley wrote: > Robert: > >>> Your suggestion is not compatible with specifications that I know >>> about. We need to coexist with non-IP safety messages. >> >> I think that is what the LLC is for? And the specification I am >> looking at is IEEE 1609.3-2010. >> >> Further when I scan 1609.3-2010, it calls out two Ethertypes, IPv6 >> (0x88DD) and WSMP (WAVE Short Message Protocol, 0x88DC). > > Yes, and we are going to specify the stuff that uses one of those > Ethertypes, but not the other. Maybe we should up-level the > paragraph: > > OLD: > > 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. > > NEW: > > Some vehicle and infrastructure communications will use IP and others > will not. Multiple applications need to share one data link, > including non-IP-based protocols sharing the data link with IP-based > protocols. > > Does that solve your concern? Yes. Thank you. --------------33FB78180479C0111F137481 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 07/18/2016 01:41 PM, Russ Housley wrote:
> Robert: > >>> Your suggestion is not compatible with specifications that I know >>> about.  We need to coexist with non-IP safety messages. >> >> I think that is what the LLC is for?  And the specification I am >> looking at is IEEE 1609.3-2010. >> >> Further when I scan 1609.3-2010, it calls out two Ethertypes, IPv6 >> (0x88DD) and WSMP (WAVE Short Message Protocol, 0x88DC). > > Yes, and we are going to specify the stuff that uses one of those > Ethertypes, but not the other.  Maybe we should up-level the > paragraph: > > OLD: > > 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. > > NEW: > > Some vehicle and infrastructure communications will use IP and others > will not.  Multiple applications need to share one data link, > including non-IP-based protocols sharing the data link with IP-based > protocols. > > Does that solve your concern?

Yes.  Thank you.


--------------33FB78180479C0111F137481-- From nobody Mon Jul 18 06:46:10 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C9812DE76; Mon, 18 Jul 2016 06:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YCHF_ERJ4E7p; Mon, 18 Jul 2016 06:45:48 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C9F12DABD; Mon, 18 Jul 2016 06:24:12 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-d5-578ccda91d4e Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 97.F2.03614.AADCC875; Mon, 18 Jul 2016 14:38:02 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0294.000; Mon, 18 Jul 2016 08:39:11 -0400 From: Suresh Krishnan To: Internet Area , "iot-dir@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org>, "core@ietf.org" , "its@ietf.org" , "lpwan@ietf.org" , "roll@ietf.org" Thread-Topic: AD sponsoring draft-kivinen-802-15-ie-02 Thread-Index: AdHg8WGWoPnMMjhNT2ePkXbsiQk/9Q== Date: Mon, 18 Jul 2016 12:39:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPoO6qsz3hBmveClk0TxGwWHa3j9li 39v1zBY3Zt1ksZj/fB2zxcX571gsZpw7wmrRdFnAgcNjyZKfTAGMUVw2Kak5mWWpRfp2CVwZ ez+9ZS5oY604tHAZYwNjB0sXIyeHhICJxJ99J5ggbDGJC/fWs3UxcnEICRxllNjU0MwO4Sxn lDj57BVYFRtQx4adn5lAEiICLUwS+5qOMYIkhAUMJT6ducoGYosImEmsaH8OZetJzPnZCNbM IqAqMen0LlYQm1fAV6L/2AKwMxiBVn8/tQashllAXOLWk/lQJwlILNlznhnCFpV4+fgfK4St JPHx93x2iHodiQW7P7FB2NoSyxa+ZoaYLyhxcuYTlgmMwrOQjJ2FpGUWkpZZSFoWMLKsYuQo LS7IyU03MtzECIyHYxJsjjsY9/Z6HmIU4GBU4uFdcLw7XIg1say4MvcQowQHs5II7+fTPeFC vCmJlVWpRfnxRaU5qcWHGKU5WJTEefVfKoYLCaQnlqRmp6YWpBbBZJk4OKUaGMOOaK/vfJLd f8RErPVOMd/+ee+mJ/wr4dVpT1sc6flq3ebHzeEL76cwNVrmTBFhjDaKu5x7rehuZcni19ZH uvfPWPrq3DUfgYM93MWlrjpyK97UaUw3Nl5b3PHCYvbHvuSfi385iB3mFvV3/r3SL6/LNfd/ bKOxcMMssdSKvh6z1NW/JC/vUWIpzkg01GIuKk4EALDwpz2DAgAA Archived-At: Subject: [its] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 13:45:52 -0000 Hi all,=0A= I am considering AD sponsoring the following draft=0A= =0A= https://tools.ietf.org/html/draft-kivinen-802-15-ie-02=0A= =0A= to request the allocation of an 802.15.4 information element from the IEEE = =0A= for use in the IETF protocols that may need it. If you have any concerns = =0A= either with the content of the draft or about requesting the IE at all plea= se =0A= let me know before 2016/07/29.=0A= =0A= Thanks=0A= Suresh=0A= =0A= NOTE: I have CCed: all the groups that I thought could be potentially =0A= interested in this work. If you think I have missed out some WG(s) please l= et =0A= me know.=0A= From nobody Mon Jul 18 08:26: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 1A93012D9D1 for ; Mon, 18 Jul 2016 08:26:21 -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 b_medGNU3NGk for ; Mon, 18 Jul 2016 08:26:14 -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 E6FDA12DE07 for ; Mon, 18 Jul 2016 08:08:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6IF80O5026182; Mon, 18 Jul 2016 17:08:00 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 01C4920BD44; Mon, 18 Jul 2016 17:08:00 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E4C9D20B67A; Mon, 18 Jul 2016 17:07:59 +0200 (CEST) Received: from [132.166.84.31] ([132.166.84.31]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6IF7xlG018813; Mon, 18 Jul 2016 17:07:59 +0200 To: Robert Moskowitz , its@ietf.org References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> <1f22077d-e464-c39f-ba3e-b3c10ab24bc3@htt-consult.com> From: Alexandre Petrescu Message-ID: <914a7f56-d99b-f8ca-3705-68f27c67884e@gmail.com> Date: Mon, 18 Jul 2016 17:07:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1f22077d-e464-c39f-ba3e-b3c10ab24bc3@htt-consult.com> Content-Type: multipart/mixed; boundary="------------7433A0057E90344F37ECC9D6" Archived-At: Subject: Re: [its] protocol layers X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 15:26:22 -0000 This is a multi-part message in MIME format. --------------7433A0057E90344F37ECC9D6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 18/07/2016 à 13:05, Robert Moskowitz a écrit : > > > On 07/18/2016 12:58 PM, Alexandre Petrescu wrote: >> >> >> Le 18/07/2016 à 12:44, Robert Moskowitz a écrit : >>> >>> >>> On 07/18/2016 12:28 PM, Russ Housley wrote: >>>> Bob: >>>> >>>> I do not understand the text that you want changed. The >>>> current charter text is here: >>>> https://trac.tools.ietf.org/wg/its/trac/. Can you propose >>>> alternate text? >>> >>> From https://trac.tools.ietf.org/wg/its/trac/ >>> >>> >>> "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." >>> >>> Replace with: >>> >>> "In the future, some vehicle communications will 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 gets the charter out of even mentioning that there is >>> non-IP safety messages. >>> >>> >>> I should also point out that for the text: >>> >>> "However, IPv6 on 802.11-OCB is not yet defined." >>> >>> 1609.3 DOES define IPv6 for WAVE over 802.11p. >> >> IETF does not yet define IPv6-over-80211-OCB (aka 802.11p). >> >> IETF has defined many other "IPv6-over-foo". >> >> Whereas 1609.3 may tell IPv6 were possible over 802.11p it also >> required an intermediate layer, whereas an IETF IPv6-over-80211-OCB >> would define direct operation over MAC. > > I suspect that arguing 'over MAC' and 'over LLC' is a rathole. Not a rathole: LLC is part of any MAC deserving that name. > Look at what 802.15 is doing with 802.15.12 (I *think* it is .12, > anyway) to address that it lost its LLC for 802.15.4 with the > sundowning of 802.2. Huh, didnt know that. I know 802.11 does have an LLC, yet we dont even have a specification called "IPv6 over 802.11". To come back to my initial statement "1609.3 may tell IPv6 were possible over 802.11p and required an intermediate layer". That intermediate layer is "DSRC Upper-MAC IEEE 1609.4" as pictured in the attachment. Private comment told me that 1609.4 layer may be just "control messaging", not "header". But how can one know? How can one find out whether that layer is "control messaging" and not "header". To come back to the documents currently written as IPv6-over-802.11-OCB. An IPv6-over-802.11-OCB document will have to specify something in the Frame Format section. Currently the thought is the following: - should it be 802.11 QoS Data (as in some US prototypes), or 802.11 Data (as in some EU prototypes)? We dont know for now. - it should carry the IPv6 ethertype Alex > >> >>>> More below... >>>> >>>> Russ >>>> >>>> >>>> On Jul 18, 2016, at 6:12 AM, Robert Moskowitz >>>> <rgm-ietf@htt-consult.com> >>>> wrote: >>>> >>>>> I am new to this list. I worked, a bit, on both IEEE >>>>> 802.11p an 1609. I am currently working on a contract for >>>>> General Motors on automotive Ethernet security (a little >>>>> orthogonal to this work, perhaps. M0re 802.1 issues). >>>>> >>>>> >>>>> In the draft you state: >>>>> >>>>> "In the future, some vehicle communications may not use IP >>>>> for exchanging safety messages with other vehicles and >>>>> infrastructure." >>>>> >>>>> IEEE 1609.3 does define IPv6 configuration, but does not >>>>> mandate it. >>>>> >>>> >>>> Right. You are confirming that the “may not” is correct. >>> >>> So I turned the text around to drop mentioning of non-IP >>> messages. >>> >>>> >>>>> >>>>> "5.3 Internet Protocol version 6 >>>>> >>>>> Support for IPv6 is conditionally mandatory as specified in >>>>> 5.1. An IPv6 implementation shall comply with IETF RFC 2460. >>>>> Related features defined in other RFCs are specified in 6.5. >>>>> IP traffic is sent and received through the LLC sublayer as >>>>> specified in 5.2." >>>>> >>>>> You have to have it, but don't have to use it. There will >>>>> well be non-IP safety messages. >>>>> >>>>> I feel you need to fix this text in the charter. >>>>> >>>> Yes, there will be non-IP safety messages, and the are not >>>> part of our scope. >>>> >>> >>> think my change fixes the scope. >> >> I read. >> >> 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 > > --------------7433A0057E90344F37ECC9D6 Content-Type: image/jpeg; name="pasted1.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pasted1.jpg" iVBORw0KGgoAAAANSUhEUgAAAeAAAAFoCAYAAACPNyggAAAgAElEQVR4AeydC1xUVf7Av8ob BQTFB2r4/ovJmJpamibWlm4PbLOHRaU9qNy2cHe1xd1sl3Zzsd0td7fCHmrlo8JKrBa1wNSt UBdLUCHFhAwtUFAwBpjB+/+cufO4M8zA8FAGOPfz0bn33N8553e+53B/5326KIqiIC9JQBKQ BCQBSUASuKgEul7U2GRkkoAkIAlIApKAJGAiIA2wLAiSgCQgCUgCkkAbEJAGuA2gyyglAUlA EpAEJAFpgGUZkAQkAUlAEpAE2oCANMBtAF1GKQlIApKAJCAJSAMsy4AkIAlIApKAJNAGBKQB bgPoMkpJQBKQBCQBSUAaYFkGJAFJQBKQBCSBNiAgDXAbQJdRSgKSgCQgCUgC0gDLMiAJSAKS gCQgCbQBAWmA2wC6jFISkAQkAUlAEpAGWJYBSUASkAQkAUmgDQhIA9wG0GWUkoAkIAlIApKA NMCyDEgCkoAkIAlIAm1AQBrgNoAuo5QEJAFJQBKQBKQBlmVAEpAEJAFJQBJoAwLSALcBdBml JCAJSAKSgCQgDbAsA5KAJCAJSAKSQBsQkAa4DaDLKCUBSUASkAQkAWmAZRmQBCQBSUASkATa gIB3G8Qpo5QEJAFJoOkEjJUczSuGQPAO7k9keFDTw2jMh7GS/LxCfAIDTZJVVQZ6hMCZKgj0 8QGDgSqDAR9x7xNA/8hIKMmnsML1+yDswzRUVWHAxxRGcJ/+RIT619Oq8kQ+e3MOQ+hgJkyK xpJSY/lRdu46iM+IK5k6Mtzqr7Iol715pfQYHs24oTZ3q4DlprKIfcWBjNP4hWryd++n5/hJ hDdoEZzIGcvJ/fIrSunB2CvHEarxX567i2M9JzAuwp/S/N18efgnLp06jaFWISNH933JkTMQ NfZKIjXuRblfknfsJ3qPGK/R1ZW8JXH2v9WlR9mbewTCo5gaHWn/0lOeFHlJApKAJNAuCFQo GcmxCqDokrMukMZ6JSctyRSHiCcpLUcpLylQ1iXGqG6xicq61HVKSnK86Tk5u0zRN/JeUezD TExZp6xbnazEgIKTdBSkJpjCTsnYqayIRYEkpVCktiRD0QmdUlOVOFDiU/NMDIozbPoKnRPT TdJ2fPTFOcrqJFVnKztDiZKxLlmJFXqgU7Iq7LzYHlzJ6fOUeJNf4R+F2NWKLQi9slqHkpxd oRSkinjjldRUoadOSS82KIJJarzZnymMWGVnmYiyTFkt0qxLUnZmpZoYxa7Y2YC8TU3tXVlW iqqTWb/4dSorrYwn3OMJSkgdJAFJQBJwh4ChYJ3pwxq7Itsd8ebJGHJMBg7ilBy9GoQ+b7Ua b0qOyaFCryjF6UlKUkaJ6bmx94o1zFhFhGAoKVMMFVlKYrIwLtqrQkmJEYYpTjGZjDzVkKQW VCppCTb3jESdyajlGQqVxJh4JaOgUElPjlONTkyKYrJlmmBLCnKUjHWJduwMJXlKVlaaEq8T 4cYq2TbrqfEpdHUul7M6SVmXU6YYSrKVBFMYMTYjXpGlxBCvFBgKTEY6JkWkJk/lGp+qlOet VmIT1ikFhVlKkqmSgRK3Ok9ANVUydIkZJh1UY7xCOeFK3k5Ty0OZsi5xhZKnNyiFGcmmNMc4 qehYpNvyV44Be0pXhNRDEpAEnBOozmf5PWPo0mUM1/3ibnuZ6iJWPjyDMWPGMGbMPWzMLVff G0tZv3A2Xbp0ocuYe9icX2nnr7poMzO6dOHhNfvs3E0PRoPZrVL0OJsug6HG7Ca6pvex7J+7 iZiZwAPRaudwY++xhhmED0Z2bkijPGgSC+NGm8O1/fgFi/u13PHwclampgPxjO6vUHZMuFdi MELkCB3wCll5gST+ZyUzhkYy89eLiRMiw3tau6wtoYYPjWayQzesd/hIJk26jisHW6Sc/7qS i573FHdFh+Id3pewHCDxD4w395WX7k1je8Id9C/6ileAYARIM8wjp/Eadicbn7+LoZGTuPf+ BFPE0VF9ICiUnkDOsmtYuHIN+4+Bbs5owl3IVxdt4eHZs5l9zxI2b16p5un6H7nr2ccZ6e9N /4jeprBnXj3CeeLa2FUa4DbOABm9JCAJNETAyObEKJ5cCxklu3npyXiNsJEtiYN45BVYm72f V+bkcJvucXKrjWQu7c3dL0ympCKHmJy1xKYe0vgDw+lCtgsT9uW3VNu9afjhWPq/eXjMeLL8 fYAgIsLtx28bew85/OWe8VzzegXCZ3hEqEOEQcx7dScxwgi98iSPLE0jIf1pRlLIl2k2UUt9 oMbgT5BZBWNRLmuBFfdfjWYo1urJUq2wOphunLvay4gn53LG0l3c06U/S4XIof9RZIJpZMfq ZSTdORbD2dN2QZmqQdvzKTb6W3U8XbjfVMmYNSoUgibxalqiyc8Lj8znhRz4d8IMvL2dy/tH TuFK0khbu4zYp/YxXIAzXycyl+MTNd/0lPu1qfZieeUxv9IAe0xWSEUkAUmgPoFyTN9nBtMj 1J9h467UiJSwNxOImc0gbwjpLVqFa9l+6BgHsoDY3gQFRfPqzgyy7h2l8QdB4+IpLiigZMUc kyG0e9nAw+DJ1/PwM4lQ7dwgNfYeBnPbY88QPxiMLuIpyv3KVDmIjRXpgRdmLWBXqTD49a8a ayiVrP3N3eiSd/L4pAYmYdUPwsGlmi3/XMLCJUtYsmQhS/6Z2WAFxTv8SpJz0ogVoaQ9yceH yqE6j7VrY5k9xrFyYY5KF0CApYZQmsn8J7aTkvM31M6ESo7sF5WlGGLU5DNtwXqbDvXkQe2b 0JGevpKVmQor7xppiihi2kNkrVNb12sfSWKffSeIQ7rb5lEa4LbhLmOVBCQBdwgYq/jBvhFl 82XUUya6PvEzuVlNYp2eH0TzNm0/hUYYOnUGkyKDwFhNeaXF7PkT1rs3TiYg28J31u4L6c+4 mxfyoNqzye71WzB3eqv+GnsPDJ50MwvjBplMZ+W+zew6YdEJMB7lhWuegLh1bNy0m3Vxwgql 8eWJblxpsnJqW9RHTTKDeqp9vvlrFjA/aB27F09FzD4+KoyNXXrtkuX0QeVnoOxYFplZWRzK yiTr4A/12r5WzqZQvImIvpm3slOsYZbvTyctLo4ofwjoKTqUxaWpQPSMJMxkgMv557XXMCej mIejg9i3ZRfHc9cza2kayVlpZH6WoRr2te9yyGQ868sL9iqKwfS2TBU3x4h3KJPuep6MJMGw ol46LGJt+SsNcFvSl3FLApJAwwS8wxhhGqM8Rkm5keLDorvSfHn3Z4IY9NyeTrFwqhH/6xg7 bASjTYOhL/CXl3ZRXp7P+jUfs2p+AGHB49lywkh1/hoCgoMZ/0ymtQ1pCRZvm7EIDFBdA8xO af/NxUg4d82bROm+NcS/VmTqSm3svTZMQzWMnHMz4ZX5LJu/CoIszUHA2xtTlJW1eOPPpKvU AdohffsxfrZqgQO9jRz8UnQ2J3FlpDfV+euJmr8Wct7lodljCNP9nbNUsl6TXpGKALPVrrDr c3dMaxB3PZ/J/sxMNmXuJ3PlXebxZEe5ajL/uZBn1u8z8Qvq209lPziUr95eR8J8tRvcO/Jq kkUVIv+E1QjHzL7MFObulfN5Ige2r36SGWO6MP6DckItNYtaI4TO4HaRZN1kBgeBM3kxom65 fMx5RWUuyx9eyGbzfIBu+hyIfZAxjgba4rEtf9tyBpiMWxKQBCSBxgjoC9LUJTuaJS+62GSl QK8ohuKd6izbOHUGcFKautxEX5hhnsksZvjqlHU53ynr4tR7sQzGMmtZl5ShiEUx1stQrKxL VJc6iaU1sYnrlENfpSkJsWLWseo/Lj5BiTc/x6bkKGU5Db9XHMKMiY1TEuLNM5Z15iVGVgUU pSBdnbkbl5BgWiIUvyJDUSdjF5uWJeliYxUdsUpaQYWiGPKUBA0X23KgCrv0luSkK0lx5qVU 6JSk1GwBT0lNjjfNOhb+4hLXKaYVQhpdTLdO5SzhoxATq8TGxCmpOWUmfWIdljRZ8i82Vqfo 4lJMcZRlm5cJmWZPC64o6lKhMiXVtOQrRklMFIxilHXZJYoreUPJTms+x63YqeZlSYa1vMTE xipxCSmmsuKYLE947iKUaMsKgIxbEpAEJIFGCRgrKdf7EBrkj9FoxNtb02qkmvLSSggKd+hS rqa8XE9AaKh5nLeaympvgvxVv9WVlXgHBVknAzWqw8UUMFZSWl6Nd700QXlpKd6h4XYNZ+eq 2afXuUzLXCsrK8FoxMfK2EhluZ6gUIfmpqk73ECoo7uL6Ksry9Eb0eSdC0FXzqb4RL91EKGN jTO4CuMiuGtL8UWIrvEonn766caFpIQkIAlIApKAJNBEAn/605+a6OPCinucAe7aVQ5LX9gs l6FLApKAJCAJeAIB2QXtCbkgdZAEJAFJQBLodARkc7PTZblMsCQgCUgCkoAnEJAG2BNyQeog CUgCkoAk0OkISAPc6bJcJlgSkAQkAUnAEwhIA+wJuSB1kAQkAUlAEuh0BKQB7nRZLhMsCUgC koAk4AkEpAH2hFyQOkgCkoAkIAl0OgLSAHe6LJcJlgQkAUlAEvAEAtIAe0IuSB0kAUlAEpAE Oh0BaYA7XZbLBEsCkoAkIAl4AgFpgD0hF6QOkoAkIAlIAp2OgDTAnS7LZYIlAUlAEpAEPIGA NMCekAtSB0lAEpAEJIFOR0Aa4E6X5TLBkoAkIAlIAp5AQBpgT8gFqYMkIAlIApJApyMgDXCn y3KZYElAEpAEJAFPICANsCfkgtRBEpAEJAFJoNMRkAa402W5TLAkIAlIApKAJxCQBtgTckHq IAlIApKAJNDpCEgD3OmyXCZYEpAEJAFJwBMISAPsCbkgdZAEJAFJQBLodASkAe50WS4TLAlI ApKAJOAJBKQB9oRckDpIApKAJCAJdDoC0gB3uiyXCZYEJAFJQBLwBALSAHtCLkgdJAFJQBKQ BDodAe9Ol+IOnODqo5t54o8fEziwJ2EBAbaU6vWUnT5OvxsWcvnJjazO1zMwLAyNBPqy72HM /STNm4RnFQoju1YuZW0RDBBp0uvR953G0sdn4m9LYZvfle9bw/Tx88kBEtPyePbmkW2uU0sV OLp5Ocu3n2FAmMqdyFksenhqo9xLczfz7FNP8UKaoKFecQkpLF7yANHhTSld5WSuTOKaR6DA 8DxDHbwaT+xi6Z/ehwFqWdaX6Zn2WCIzhwZZor1ov87yf9/6Z1h5QG8qt3p9GT3G3c/iOdGN 6lS5bznB43NJzU5mzriIRuWlQDsmoMir4xDQlymFBdlKSrxOATT/4pW07DyluEyvGCpKlKzU JM07VS5hdYZSUFiiGDyOhkEpydupJMVo0hOzQinzKD31yro4jX66+voZCtOUuMQ0D+TrGqS+ LE9ZEatJlxvci3cmq2UrboWSU5CtJGu5EKvsLHGzhOkLrHmenJ7nXMmKYmXnukS7srwiu7kl w6CkJ8YrqYV653E16Oo8/0sKdioJuqbxM0VjKFHWxav+4ldnNxizfNm+CdC+1ZfaOyNgyFtt 91GKTclxENMrq7UfVhKUAgcJT3ssWBdvS1NMilLhUQoalPQE7YfWUb8yJUVUIJwYZo9KhhNl 8lbHNYF7hZpOUfmLSVZKRHhlO5UYTWUwZoU7BqVQSTYbrqT0QidaaZ0KlURN+M01wGVZK0zp bJ5/1/lvxy/WsVxo0+F4X6akmP9G49e5qIA4epHP7Y6AHANux70XrlTXG2rsX9UY7J9xeI4d SW8HCU977B89ztNU0ujjzcyleaQkJpCQkMzO1Xdh6wQ1suWZW3lkOzA42K7bXxOAx972H39V 83TbvoVvy4HQy7gj1hZEsO3WxZ2RLUtu5knRex2zgsdmRrqQszj3YYQmfItrU36NRVu49Yon TF78fBz6ud0KyHX+2/0pVrgVmFkolPv+us50/8rdUazJrWyKZynbTgg0p7S1k6RJNd0m4OLD ULRvC1v+e5gaPz+Ce0Yy9erpDA1XR14rTxyl8LQBHx9NLD4++GCgygBWZ4MBeg5iZFgluUdO m+QN9CRqZESDY83Vpfls+ySLk6dqCBo9mSk9/DQRObmtLGLLh1s4fKoGP79gIi+byvRJQ52O V5bm7+LjHV9RUeNHxIjJ3Dgz2k7OWJrPpve3caLGj14jJjCu9/fsOzOGu2Y4MwZGTuTncZpA Zj6cwEyjEQItqa9k85JYYpcJ6wukbeKL/KlEBoQxNDK0XiJak2lDeSciLj2azw+WfDIY8Ok7 nKHhBnZv/pDdhZWMveF2pg6tr6NJ6coT5BaKvFTTaTAYCB4URWRQAKNmxsL2NNBdQS9RCzEW k59mS6qLomYVqM5/l1nL1LHjhIRY6mtQTf6ubew4dBLoyeSbJqCp7VjD0d40lN+V+ZuJjYrF nEO8s30v1wZGEtZ/KKHmSQbVpUXszd7LoaLT1NRAr0Gj+Nl1U1H/FBrKf60WjvdG8jM3se3A Cfz8Iphw9WhK9h1g+C/mMNQcr//In5Gsw1QZmR+3mhv2P064YzDyuX0TaHdtdqlwowQqclJs 3YagNNoFXa9Lt0xJTYyxC8MyppyYqnZnF6Qm1HuvS1qnrEuKrecuuhENxek29/hUpaGRtsIM 8ziipmvREr/p10HfirxUu25Oq6wuUcmx66uuUNKt+sUosZZx5dgVSqF5aLIiZ51VT12MbSzd ddepXhOmuRs6ZrVSoTh282u6qNEpWXZ6qVnaOkwbzztF0Stp2i5zUGKSVisrtOO1uhWmbn67 smTmbihIU2Lt8iZGSSuw5ai+rMyav3qH4ZB1eU4Sbi3RYhzWwjxWyXYUNRQqyZY8s4vfxta+ C7nh/HbUzVpuRNjJoqtcr+xMsQx96JQYu7jjlCzTeLar/FcTlZPirAu/zDrGCzpFZ01LTL1y kb3C9ve0ukF2Vojyph0RkGPA7Siz3FXV7qMpPq6JaUpBcaFSUFBg+ldYmKXEW//oxXid/diU 9o8+Mb3YFG2aZmJXinmii924LChpqqiSkaQ13glKntm4ZSW6MQ5akqExpjolNa9C0Rema9wc 9K3I0hiDRMWkQmGq1YgSm2KdsKX9GKaKoUVDjhJn5qAaWDGWZzEAcYpp9LE4wxR+THJWg/iz km0fSsGzTDEoZcUFSprV4Au9k5TsQpEPhS7HsFvK1N28U5QyZYXZoNgMgM2QWcar7cqSKV0q hsI0tQIWtyLDamzrA6qwm5y2Yqe5gNQXVF30tvwARwNsUHYm28qVLiHVVMmxVahU3bUGuLH8 NujLlIJs+8pbUlq2UlhYoBSWVChlWbaKYEKaqcAoqdbygaKtlNXPfzVJWh0sf2eG4jSb0V2t jnFnmMpPjJLlMIdMq4MuMaNdTeJzlc3S3UZAGmAbiw5zZ/fR1BpaV/daA1y2U2PQYpT0YtV6 FqdrZk5b5A15dobcYqTsDTBKYoaYjlOiJIGSYDbormBrDQhxq60f9+J0zWxXS/yKomRpWgi6 pAxzsMVKkmb26QrRDNZ+3K3+DRoDEa/kGcyTpcycdHErTAa9Ymeigs6+kuKov7MPrZCxc3dn Ek5LmDYl75QKh4l4MUpaXrGSvS5JiY2NVVZkqNPy7MpSTIopP4rNPRSNzdDVF5h7E3QJys5C x+asI0FFMRSk2gwTsfatwYpsTblEWZ1jaXEX2ue1ZRa0W/ktGrlao4+SoukyyV5hM/iiQiJi LNBMSovVTCizy2dr+XLIf7N7RbY64UttceuUFRmiYlJmmkxmKqsaNPb868+u14jK23ZIQE7C at8jCG5pH5OUQVlFGSUlJaZ/ZWUFrIhx7rXy2FfYhuyC6R2kThMI66+ZprX9vxRWA94jiUuy BbT9yTSKKo/y4VLLiJoax7J3vqS0aAdLieHOKQ2ta6wkJ9MWe+xVOuvYbFh/Z+Ov5Xy9ySY/ uHcPc6KCGDjYlr692YVUHvqCtRan7e+wfvMWtmx+nWSr4xHO6gMI6m8Rgpy1T9C/ywze414q sh9ubKjR5tHVXWMDoMJfC5g2Ke8cdNQl/oGbR0Yw7q6n2LRpE4/PGOogAfT341DmP+l/zZNA PH+d1/DEuCOfvgu6JAr3P8/USNu0tPoBqy76s6dN66hNTzEzGKHxUlm4V1Mu49ANsqwCD7PL a0vY7uW3kLafkFhjMFqCYHjMg9b7+IWT+DE/k9c32dY2p2XupTlTo3wCtVPRcnjimv7MWJLO vcUVPB6tSbQ1dvNNsF+D8yYcxeWz5xOQk7A8P49arGFwSA9Cg0I1k1X8CdZ+A7Qx+Dif7GT/ mao0TbQS1nHCbfeC1eAu44kFWaTFJJO+4AyzblumhvzKUzx0JAfi0xjfwPdFq4bpXjOZ2z5+ i6Q3ftp0aOQtEuK3ssIy28jiup2XVvVH2GhdfDxXUEVV4DUMDPBn4PwkWLvUIghsZ/60KErS C1nc6IxcjbcW3DabaRPzTqvi4EhL5UXr6nC/dj7jrRWWV0jauJjn5zgx1GZvVSXHiE9+FWdV J4eQ1UfL3DXx1KCxqXQwm05C04aFq/wWk8Sc+DU7BUXfhaLcTtG+/7Dy+XgGzbcZX5OIOxUq J8H7j7yOJB0s1QS3fdndRGUlU/ifxURa6haOftPSOVL5MOOa8jfkGIZ89igC0gB7VHa0P2Uc PyZpa7cTu/olZt54lhiWmWeX5pC2HZKXXdm0Gryf3Ve0FeHE8/6mlTg1HTOeojjDz9zKs0X5 5KwnuFa/iXGuPo420RbfXVCmrrRzUXlxJS7cX7jtIW4qyWSGi6m5Yx5J52/hLl42FHCj74Ls Z983Kt9AfjdggIV13r1mEVfMf8EUg9jhbO6559Hd/UqjMTYsEMFT+wvxmz2IJ20dOLD9Sea/ MYvMh13slqWbTF9pfBtG287eyi7odpZhF0RdbSvSLgLbX7uxSvuF1n4AI7htYZzGl477rxsG /uNZEK9xJp5ZYxr/GGtjSdv3DaKnW1x2plijr1Yea+PdSIW2dSIMuV0T+hXW7yo1h6z+HN29 m1Ij7Fv/T46OXYyheCcJOq1IGnuPNKfDURNGcIMNLo1gazB1J+80Ubq4teMeu5riwjRsWLZz zUMrEct9HS9j6T7ef38b761cT74zAUcPIo99bDqTZh7msMjZ5d9a8oudlgyLtNv5bfNQ/+7E lqVW46tLTDdtL+pTW1VfsKku5ftY/s8fWLzJwM7VCXa+t6dnu+7W7hnS8mEQu9jkQ1sTkAa4 rXPgAsTv49gVWa8lafdZhWNnrYYuKOpabJ+EYkrM37nvv860aZpwt11LcOR1d9s+yjELmBoh Ola8ueb+ZKsfXeIdRDfaegxi8myNMX8ljUOm+Kv5aNVL1rCwGtcgro2zaXus6IwqU32MTOsw tI77b4oiaNRkNCGzdNqvySxSE1eUuZxhV8Rz3GikZO8TTEvajHfEVJ7fX0KK1ZOOfsHa3bNt 6pjurMZfdJ/a3hm0n9MKCMDIlpVrOGqxHzZRu7vmMG1O3lkj1epvdYSy4hLNE/SOvJm1q61Q IO0Rfrc+304GKnn9jvHc/ch85j9yN1GPb7SWLwdBu0f/QSOx7alhHuYwSwSNmmCXf+9+esj0 pjr/I57XtiLNfSzu5bc6BGxXrfIJgKItrNySw7Z15iEUIOd4EflH97E5Q9NvHFxDZbW5Ca3l p8l/uwSa3Y36Ep584go2F3kzdd7zlGWlWMV0g+33aNdWHHVj+rW7jVysCZM3zgm0w4ljUuUG CRiU7HUOa3TjVivaLXj15qU1tnWP6nIfS7DFGbYZz7Erdip6faF1X16xPCRDG5jJk21Grbpc wxySZkZvSr1FnZbYHH4rsq1Lg4R+urhEJTlBMxvVPEM5PjnNnCbtLNg4ZWeJXinUzNiOSd5p jSBHM4PVknadebZ0fKo669cymzVWhK+vUNKt66ETlAKX2xhX2C1PEdswmiePK5blOpb41LWk SepyKatmzm6ax9TtvNPnKYmameK6xHTrjHObNgaHJWVx5mUyJfXW467ONm08afaq2ZJS5Jcb e0irHvWa9bGxSrZlorM51Gztmlp0SuKKZPvlaSIuXbySlqPq4k5+K4YCJcFcpkx5pFPLWmJG kZKmWXJkyb/6v7FKjt5V/lcoadbyIziYy4XeUsbjTLpWFNqWJSWaZkTbcsBSHkW8ju9sUvKu vRKQy5Daa8450bsix34PaMePRVJ6tv0HQfvhEcYuIc36ES7MSNEsCTGvD41JUHZaLItD/MXp wujX32AiK0n4jVfX1Dr4cfUo1v3ab/QQqyQnWzY00CmxcfFKYvI66+YZir7AyQEUKAmrsxzW TRqUrNUOlROxNEojl21aa2pZC2xZFxtrt9GEvd7azSMs8ijEis04xFVhvxYYUUmwD8HVU3OZ Np53NuOuLSPCCGvrGHZLvyxlJWa1ojcU2C0/s4RhO8jA3nDHpbiz/7NKwbInswgzycEYiY0x 0q3lQGUdm5hs1UUXE6vEJyQq66zrjRvPb1MO5aXalbe4FHXNt9iURayRVitpOiUpNVspzkvT GP0YZXX2Cc3mIdr8f1l52W6/dfM7sRSpIssUhqXyZ+EXm+RYCdKWLbFMzlVJke7tlUAXobjz trF07fQEjOUUFZVhFP1g3j2JjAx3PYnKWM7RIiNDhzqM81aXcvRHb6dbLzbI11hJUVExRgII i4wklHKKSqB/RKhLHcpPFPGj3oiPAYL7RxJuXkLlGE91+QkKf6zAxycAsbzJsuWgkKsuPYE+ KEKNr7gMo3cA/SMjrMuhHMNy99lYXUml3khAaKj7YbWEaVPyzt1ENEnOSHm5HqPRSHh4/Q0l XQdVzsrZYTwiupVjV6PfNK8er8oTRRRXGAkIDiMyIhSR72L9WGgz8tumh5HK8kpTeQvVFgij UZ0o7e1tK3fGaiorDfiEBtXTzRZeQ3eVnDhhJMKse5koF2H9idDGK7yX72JG2DTTRMbE9EKe vUiz8BvSXL5rXQLSALcuTxmaJCAJtJRA+TGiFk0AACAASURBVG7uCbvCtG57dU4F8xpaG9vS uDzY/67ls5kmpkknpKF//uZmGnsPTqBUDTkJSxYCSUAS8CwCoZNYXZiO2OJlvu4e62Q5z1Ly wmqTu36hanzjVlMije+Fhd2GoUsD3IbwZdSSgCTgnIB35Ewyy3JIjkvjmkGT2G03Vdm5n47i Wp37T3R3v0BCSgb6t+bJE5A6SsY6SYfsgnYCRTpJApKA5xAoP3EC794RuBji9RxFW02Tasor vV2OabdaNDKgNicgDXCbZ4FUQBKQBCQBSaAzEpBd0J0x12WaJQFJQBKQBNqcgNwLus2zQCog CUgCWgLnz5/n1KlTVicvLy969uxpepbvPIuLn58f3bt3R+SRvJpOQBrgpjOTPiQBSaCFBMT2 A+vWrWP37t0cOHCAc+fOsXfvXlOopaWlREfbDiTo168f+/fvl+88kItY53327FmGDRvGN998 Y80jka/Tpk0j2OWxay0sQB3EuxwD7iAZKZMhCXg6geLiYlNrKSQkhJqaGu655x4mT55sMrYj R46kf3/NYcyenhipnx0BvV5PQIC6V3p5eTm33XabqUI1ceJElixZQkyM7dxwO4+d/EEaYE0B eOqzdzRPnnUrapj3DRjvWUpJbSQBNwiI1utf/vIXPv30U7799lt69HDj7GE3wpUink2gtraW Dz/8kMLCQn7zm9+YlBXGOTS0KTujeXYaW6qdNMBmgg+nv8qpn6zH7LSUa6v67zlyCGP7D+XR UNtBcE2N4C8bZQ20qcykPAwfOpjbx65qNor33nuPxx57jN///vfcd999BAVpjhxsdqjSY3sl IAyxGDNevHgx3bp1a6/JaDW95Rgw4OnGN7h3rxZl+G9WDeZURWGLwpCeOx+BngNgoMPJlU2l 0LdvX44ePUpgYGBTvUr5DkjgqaeeYsGCBYwePZr333+fsWPHdsBUup+kTr8MSRpf9wuLlOw8 BITxDY1oenpPnz7NTTfdZPU4ZcoUaXytNOSNGH5Yv349K1eu5A9/+EOnB9KpW8DS+Hb68i8B OCHQXONbUFDAzJkziY2NtYb62Tty6MMKQ95YCfgCv7zNiKV89O03gJHT3rK+7yw3ndYAe7Lx 7TsmioCQlo2VyW7nzvIn3LrpbK7xFetzr7rqKp577jnT7Gah1ZZXB/OTHPpo3QzqYKHpgUED 4L3NQ/ntpBrEuuLOdHXKLmhpfDtTEZdpdZdAc42vCF8sQ0lJSZHG113YUs5EQBjfSyLgvS0l DBw40LQ8rTOh6XQGWBrfzlS8ZVrdJdAS4yvi8Pf3Z/bs2aboZMvXXeqdW85ifAWFzPXjmTp1 Kr/4xS+oq6vrNGA6VRf08vxMqv296e4f5nEZ3GNwf3wC1YXszVVOdjs3l1zn9tdc4yu6nf/8 5z9z+eWX8/Of/9wEURrfzl2W3E291vha/GzcuJGtW7dy8uRJBgwYYHHu0L+dygD7BwbgG9Ld 4zLUL6Q74t95Q/Nrfiu2xVBFIYHBHpc8qZAHE+geBsG9m6egWFIiNtlYunSpKQBpfJvHsbP5 cmZ8BYMuXbqYJvF1Jh6dygCLDPbETcO9unRpcZnr3gMCO9Gh5S0GJgPAyxt69IXm9Ph99dVX vPrqqxw6dMhEUhpfWaDcIeDK+Gr9VldX891335n2l+7atWOPknYqA6zN5I54Lz6o8pIE3CXg 08wJp+IghXfffde0kUKvXr3kbGd3gXdyOXeMr0Ak5hMkJycTFhZmmlXfkbHJT7abuVuyfjX6 mHuJ7Gd/7FbZxhROXHofo6NaNn7rphpSTBJocwKiJ2nZsmUmPfZvicGXQnzl0Eeb54snK9Ar DPo1Yahj+fLlREVFmXbNGjx4sCcnrUW6SQPsJr66c7lsmXU7PYdH2vk4faSIKRvi7NzkgyTQ WQiEhUCdZ26h3lmywOPTGeAHEeFQ24QpLuL85wcffNDUAn7ppZc8Po3NVVAaYDfJ+YWphjds zAi89TUgShUQRBE1lbVuhiLFJIH2TUCM/YruZ0sLWExf8JZfkfadqRdYe/9mDnU8/fTTbN68 GTEmLLqlO+Il/3TczNXz52Bq6l8ZNVxsoma7zh8bwiefnIKJnre0yaalvJMEWodAUlISN9xw Q+sEJkORBBogIHbFEucKd+SrY08xa8WcO48f/j3sja8IvubEWfpc3oxd61tRNxmUJHAxCJw9 e5bMzEzuuuuuixGdjEMS6PAEpAF2M4uDRgXxyc9SKSs9p+7UUlfLubxdfPzLt+keXt8wuxms FJME2g2B9PR0025F8mjBdpNl7V5RMeNe7DF+6tSpdp8WZwmQXdDOqDhxCxh/HZfzCKk/e9v+ 7QO/Y/BAaYDtocinjkhg1qxZdicddcQ0yjR5FgEx475fv3785z//4d577/Us5VpBG2mA3YXo Fc743SmEvreNI3u/h8AQ+sfMIOraEdgvTHI3QCknCbQvAiEhIe1LYalthyAwffp0srKyOqQB ll3QbhbRupO5ZD+3nvLe13D9879l7FV9KdmeTm76tzRhdr2bsUkxSUASkAQkAUFAp9MhZt93 xEsaYDdztXz7Rv7HOKJi+lL1+dt8kPgWZfSi6v1F5OWJUy3lJQl0XAIHDx5k/PjxHTeBMmUe S0CckiTmH3TES3ZBu5mr52tHcMuiqQR6nePAmveBacz4y92EnYxg69bjjI4a4WZIUkwSaH8E ioqK6N27CVsZtb8kSo09mECPHj08WLvmqyZbwG6y8w2tpCCrmHP7dvD5Xuj5wAyCKorIXvpv fAbIffjcxCjF2imB8vJyxL7P8pIEJIHWIyANsJsse9x4K4FrH2fd/atg+I1MfyAaY9EJAm78 HZdPDnczFCkmCbRPAlVVVR12N6L2mSOdS+uJEydy+PDhDpdo2QXtbpZ6hXPZq+9xmVY++kpG RWsd5L0k0DEJiH15xT95SQJtQUCv12M0Gtsi6gsap2wBu4n3VNrHlDjZdN5wZBff5J1zMxQp Jgm0TwLHjx+3nv3bPlMgtW7PBM6fP4/YlKOjXbIF7GaOdjUU8N60W03S2hOR1NOQ3nAzFCkm CbRPAh999BEHDhygI59M0z5zRmrdnglIA+xu7tVWw/CJRI3pDfpCSkrC6B3pR5C7/qWcJCAJ SAKSQLMI7Nmzh4CAjnfmujTAbhaH891Gc+vbN9DLq5biNS8THPcol0X5Upf7Mbl6z9yKo7oM xEGJgSHg3ch2XbVn4XwA+LdgV83ztXAe6OoL9cY26uC8+OfVuC5uZknriNWBGFkSfFzyqlU5 +lrYaPyY0mTJfidpM9ZCVy9z2gFTGHVQrQff7k44OaSq+pxzORNrc7hWvRz8ykdJoKMQ6Nat W0dJil06pAG2w+H6oVfsDEo+3cSHv32LE0JsuB++cQM5/vQq+rx1tWuPbfRm//OQHwzhhZAN PPEMWOyHo0rffQCZb0ApMO9daO7ZEucOwMokNfS5a2FAd/W++jD8a7F6f0sKDOvrqEEbPeth 21wY8ir8tNY1r+/fhQ01sOgBVU9jGex8DbJ3wyVXq4eNGyoheyvM+DuMH2pOTx0cfB22bQUG wXX3w2Bg5VLz+2h46I/w/XJI321jIMIYGwypD8F3wvlq+NVC8K+Fj2+HQ2bRezfA/rkwchVc coFPwxw0aJBNQTfv6kTtzwu8HCp/daLCUgc1onLoqlC6GYfbYnVQehbCwkwque3tggjWgphO EuwLdXowBkAzj8w11QyrLibHCwKk8wZar6HSeVE0nPKy9X/lA5PxncbPVv2Zy/mEXU+vopCJ RESaLU3DQVy0t8bvYdsO+NkDMOMZmBKhtkydKnAO3nkDbn4XHvg7hDr5IFYVQYWllec0ENUx eBzEmusiez+zCRa8p95f928PMr7AnrnAEhhU0wCvOti/EfgQTpo3PPMOh+n3qGka+QuYGgcz HoV5vwKTcbEk3QvGPAqjgGGzYIwODqTCA5tg4b+BXDj8LZT8CNcthlvMlZSQUDhzDKa8AY8K Y70Dquug9jj43Adzk2DOcggPgBn/hnfuhzNu5I9Freb8/vznP2fBggVue60rg2d/B+Nuh9tS VINj8lwHb/0Nxs2FTd+4HVyLBOtKYckiuPYh+M32FgXVYs/H9sKYufB+oRrUO3EwcVPzg837 D1w5F4QR7sjXFVdcQX5+fodLomwBu5mlosuv5wO/44YFEwgQNfq1rxJ58Ed8h40g2NP24TDn 6usJMON20D0A/uZ0fr8Tjn0Hfv1g3HT49mP1xcFdMPUaKN0D+bng1QcumwW1B+HVpXDFo9Db Cwy+4N8XgqqhrBSCdDBAswy6NhjGXw3Zr0HpLAgvg6IeMAz4/lsYM0CNr+Aj+O5HCImGsRPh fCns2wpnKmHITTBsAJzcCXkHwWcgTLhRTYOd/teASGpZDhzcC4buMGIK+NVBz0j41iEObW2z Yo/JrvHQROAHVSdnvKoOwrlJEL4bcvdCv2mqrFE03wDL78mPoG46THSsi5m7r2sNqvzlS8w9 EYHqc2AAXLYMfMXwlh4uiYYBYeA/EcL0kJkE4Q9CDy+1G7z8BzgjejbGqt3XXQfAjEGw9VO4 43o1TE/43ysMnnoOTt8O2z+BqcCuRyDYC+Y9DhWZcNdFWsK3fxuU3AR7xqH2XjkBtO8wjLsI m9kNHg0TxFCE+W905j9gQlMnkpyF3FqIDocR02D1WDAXJycp6xhOlZWV6jGwHSM51lRIA2xF 0fCN//i7uWFUL059tIlje4rQ40f/664jSnxRPOzy7gtxv4K1/4LM5ZAJxK2Fn16FDwbBE9Nh xWMwcDKE9FOV7zUIKvbBmmdhzgo48gS8aICH/099H9wPennBqt/DdStgSDB89jncco194uv8 4LKbIXsH5GbDsGMw6iY4shXKzcu4jr0OH+TCvQvgzcVQsxy6vQSlt8PVvWDH13BJHaz9Bzyw Fo6/CuV6+Cmlvv7hp+H1pTDnDQjcBW8+BkyC2b1hk0MckzUf2OIMtWtX2EtXvPp1hyOpMHIu fL8b9r8Pk6eB1sYWfAxVeyBrI8Q5sNCSsXQsmAwtkCcmzs+F0eYKiZAtzYDuP7NVlr7bCcar ofQ1yLsMRM/2d1vVf0J+zioYHAYDroXMdKi+3uZXG3dr3H/33XeIj+Cll17qfnC1EDganhoN z7ytMcIiBHOFRHRFf54BXxRjAhsXC2G18OWnsNcHwkvgeHd4MBb6WSCaNagphQ3b4HglTL0J pveHqlLY9BmcqoWrroNBVfDm+7B3NBweB6O8YGMqHKuFCVfB9N6w8RV4phqWTQVDDfh4Q9Rw KDgCVd4w80pNF3EtfPIJ5J2BYePgikBYuwler4Yn/w+KDXDjddDnjHP3KPM8Il8vqPgBMv8L J4bA8Cuhpgw2pMPxUxCigwdjRKGwT8/IOvj7L+H0L+COiXDuGHxcCpdGgvdZ+GAbHDsNwZfC PFHrOeeCJfCf/0D2DzB0PNwlagXyuugEtI2Cix55e4qwe3Qoh8Y/xH+efou8j3dS+PEnfP7E Il7785fWb4nHpEe01qfDonchbgmIBurxE9D3Nph3Kfz3b6qmYnKQaCmKK2wgnDkCRKsf8ejl MO9KCP4/uAToOxJ6XgqzJsG2XVB6GC69ycm4cg10HwpXD4LsZ+GdMhjcD35SozH9f/JDdey0 qx/ELYdRfaDvLDi0HF5eDOER4NtT7bp9PQ7EOShijMyZ/mISlLj8u4NlkuTDiVDqJA5VUv2/ tgouGaW2oMVMNWe8KIP8SgEPQkXrshCOHlX9+0aoXCxd0L96Fs6UgJjM5ngJuyGGQy3Xj1th dzgsugOMmnM8cl+DMeMsUnDJ9XDd42rvQf5B8B0Ev9wAi96DK4CT5jPKu/qouolu6gt1iWVI L774YpODL6mEm26DV+8EREs4Re0u9RM6A5+/CQu+hUXz4epamPkyVJ6AJ96Cb87A9bHA25Bq 5q5V4MNlcHgIPDIDtn0Noqv5ykdgbCxEvA/zP4duPWBIJIwYBP0D4MX74B0fmHkJPPFryK0G H1G4QmDwEPjpM0j8FPr0BcM+8LlEY3zr4Jm5UDwabuoBiX+ALj2hZqfqP1oH1W/DnX+CWhfu Yp6FqMDV1oGfL+S9D7t+VHs/fvkQ9L4GFt8Br/8bTpyonx7L2ac9I2BAKJzNg+3Z6nj6P+6H vAGw6BGoeQH+9CX85ILlkU8gsQh+eTsc/UIzRKAFLO8vOAFpgN1EfG7He/yPG7n5g1e5f/cG HvziDe5YlcCgjX/jiKhOe9BVWwgrfgO1vtBvosmmmmaenNkLaxbDCPO51pUl6gxdobowxn5i omEu1AVBP9HcEt2s5qQZ9OpM3mFiKfRGePMTtZvYMdli1q+YCT3aHMesm9SJOFq5btHwXT4E DIA+Yny6Fs5WQVwKzLkPdiRB5WkIXwwPrYCQHZB/HJzp79tbNdT71kBWDsT+HcSIgLM4tDqI ++++VWdAu+L14w4YvADGXA+T41VDuG2beTzd3PFRY+6K9h8Fg42wfr1DLL4QqelqFV3fb74M 106Hk1/Ae5tV+doiyJ4EEebm9ckcM3rBBrhkmNoKr7RMbBJp1PY7DgJ/z+uMMRkbgWjibfCS 2Qjf93vYa24BnxRjoeZJeaJFyU4oHQhPRcKMq6BfGOhGw65v4KQYP71V/XfbJrh0Jnz8N7g2 EUZEqJZt4z+g7DN4BogJBL8QiAyCkN5ql/4u4Ib+4N8f1i6DyGAYNRBG9IWovnDr/cAB2FMM x4Phmv72+TnvHzC+DBavEokCPzHsIbqVh0D0EPjNc0ARlHo5d/+h2tQoNQXqFwZRo0HXB6pO wl4xtzMc/PrC/vdgcCg4picwHKIiYeAQGNgLxkQBI6CbHsSQ+sCeqr5X3QkfbwH/Ec5Z9hmu so55CPSRmkqGfXI95kksQ4qKEontWJfsgnYzP6uOwcxP5tPPOt7pS49xU5nx1g9kfvk9o0T1 2UMu0VISLaQVT8GoQPB5EGYMheNfqgoeOgTjJ8EHW2C6aOGJCUmb4fqZMGU3bBAfIWCGGH8c ABGDYMN9cIeYbTsCpgDVt9Tv7jTNpt4KBUFwWxyMiYYhA+DAy3A2GgI+hS96w+UPw7ePwcvC mA+CO36vjsOu3QBT/GH8ryHAD3Ysh5r71Fb58IFwbo+ql1X/rTCrAg5NghvF36YRgvxUAxnl JA7tROGIq4B0VdYZr6hCSN8BAYUwcij89CnURkP4N7DpFQg8DvpBcOgtODMIDCVwaDeMN0+k UjW1/a8XBqcWdj2rum0QXeXAFeYZ0YXrIXyceVlSLWQthYJouKQSwu+DMUNh379gRyGMmgQ+ j8IV5u7rcjEtOtpJb4QaRdv9b+4ytszwnSJawj7w0Fsmm6HqJcqf2RifNY/F9wmAg7a6nyrn AyFDYdM/1UfvAMjfCWtfhIosWPBn+MUqSP41TPgDLAQ+Pgtlll4B0eL2NTV0+boE7pkAP/0A P9WqlTChg6go+EXCk6PhicfhyWUOhskLdok4RquViQVfwo/nVPVFBVJclt0Su/u6cPdXW8Ci C9p0VcLQCPAyf4kzc2D4WMj9EroPd54eUQerEfHVgbcBRgy0zTQ31wc5fkDUgm1jw3ZNBB84 fRr+9hwMOgtz/gxzrodxHrzMVi5DMpeXTv3jpLrS1duHytOWYu8hdHxh6gvqmJtWo8FxsCjO 5jLDfDtBfK3M1+Rn4Arx16pZy+sYVq+bIHS0xYft95JbYNEttufrRDNEfAceNX0LbC+AWzaB aC17W8b1HoXfmD+GlnWtizZBrR68b1ENU7gT/c/tA5Igx/wB/C5XHaMeE+kkDo0G4dPgkpeh sBRGhDvnNU8zpht8feOTnG7QhC9uRXe0WBNdlAuCjWB6wyZwlBOyQxJgiOWj7KvqLtYAC/8W HhNfgHGiy9pXs5b6HKTtgNhXzcbbQYfWemzyMqRaWL8KiovgT6nw9G2qMZs4G141wEM7oWI2 3JQI+x4B0XD85m1Y9g+oyYVnimBEulrZ2F4JhzPg9Ex1zNuSpvwfIO4dWCCGMhKgW61q3PZu A90v4PDbsL03vH0ADlfC52Ph97+D2X+FcavUCUz/fBS6h8HhVfCkD7wwG2beCcl/gJ9p5gyY 4qyDSlFh+BK+GA8TimBjLowIhMNvwXM/wZ73Iek5GOwFOU7cyz8DMRH73CYYfhW8UwRsgqmP wkv3qBWJl0Tr/U54dlj99GRPhcjxsOAP4LUQvs0AcUTB5xPhmT/C4ylQMx5ES//tWXDSBcvS W+G3i2DhneoEx5EebHwt+d0Rf7soHXGDTRc59a/jWRwsM63idSHh2rls/dOk7p3OvOdjbGv2 aorZM+lxWLWKieNCXHtu5I1fUCB+ocGcN1iq6/U9DPUJ4dFQXf0XZpfX98TwzUnN2h+Xks1/ UZYBr/8LRv0KbtAYp+aH2HKf2bMhVywBEmO0dZD9R/B+EIQBbuyyrE9+6F3oYakINOapCe/3 zIYd5uWzD4uucYuBbUIYjYlmJ6gzja+b3Jhk/fdi7LNbqMPSKQexyODp3Dva9dqd77NiKDvh vNyJJVliDbDlVxt0lR7EDHDLJZ79Apq+RlesNRbV3yatJxZrkM1jsJb4tb9iLPkfB2CRmATl xrXxadgyEVaaa1aWbHbl7kaQLRJxZOsysDqoEhPlNPngUrYFL4ICISxYHfd2FYxPyHR66FyX M7EMac2aNYwcOdJVEO3S3Umbrl2m44Ir3WPW3Yzdu468PWO4bKLamXlm1xdUP/AYumHaebEX XJU2i6D7pXDjYhjcjI/9hVJ6zBsQlAV7PgCvQHXJziVuGF+hjxgf+9UKOCvO0tD2T7eSsqP+ DmFnIWIMBFq+yq0UtimYWuizAMY7ttRaM44WhGXZgMPyqw3K8aPv+KyVbejey9fWzdqQnN07 Md/BWX7UqpOsxLLvtzfY+XD9UAenD8Becx5Yg3Xl7jqkVnvjNkuvC298WytRchlSa5Fsp+F0 DR3BxOf/ZKd9j2tvY9q1dk4d+sHXPFHFkxLpHQIjWrD+1T+y/lh2a6VPzAYX658v2OULAy6S 8W3WMqQLlvALFLAvzP4dXB8BUW72iJw8DEGPwVNVkF0KE81zRFy5XyDNZbDtlIBsAbfTjJNq SwIXk0BnOQ0puonrYftFwV1OJue6cr+YeSbj8nwC0gB7fh5JDSUBSUAS6NQEOuppSHIdsJvF uu5kLtl/XkH2p2KtRB0l6ZvI/P0Kvk7/Vsz9kZckIAlIApLABSIgliF17drxzFXHS9EFKgDl 2zfyP8YRFdOXqs/f5oPEtyijF1XvLyIvT7Od0QWKXwYrCbQlAbEMafRoJ2vP2lIpGbck0M4J yC5oNzPwfO0Iblk0lUCvcxxY8z4wjRl/uZuwkxFs3Xqc0VEXaTaMm/pKMUmgNQmI05DkJQm0 FYGOugxJtoDdLFG+oZUUZBVzbt8OPt8rTkaaQVBFEdlL/43PAE87DsmWKLHNo9FFH7nYR9my daTwITa9aOplCl9sPylO/dFDrd2WO+6Fdl4P58RSICeXCNeip9iYojnhOwm2vpN5C03x4twP cO6sectJraRIozZ9gp+ZrUVHwdPipvVq4mzmbQ2jDkSaxNadlsvEwsl+0uK9kHW8LPlrDdNR QD5LAh2AgFyG1AEysSVJ6HHjrQQ+8gjrTBu23sj0B6IxHv2SgBt/x/DJ1v0pWxLFBfFb9AFs FGsao+GXz9jWTP74Ebz5mur+wFPQ/bi6f7Q45F1sBejudWI7bHhZlRZ7Ju/fCuE3wZ2aIxAb CkucwPT+m1BaCLP+bX86kPD3/cfqecVC//Fh6ilLw+bCDXeYNoRqKGi339V+r54O9fAbsOs+ CJgLZzdA7YNwx422YL5/FzbUwKIHVDdjGex8DbJ3q4dLRISDoRKyt8KMv8N4sZ+2uOrg4Ouw bau69eZ198NgYKV5G0qRtof+CF33w8okmDJH3bnpzkdtS6Qs+fWrTeBfCx/fDmIHSnGJPNs/ F0aKrUIvwHpmEUenWIak4pT/SwIXjYBsAbuL2suX0Ck/Q+x13nOAL+dr6giIvpJRsRMIviC7 LLirWMNyg++AMUIkF/IsJ8rUwhfC+ALz/ghhYrvDQTD3WejZBOMr/A+4Xj0hSRiRax+FR5eo JxEdtMSlRuPy//1JMPZ38EtxxKH5aEStsNjCcZbYE/kqmLEQ5s6Fgg1w1LxvsFa2WfdnYf1j 6laOxv+p+0rPuANueUM9RcoaZh3sFzs0fAgnzT0F3uEw/R5VwnIq0gyxK9evHHaX8oIxj6qH RgybBWN0cCAVHtgEC/+t5s3hQhAsxiyByXEQshX25qhhi4MaTJWlSep2k7XHwec+mJsEc5ZD eADM+De8cz+ccdHbYU1HM2+aexpSM6OT3iSBTkFAGmA3s/lM+hq2vPAJvRfcSW8O88HiDzFv P+xmCG0kpoeA69WPf+a76sbzFf+DbnNUfU6dVH9N592mwbk6qDgK256HAxnmX0tTq5EkiK5U vflwB29vqCqCL9bCrrXwo+jSrYWCd+CDlyHzHTj+BWQB+Z8Cka53i6rKtW3Yf6ZMVSLIXFEo 3QO7XocvPoIqs/ER8e4R8X4E2a/DSSddt5akHNsIpdfDsHAwHeu3G9aIY+6KYZqm9Vt1EM5N Uo1yrugFMV9G8zbglt+TH0HNJJjoOCVAdF+Lbn7zwQOXL1E33/I2n2gU2BXE6YIB/mrAohf6 1Hdq6/m/70Pso4A4ts58lf8AZ0ohsJdqlL0HwIxBsFWwlJck0MEIdNTTkKQBdrOgGn8sI+pv KUyLv5Ghc+9jpq6I0+YD5t0Mom3ExH68Q+DyXwG74dvvIX83jBWHdQNVlnMkKtXTfPS1cGwz 7N8BXoNgzHhIX6Ke4dpgAgJh/+uw5l9wyRwYHgQvPgHeOuhVCW/eB5WF8MEGKDgDRgP491EN WviQBrqT9SDOav9uN7wzG9LN3bsDOMPJNQAAIABJREFUQkB0X695Vj2Q/txr8OJmqD6qxht+ vbpFY+aH9Y9DtKajFg59CKMuVY1Yj2kw63oo3Q1pS+D5ZVBtFj6SCiNjVX33v287Us4SVsHH akVj7Wu2k2ks77S/lg2WfM0ViLw3gLkwejBcNkc9BWl/Bphe+8B3G6DffdDXLG/5g/1uK6T/ C968H46ZKyUDroXv0m06a+OV95JAeybQUZchyVnQbpZK7+7iXD+xs/xJvoxfxOkJ93Ov5869 sktVnQH6iNN//gVpj8H4pdDTckacWbKveY/zAF+49DbYVgTDxRimuYScddg8XxtBnbkrIPoB GHuPeoJPlbn7NMwfgq6Be38OQZFw3SCouQsmiv2aa9Xj4UL6W6PRBqvemzfXHTYdblkIz90P Bf9Tx1fPHFHHsEWjMXo5jA2Gs/9T3QaGg9im8pL6Idq5iFapOLBdXEY9jHoURt4Fhbvgg9eg XA/99JBfCSOPQ6jY9nIrHD2qHhHoG6HGIbqgxQEQE8bBsRLo2QN8Hc7nEMZX2xj/cSvsDodF d6hxi9OqHp4O+hLYBswaAe+I8fVvIFz0AogjXHfCjCnwyw3qAQS7boWTp9RTgkwt+EKormv9 s4GbfBqSqq78XxKQBBogYKlQNyAiXwkCPW65n8EBteDVmwl/SuCOv9+gtlI8HY8XGES3ZwBM NHc7XyYOPjeaFTcb2K7C0A2C7l72x9qZ3AHxezID9pjP5NUmO/j/1CdRmMTxeeLy7qb+njVC nxFqi84SpTVus3E1qVAHB9ZCwfeqP+v/ZhnTDO0wiL1ebRUeKAI/EUcu1AVBP1FZqDF3I+dC qXkmsWVi9/mz8MXrUGZxsEYAP4oj4YDSzfDmR6rhFmO1lql1P+6AwQtATDKbHK/u77xtm3n2 slm/GnNPgv8oGGyE9es1EYhbX4iMtrlV7IE3X4Zrp8PJL+C9zeq74AHwwwfA1TDyEnhgBcx7 GC4373c9IgrEcEGlqDl4qacHdTN3Y5tCGNT6xleEK5YhLViwwJYAeScJXEQCYhlSfn7+RYzx 4kQlW8DucvYKgIJUPnwuF99pNzHFoQXpbjAXVa4O9qSoM4d9+sOUa9XWWg89fLYSLomG3Och ZDGcTQUKYd//wEscJiomBe0BP3HYKHDwa+j5GewIg3ETbS3WM3tg40Y1rA/Xwg1xaney71C4 ZS58sAQygVEPwpWn4atCYA2EPw4+u6EAOLseIn8FBzdC9yEwzHzQvIhXjNGeFUf6vQaZYTD9 DggX3a9PwC0vwJRo2HC/quOMJBgfA1fvg7X3qTqVikqBqG+cgc8/hNAbIMzcnSuM4vBo+N9p 1X/41cAj8M4R8C2C6CTgC0jfAQGFMHIo/PQp1EZD+Dew6RUIPA76QXDoLTgzCAwlalf++MVq mI7/60VlqBZ2Pau+2fCY+nvFUrX7/O3fQMAc+GWcyjjM3Dr3EmPKW6F3OHz9F9hRqJ6V6/Mo XGHmVS7G6qMb6M53VEY+SwLthEBHXYYkzwN2swBWfJrCht9+wvAH7iGsZie7i2/i/udj8HHT f0Ni7eU84IbS4OqdaR2vl+YAeVeCLXAXcQhjqu3OEetyu9bBO7fDNDGOajG6DvHUHlWXXz20 CXo4vGutx9qzas/A1rkQsBRmiB4IJ5dIh0iKv2Wg2EFGrPX1Nb8T3eUizd7mFrjo234uTp3N PcLSdHfw7/jYlPOAXS1Daug8YMf45HPnJNAa5wFfeumlvPvuu4jfjnRpv1kdKV2tnpba708S tSKFGb+azWW//Qe3RBVS0h4mYbU6iaYFKLqkrUaiaV7dlhZxOBZk0WV+/hyIicQ/aQdeHUIV LfW4B+HV12298g4iLX78+j54PhEODYLLTWvCnAcp0uHK+AofFuMr7r0D7Llm/wHGLAZ3ja9z DVy7ymVIrtnINy0n4O0vurk63yW7oJuS5+YlJPrcbXzwUiG3xDXFs5S9qATEDOcdcN2jULYP jNfbus0d9eh3IzyQo05eEmPgrX2N+juEnYWIMa6XWrUozlros0Cd9d2icKRnSaANCPiEXE3g JU83GHNHPQ1JGuAGs932stc9jxL2ej41pqk5Plz+p7vppZ38YhOVd55AwBdG3+K+ImE692Wb Ktl9qDpxq6n+3Jb3hQGO647d9tywYI9O2jJpmIp821oEhPENHrGGro2UM7EMqSNe0gC7navd ibiyF6f25eHj052aPYUYYkfQHuZiuZ1EKSgJaAhcEnw1Vw9UWyZyGZIGjLxtFQLuGt9WicxD A5EG2M2MKfvoRVKf1qzBiXmYCW76lWKSQHsjIIzv7OFrCPFTx+bkaUjtLQc9W9+mGt+OehqS NMBultPzP4VwzYcbGDZQnYZaV1UrlmHKSxLocAQcjW+HS6BMUJsSaKrxFcp21GVIjpNH2zRj PDnywMggvn7jc04dKaLsSC67//IJTvZ08OQkSN0kgUYJuDK+YhnSwYMHG/UvBSSBhgg0x/g2 FF57fydbwG7mYPWpU5ze+D7viRNxxDVBdkGbScifDkLAlfEVyRPLkA4cOMBLL73UQVIrk3Gx CUjjW5+4NMD1mTh1CdFN42cb5jEkqrvpgHghJLsPnKKSju2QQEPGt6HkeAddjW+I0pCIfNfJ CZz3AmO3SEJH/KnR2c6uUMllSK7IdBL3019+TVVkCGVHzlBTtIcjJWOYdtcFWvvRSZjKZHoG gWC/QXYTrpqiVd9L/0jfjrU5UVOSL2UvEgG5DOkigfbUaLx9S/j8l4s06r1NxFTbpCzNiza5 7R90NVVVsiXSJvDbaaRihzJfH5hzqW22s6ukyGVIrshId0mg+QRkF7Sb7Iy1Q7jxk4X0D/el Ju9j1sw9QFhvF5v2uhlma4rNjPojM6NaM0QZliRgIyCXIdlYyLuLT0AuQ7r4zD0qxl63xtLV TzW4Pr2GMGlxb7rJXTg8Ko+kMpKAJNAxCchlSB0zX91O1an3VnFoXxEVx4o5d6aaqhPVprPq zx0rRm8+C9btwKSgJNDOCMhlSO0sw6S67YKA7IJ2M5u8fc+y6/5f20n3vaEHB+f+kW5/e5EZ 1/a1eycfJIGOREAuQ+pIuSnT4ikEpAF2Nye6jeWW7QvpGVhnW4YUGMDA7asgNMTdUKScJCAJ SAKSQBMJdNRlSHIpq5sFIey6yXh/X0j5tyepLC7gq5eyMAI+oSH4uBmGFJMEJAFJQBJoOgGx DKlr145nrmQL2M2yUPbBi6T+WXMYA/BVtT8P/uFKuSe0mwylWPslIJchtd+8k5p7LgFpgBvL mzoQFrarjz/RL6YweUo4UEb2ok8ZtmiiNL6N8ZPvOwQBuQypQ2Rju02EXIbUbrOuBYrXFLF1 0q8Zmf4ukbGPManGC6rKKP4kjf8dC2a0X/s6D+mpz95pAQzptTMSGDZsGPcNGN8Zky7T7EEE OuoyJNkCbqiQefsRBJQfLyPCv5aitA/JeOET1ceE+xvy6XHvHk5/lVM/VXicXlIhzyUQNmgA Ed3UGQ5iGZL4CF56qdx30nNzTGrW3ghIA9xQjnn1ZfLXb1Dy6adsiXmLE0BEwh/5+bxozp8s azeHMUjj21Amy3fOCAjjG3JJhPWVXIZkRSFvJIFWIyANcKMou9P72tnc9PVNVB05xOEtn/P5 3z7nbPFArnv+Bo8fA5bGt9EMlgIOBByNr8Nr+SgJXHQCHXUZkjTAbhclLwKHR3PZ8GjOVxSR 88o3nHfbb9sISuPbNtzbc6ytbXw/eyemPeOQul8kAsOGDWbA+FUuY5OnIblE0/ledA2O5LLf Rnp0wqXx9ejs8UjlGjK+zVmGtOXVwfxUUeiRaZVKeQ6BQQOgeyfdTEG2gD2nHLaaJtL4thrK ThNQSJ9wAvv0dJnepi5DksbXJUr5QkNAGF/NVAPNG/vbjroMqeNtLWKfb53uSRrfTpflLU6w ML5BgyLw8Wud472k8W1xlnSKANw1vgKGXIbUKYqE60Seryrj1IGjlJ88h1e37vQYOpReg8Nc e2iDN8u+3sI53y74+8q9qdsAf7uMMjAkyNTybcz4ursMSRrfdlkMLrrSTTG+F125ixih7IJu FHYdp9Le5L2nP6ovGXMPc/86m+DWaTjUD7+JLt3CQgg8L9f6NhFbpxX38vamW79wuiiNI3Bn GZI0vo1zlBIgja+tFEgDbGPh5K6O4lcW8dHeK7k5NYWwPt3xNu1+VUdNWQk/bH2bDZNSuO2L RwgLdOL9Ijt16dIFLy+ZpRcZe7uNzsffDy8fb87XimNFWnZJ49syfp3Fd3ONr1yG1FlKiDad NT9wrs9DPPRqVL1NNwL7RTJk3pPMm/Qlx4+eJSxadvtq0cn7zkNAGt/Ok9ctSWlzja+IUy5D agn59urXrz//F9vfpH1Z2iZqps2mX6h9Yrp6i9ZD+9oT2j4F8kkSaJyAq2VI+7fE4EshvsGN hyElOi+BXmHQr3fnTb+rlMv+SldkHN0N37A55lZ6Drdf/3v6SBFTNrzhKC2fJYEORcDVMqSw EKiT0w46VF63dmIC/CAiHGrFyXLNvDrqMiRpgN0sEOdr/SFmGr17qjOujPoak0+/I0XQ8iE0 N7WQYpKAZxHo0gW85VfEszLFw7Txb4VJqnIZkodl6sVWx3fI5dx+6xRCHQrT+UenUXTuYmsj 45MELi4Bd5chXVytZGySQPsmIDficDP/qr8tpEpt9Nr5MJQUcbaiBX0rdqHJB0nAMwmIZUgv vviiZyontZIE2ikB2XnkZsZ5+57ig2m/pudwmwcx/iuuKRuutTnKO0lAEpAEJIFWJdBRlyHJ FnBTisnwPgQN6ENQD6BHH4bfMA3bialNCUjKSgKSgCQgCbhLQCxD6tq145kr2QJ2swQYa3tx 8xt30y8Q6vK28Y1xKqOiAzDERfGNXnZBu4lRirVTAq6WIbXT5Ei1JQGPINDxqhQXDKuvOeQ6 zhYW88M3/8/emYBFVa4P/CfDDKssgiggghtmobkEVpaJpWXapUxbblppV7PVbte6WV63a7v/ UjOvbV5valpoWWparmGYQq6YuAupqKjsMMwMw/yf75wZGBBwVEQYvvM8cM75zre87+89c97z fedbjiPcrgR41YDLjOsRATEM6dlnn61HEklRGhMBMQxp//79Tqey9B8OmtSFoxzfWwB5Bzl2 2J9mBfs4fewspzfvpEQrJ+JwEKOMJglcFQKnzlaRrRmOnbYLN8PZs3AqC/L0arjZCAYjiH2R HoqMdvHtDg1n4f1FkG8Gg3jzFntrXLM1TMlHpDGreWXlwlm7smzZGfRqHiK+KFPJz3ZR7qsk IIchVYml8QTqgkPZOfoJ+PgzYl7opChekLicxH2BXNffVjtuPDykpo2LQH0ehmQ4Cfe8CNEx wBlITlePc5OA4RB/PxzbCfdPg9jB0DYfvlgLz06D6OMw4hPVlkP6wdK1EDkIvhgB9pN7/b4M Tt4ABfvgX5MhGYgdBG+MAPbB+MlAPxh/D7z9D/U6MfD3jvDrAkiOgaXPQQcPWPE/+PdaIByG hMPSBBj2Erxye+O6p6S2sgXV4Xug+FQTBiUsplu38jmfvXvdT5/HA8jOtL5OO5ybjCgJNCwC 9XkY0p8HYer78Pk/4Z/3qFz/8XeInwVi0ELeQdX5DnsNZjwGL46BdZMh/QB07w9TheOOgtdF +GtwcCWsPGpnnwKYsRae6wnBneGN59Vrzz0OzYHmneEfI2HsSGgXAR/PUq//6xF48n74fBk8 ewaGPAGngCGjIFY48HvgX2NhzmBYOANS5GPEDnrjOJSdsBy0szoM6TU5DMlBXjKaJFBXBDrE qo62QnmimTgU3gqF799VrwyKKo8hnOZbncvPxZGY0C7HOqmOzu6r0qEtcPAR6GBt6CoxqelK RBO0h/UYMIlzHZit8wXYT704fAzMGQ8b0+GvrdQ0BdZ8zp1Tz93tylRD5H8bATkMyUaiMe/l MKTGbH2pewMlYPVzuNbk4Dxh2X9hyGyIHgz97aZ8X/IJzLyzZuVdTbA/s/o4mkoz6ImY3kXw /iSYmABPvVTu4KvPpfFekcOQGq/tFc3lMKRGfgM0cvUb8jAkX+tXo5JKowVFByhPDzAVqca9 fwQ8/Bho7Lp0ZKXA0hh4tVkVN4CdQ3fVQn6lOeHta9EGaxlKLjY5fOGVKfCiGZRlxqsoQgY5 NwHZC9ph+9p+lXIYksPIZESnIdDghiHZOcdeA1QzLNhabo5DG+GWJep5cKS6F0nsna8IXTMZ /j4U7CuwwtmK7USWuhf/k5MgOkw911jLTrV9RzbC4s/Ua7GiZu0BbQFbE7R0vuUcqzuSw5Cq I9NIwuUwpEZiaKlmgyWQGA+vr4HIcJj4IRyzDhPyDId1b0PRbBj6Lrw+SW1q/lcvOJ4Mz34L 0cA/F4F9RVX0rhafj/8ivKXd1qYX/L03jHsOXpoLL70MxkHQ3QMMp+GfL0N0FOxZAS+9C397 FFI7w/KFEKyBTYvgC+GI18Os3+wybsSHru4RNWovhyHViMf5L+pCW1U9DCk1iOsH2GrHzs9B atg4CdTnYUg2i/QaCuKvqq15JMxYZh2/a4a37H6yu0V4FVvCQhg4Di5ofdbBk2Nh+DNQaAQ3 7/IasltLazlV5GcL6vMY7H7Mdib3Wt878Gw9qVGCkL2gHTS7z22PMGrXUMxF5W1bYhjS3Tcb MYuuj3KTBJyYgBiGtHfvXubMmdOwtdQ4+L3VDC37w7gu1asrmqt95E+/ekAOXBHO1ydyPi4X qQE7kFWDjCK/ATtotsyvl3AqT4fWs9wBi6SG3T+Ssj3XwVxkNElAEmgQBDTQuRs0q/hzbxCi NxQhL8X5imFInTqpEyA1FP0ckVPWgB2hBMjlCB0EJaNJApKAJHARApfifEVWYhiSM27SAV+K VZVxwKL74hnyEcsRhlO4KuFScpBxJYEGSaAhD0NqkMCdWOhLdb5OjALpgB20rhwH7CAoGc0p CYhhSHKTBK6UwOU6XzEMaf78+Vx33XVXKkK9Si+/ATtsDltvCzkO2GFkMqIkIAlIAlYCl+t8 RXI5DKmR30ZiHHDa3gKCrzuuLkfYVCxH6A+bd1Jyy62NnM7lq19qNmIuNFJiNmJBg9bTF639 rAcia0MuBZlGNAG+eHiKyXZFz3MNTUrMmMWabq6ic5ztBalcFlN2FoZiMxovD3Re3tgmSBAx SsUacnabi0ZjzUtDE8BSAk1cQYRfWL4Zc4mZJq46XC7opGNW8raUiHyETjqaYMYsytPo0DbQ WReqG4bk2vQOdL4WO5LyUBKoSKBUAyVe4fhHTmm0vZ0rEik/k03Q5SxqPJLjgGvEc1kXc9Yt 4utx3yppI4Y9Qgu3DLZ9kUDEs6/RZ3S0MvuQPuVnVg3fSZtng/h9zkp6LV5IRNZPLHpugbKE TedhzUhZmACxj/Dwm0Px8wSKTrLrjRfZtjGGm15qRcaMb8lgOI/vut86d76RtLcfZe1S6Dzl NXySFpO4Kp0Ozw7Hfe0CMm4cTnv3nWzLvothj+hZXan8Tn77WTdgGmlAz3nz6NrdOtdh3kF+ 6j1eCe8282PCzi7nh2nqunOdhoSTujSBgGEvcd+42yvMrHRZ8Oo4UXXDkFreMJmWN9SxMLI4 ScBJCMgmaAcN6XPHYzy968LlCO/+cARhYRfWvhzMtlFH87vrMR6e0huIIfrvQ+n6wlhGrZ1A /px3mP/RTkox8uesT2g65Ql6jB7B4zMfgRIzYvz1wxOioEMvbh43lifnDYeNS9jzi1h9PZe9 Y4XzHcyju/5Jjycf475dc+kZm05+2TRHOtq+OI0Q0bRFCFETxxAgLKHTwo0juW/C/bQOCebO MTdxooryNcHd6DW9n2K7bf/ZhnXxG3I2fqc434gJs4i5oyXBQ0bRR6w7F30ft00Yy/CZgzm/ cAaHUq1L7jRq60vlJQHHCTjrMCTpgB2/B5S1xiqPA76k5DLyBQRKTMVKWKnVi7k070afV2Pg i+WcKwJtEKRNeo6fPlpFTsidRHX2VuLrs/LFAnCYMJN/XDhe8GnhgfnQNhKTIeLVW+wWVG9O 1w/HEiRqx7bNJ5Kuw0TeK8hzi+SWYeEcmjEPt7i+uHGSvclhhIVpqi2/OKcpnYfFQPInpB0S cx6e5mBSEJ1jIW3nUdQGbutciJgQjbTFOeq6cy41LstjE1DuJQFJwEbAWVdDkg7YZmG5vzYE bD7KrnQXL3fAExd0tB33Np07QNoX8/hh6Ch+WipmuC8gOzkdDiWxadRDLJu0lohX31eagktR Z8rXel3wcdauBHGoIeTBl4C17E/KJfjh+5Tr5jwjppRkXO+Pwa3a8qHU6EWbh/+iLPi+6fvd 5CRuRnNvX1oKJ5+pV9aWLSvQO5fU6ZOIn5RAyFMv0a6DdRHZsgj1/0AMQ4qKsltQt/6LLCWU BOo9AemAHTRRwY4UCir226Fg3SL2psjmRAcRVhPN2i5s5y8N2WKZmSJKRR1XE8Gt8ct4fMXb 9BoSTtrXqRjQoBEV4di76PfZXMS66mkb9ygT6bu4q90aTIWVjGXQU6nfFZo23egVDTsX/8rJ HQcU+XbOX8xvSwq57ubmynnV5YtLhWiCOhH1bBQsfIevnyugU6/gsqXtbMqaxe1R4EvHcVMY te0b7nuh4X3/Fbo0uNWQbAaQe6cg4KyrIclOWA7ensX7N7BnTw7tWrmqzYtaV/EMJnH4FwQl PE+Qj50HcTBPGQ1cdKLKmMT5P/UEdvDAfGoniTP2EvDsZAI9C9jT9QlcF/+PqE6RXP/wnSQu BResrAv0WGhOl+n9SBm3gK3fd6Nv3E3Kd9dN7/3MuUFjCPQRvjydDbfOpGPCB4SK87LNm3aj HiFx9Dx+9BzHw/Na8vXIBWS+9DbNlJ7YBfzRu6ryASOKQw8eej/M2UuHKf3xtMklZk5TyvCg qZhLeI+QGVwaaA/oMlyXcbDjp6cuI5VM0pgIRLRpTbPImhdjkMOQGtMdUZWuxiwOzZjBoSqu 7U98mKABLau4IoNqIpD3Szwbpp0hJDqKlNffIS3Sk7RVZ+g8YTLRQzorTqvt9MEsfvQJMof0 pjDdjUGrR2JI/JGUE+GE8Ak/Tvdn4LgH6dZhLTsnvYy338fETJ+LZs48lvV+GVvvYwY+zc0V nK8qmUfM7XRgCaF/i8GvzVk6sICIu9tZxfamyvKTVpEw41vOJ+p47LM47hwYg0dsc84t/ZKU E1GE+K1h3af+xHQ8yI9fhBMSvYZ1H/nT94VoawN5TVTq57XqhiHVJO2az9pQmCf6istNEqia QIvm4BLcB6jZAVeduuGHNrFYLI1mEN9Hx7fyR1bGZVnt3NLlmPrfT3AVD/HLytAukVtTT9z8 fSg1VWo2tYvTTuvLM/41LM0CXIl+dkU51aEYJ1z1eN1yNc1Fepp4eigO3/64PIZzHmk93PAI akapsaRaBW33nVgF6VJWQ5LOt1qk8oKVgHC+ESHgHdQHvy4ba+Ryww038M033yD2zrTJJmgH rRk45G5OLv0vS6et5DwQEjuIG0bH0bbTBauFOpijjFYXBDRuFx8ipvEs7xRlf1wX8jljGZu+ jpU1X2c0bC3qZHO+bpUn3ammDDEMycOj/HdaTbQGFyw7YTlospzvP2Xl1wbavzSSnk/1w7Bx JWsfHUVS4lkHc5DRJAHnJyCc7/kTm5xfUanhZRPw81Frvo46X1GQsw5DkjVgB28jo6k9QxcO VDvn5KVQFNCXuH4Gvu83m4gtUyqOMXUwTxlNEmgoBBxZDUk634ZizWsnp3C+HdvApTjfayft 1S9ZOmAHGbt7HWZxzwcJiY0iY+NeIqbMQts8koEf7yF5y1mC7lKHrTiYnYwmCTQoAhdbDUk6 3wZlzmsi7JU4X2ddDUk6YAdvRZ8Bz/CgZyeO7jlLm/5D6DAgVEnpcVN/Ohx0MBMZDVOeHo2P 2uGpAg6zHlOJx4ULMVSI5OCJWU9Rlhn35t5KxyoHU11RNFNeAS4+3nYDkdTsDHl63Hyc79uV Pazta0bKZmd7IPL4AgJX4nxFZnIY0gVIG2GAqYjshG/Z+cW3JI6HgNh+dB/5EG07y45YDt0N RQeZ13s8PRcvpGuncqdU8Es8i8YuoeeC/9HVOtWkQ/lVEan01E42vbiAQ4fSlVaKu+PUF6Uq otZSkJHjn77Jj3PyeWDLB2WfIkqzD7L11fGk5IzkyfiBDW7xhcpwqhuGtO+XkWQc/i86BzvT VM5Xnjs/AZ2rbHauzsqyBlwdmUrhOavnsexb6DlwOC3QovPWUlpwlh3DR1G6YjHt5YIMlYhV ceoZwdB503Bvqzpf/aFUzG074X1Hf3qyBFf3i/dYriLXCkFnlk6jcNgs/ta7hHyq+iyQy6kU M8G19tKkI+iWGGUyDlc7J+TiH0lkbBQp32nrrBZeAUQtn1S3GpKHyzFayPfPWqbtXNm1DUOZ C925tKodbaQDdpCj/riBPq8/Q8c2FZ1Eu+vht22naB8W7mBOzhrNSOa6RPJwxQVXSguLMeNO 85g2FO5KpahQh0+YjuNLthD4cjsCT61l8eh5dJswjsg7u6CLhnPJiez9/gBZPh3p+kQsPnYO zXwqlZSlW8nL1RH+WBzhbbwxnUrlwIodFBm8CBtyL34F29nzBWREb+J878cI1KSz79NfyTHo CL2nP+Gheva9+RybiwbT7+EucOYcpbji070tpgN/UlAIoffcgre13IIdm9m34TDFBNHl2X7o 167ljKkZkQ/0oODnTWQWNiXivltwcxfzTyex/4t4StIz8LltAJ0HROJif6sYznJ02SbOnTfS rFd/2oRlc3jLSTQ6PwKjfMnaexKTtgVtY9w4tMRO5g46statJHHVeVqEBhDx1GCC/OvPrGta LbiLqbvlJglUQcDdDbQaMFY/xUEVqS4MksOQLmTSqEICY7uw6YFH+aTrgxX+vhx9gk53Nnbn K24FHb7hsH7cDPJadCRQt4dUwfcaAAAgAElEQVRNkxIgqCUeZ5IoaB2JrzabnRsTyMsx4uIq pqAMx7t1C9w81dFwmefdiXiiP65zZvPLinS7+0vPgRcnkNWpPzfF+XHkt0xKT/3GvAGf0fKJ OLy/WMAPP6WhC2yBfwcI6NiWpp5n+b33y+zTXU/79udZM3QkmUUaNKLyHdAcn9DWeBduYv2k LbgEhdLUtJszutZlzhfDUdaMnEGzBwdzXchxThwxEti9GdumxVNg0BHY1Z/EafEU2T1Y/G66 nS73hrNt/Hi2/WI3PM18moSeY8iLHkRkwHbWj0yipHkLTCtns/7bs3iFtaL013Vo2nmws5LM Z06msWvcEjI25lJcXMXKFXaU5KEk4KwE5DAkZ7Wsg3ppO8QyKqETJ5NSOX/iHGajFu+2HQm7 vROedjU1B7NzymhuHXrRb+Bs1v6UTvu7xUvJAg7/nIxnfgxdYpqjNXRU1uD1CdThHSSmkmxK 0I1t8XDTU5oD193TA+/mEBANGRVemT0Ierg3m8e9yCHC6flxD/DtyND4sRSuiGczEOHthsY/ CF8/cAtpgUfRaf4E2rfxwjWoLw8sGICvf3Nc20YRYGxPYJgvPDiSiPde5ujvRwk8HECXZ+2+ F7sFcH0srH9gJHTozb23a9Ao7UVNlSZll6AgRf5yQ8YQdENL/NzupleHBew/ls116sqJgDdd 4z+gOHMz695Lh1jRLO1Lp1efJ3HobDKORZDrfw9d/XLYVVnmluF0nxBFlvERev/12r3oOTIM qZyFPJIEJAFHCMiJOByhhJGc1NPg05Kwu2Lp2DOQjDkL2DRuAlsX78TkUB6NIZKO8L89Dwun sWiJJ/dO6cfO8e9g6GOdA1lxYFH4BelQV7HPx1RkpNSssftOqjavuunsm1n15BW054EVH3Pv Sy3Y9txWTIYzJA59mczgm+kpeklmZaI3W9OItG5uSsenMyfN+HWKxNfPFZPBrKywhNGAWSyp 4RZOt5di2PncK/wRcCN+9kUacjDeOI5HV79Pz1YJ/Lj6OOYCsUpTvmLv0j//RJnUtGwWxzOU itqwOYvMQ9C6QyAuWnUBYheNkT/fe5nv/vCn57PhcCKXwjwjmg7RympMax4Yj9vdndFUJ7Oo +FZ4Ian7e0muhlT3zGWJ5QScdTUk6YDLbVzDkYashe+x/5h4who5MnE2uqdGcufbz+O6ahp/ yCUJy9hp2tzM7dHQc1gfwu65gxAG00np2Wzk5ILlZLCXXQt2YnbzpEWHdH6I/ZCjG35m3yE4 9vVaTu1IIC0ZMn5KIq+seVcDJ9bz3dz1ZJ6Azm93Q1tcjPjEmrH0Z4xP9eP8nMWkrVlDikj7 9XKO50Zw+8xHSHtvAp91fZAVc3eBRoMuKJLzcyawbv4+ReaguHsJALoOiCzTQTlwdaVoxnR+ X7GHvIIY7owNQ9s2hpuEzLdOYuvKw4Swl/0rUzCjJSQ2nL1vzmXDmP+DlybQLfIM+1aegUOJ pG49iyFHLD28kuOGHoQcWsK+JOHMvWn3zCPAYNoKRp6RF8hsObuHXd/lw6r/sTfJrlm7orTy TBJwagLOOgxJLsbg4G1rSF3F/EeTuDf+MXK/P0nHcbHKyjam1I3sOdmJHndd/mpIcjEGx4xQ Ktb0RYf2Upb1M5sxl4Cm2jSnSZp+iB7jbr9gDK+QSizOgJuH8N1XZRPfsrcmteZW++FSF5W5 dkS5lMUYqhuGdGJrLFkZcurJ2rGI8+UiOmG18K+5AUfrKxdjcD7L17JGbp0G8sCEw3w3dLyS c+LCFYDaUWjQxmW1XJrMrioCLm5VTOBRVUT7MI2mGuep5/Abw1i/Cm6PX1il8xXZXLXFGQzp JPR8mVT68eC2W+wlVmrqV8vhVyzI8bPqhiE5noOMKQlIApUJyGFIlYnUcB40ZCxP9hxA2uZ9 5GZkowm8jzYDe9HMv4ZE8lI9JeBBy0deo19cCG07lE8KUmfCugVx3cxxtGvdmUDZia/OsMuC GiYBZx2GJB2wg/ejPvU3DhwMoHNcJB3/Wul7oYN5yGj1i4B352jKOirXuWgeBN1RqeZb5zLI AiWBhkFADENyxk12wnLQqoU749k2KRG9g/FlNEnAmQgEBgYSGmo3TKsBKmc2QpERzGYQn/ZF R3jbuUFvDXNQr6JcyJIPAwdpyWjVEZA14OrIVAoPfPgdRj6oUTpeVbokT2uFgFkZJuQino5u OigxgqvYWztQKR2TbN2iNUqnqlLxREWHiwbEscU6JKiJqwgzYzZUn7YqkQ3ZBWj9Ky/goKfo rBH35r7KUClTdi6lnr52y6mZMZzNBZ9mdmEVcxcLNeDljVZjxlQEWs+r1KOrYrG1evbQQw/V an7XIrPMA/DiZBBrpwwcDs92hMkTIBmI7QcFayE5HJZMhU7VNI2Ys+DjmbDZE8aPgmbX4OvF tWB3rcvs2rUry5cvx9nGo0sH7OCdlfX1h2zI6EvcOOuYVowcnf4maSFDuOOvnavtxONg9o08 mtohKvOut/BZ9wmJq9LVyS8+HEzu/K9IXJoE0b3p1iWQEkM+5xeuhVffJ7Z9KonvzyPtUDgd hvXAGyPF2WmkrvLkwc1PcHrm/6pNe99f29oxN3Lyqw9Z+d4ZuwUVjGSujue78dvpNmUUN8V5 c3L+bH7bXQwbi+i5eiJhQVlsHzOGc10eQZuwl9Cpr9DR/sltPsuuMWPYJp7w9ObBLc+Q8+Zr FMRNoGuMnEDZzgB1chjcGd57Gu5fA5PuRxkn/sbzcP9seG4MdHgIho6C//sFPh94oUjC+T4y Cu6aDPGdL7wuQ64eAdEL38fH5+oVcI1ylg7YUfA6OL/wHb7Pfpp73+yPJzrajpuIZtpDpKRW XN3H0SxlPJXAqU/fYL3Ha4yK7YhL77GcXPUyYW89Q1grHWEThpG5NAnT3fcTM0SdCcoU15Hf EkvwjhlIz2GHSZtUTNe/P0YzpWKpJ8Tjf5gsLYmqIW05eyPpn84jPVOEtLBOCGLm5KevsXLO LTy26wPlO7EYLrRyRhZDd03BdekkFk9M4K9PpvF78iCGfzaUktZHWfzoasJ2DUWdfgNMf6bh 8cw8nn7rKJ/0m0Ze7vO0nziWn3qO4nADW8Dj/PnzHDx4kFtuadjfrW3zptjaUkqss+iIBhdD vlo7jjbDj6vA5AltI+H8H5BhAo90OBgOU5vD8SwIk+9Q5T+jq3hkMBgoLi7G39/5ervKb8AO 3jilxiJCJnzAvQ/msqDrTI4fy8JsKMCkD4cS28/ZwcxktDICpWeT+WFOOv2e6q46P+sTslQ8 EcVWVEihmP7EaFBO9Tt+5kB+NL2fVDvClRSKCS2gREQii30fbSZ0whiCxcvyRdIqCdERPnoM tz0WIxIoQaWnklg5J52bZvag9NhZZeargj92q9fMUCpcbHIGueeE11bXADZmnwGOUqBmocTV tommY3cdR/83DTo8TViwmKErnB6vhrN+6qYGNYNaSUkJ9913n4qsAf8/lAo0vVCBnWsh5mUg Ct7oB220MHE2uLeEgFwwRsDh9RAZCQe3w6BR8OPpC/ORIbVP4MiRI7Ru3ZomTZrUfubXOEfp gB01gDGfjP2ZeHYfymMfh/DjA6P4vOdI1q9Kx9vPftkbRzOU8QSBvC1bgH40C1K/i5oz/iSt EhplxquNq0n6aBEJIz8BD/tvqKK+mcTeTxeRNP0zNu8B+2admtOWF2QqOFd2ojrbcDRF6ex6 YAzz3vgNQ454AcinVLwgaMXyPwfRdu4PLGHTpz9z+pz6VK/8gypI2sxpesOhT/ht9UmlDN9u d0JyItl2zrqs8Hp60KJFCywWC+fOlXOqp6LWKFZRsXrZVhO27bv1hd3fwO4p0MYDOvWBWGD1 Dkgxwl86gLBeaFuIGwj/DIdv99RYlLxYSwSuu+46UlJSaim3+pWN/bOqfklWL6QxYzarEzl4 9hhKtxNb2JUYQddeQxm5OoaMPzLQtetIkNV51AuRG5gQpaYsiO5DU6tPLS2p1LXUM4SwDmC0 NUE/0Z1diVmYw70pdfPFt1uUorGtCTpi6Sryi/R4GMDDv+a0Ypk02+bi7ms7pCQnV2mObj0g Ft+IXFIfTSCvq92aeybxFI+iadtu/G3jXPJz8jkx6xOIfR5/W/uzNTfvmP7cGtOHgJMJbPr2 D24ZEAquYvnCvehzjeDZcF7exHy8CQkJDB48uIxVQzsQ5MVmG3odaFsyWtwLdveDmOf0qZEw 7B0YNgGa6SA2ChZam6zz06GjLa01T7m7OgRcXFwQf864OadWtWUp82l+6TGJ9GMFeHa+hZgJ Y+naS/3VaYPDCY+9nsJFM9n+u3hgy+3yCIjm3APkqy3MZYsyuIge0MqmURZQMBRYI/h0ousd hay79VsMZQ/MIkqsl4OGDKR0+SyStxcoT9RSoOa0aim2H4KLG/j2EM3RokkZSvWibbsVLW4T YU1xdYPSgjMwpL3yrVfj3xyPgsMkboQ7X7wZjTmLAx8tIv1YLnkpqeQptVwz+o0QENte6UWv lhWFh5dNR1WG+v7/ueeew2hsuEsiHk+GhWcgGvjnIsg+DeOnQWQU/N+HcKySap1vA/Gh45Eu qmUGjYXQefD+XJgTBUOuq+8Wcw759Ho9ZjE6wgk3WQOuyaiaUO5YMYjP73sCYgfRq097mvq5 Yy4qIO/wHrZ9kUDEhLe5u5fsjVETxpquNb2xG5CoLvZjPs2uOWsIiY5i3+sf4v72wxQt+S+J h8IJWLWIDScicNVnkroqiYBhr2FOXMWaGesJ6ADb3phJQKgb+QfWkpYcTr/lxeydNrvatPaj R8yndvLL62uUfJLfXsUtr9zDoJeSSHzjv+hWreSmmbPwDm7JX15NIn7oJMRj+YEvhNy5HJ4+ hfULm3Ln4nm0F22XhlMc/OJbvDrdRuiqCWzaGEVEdD75A4fT/0G153Vh+lElD88G1qlTrIjU kLewaIgX3tdu+7ymWWR9Id7uuqYZzFgGYlTZK9UMU7LLWh7WAoGjR48qHf8yMpS1x2ohx/qV hVyMwRF75J3kwJKlbJqTUB47ehD3vBxHeKcrd76NezGGAvYNfYLTT8+l7131q01PvGiVuonx u+VmF4szNPG0zUltxiSWFfSxnZfHsx2JMcClrjrcypqac9nedSSF0z+m9xUs4GHL/0r2l7IY Q3XlyMUYqiMjwwWBK12M4b333iMtLY05c+Y4JVBZA3bErD6hdBw9lo6jn8dsMIOr+C5s91R2 JA8ZpxoC3lz/xdsc7z2GoysW0zas/jTLajzVHs72gldcnEGD1se+Lm0fUz3W+lSsKmXO/4Df h7zG366x871QUsdCNmzYoHTEcoaJORzTWMa6VgRKS0sVx7t06dJrJcJVL1c64EtCrM7AdElJ ZOSLE/CJ5O6EDzh5Uny3vfIWhYsXeK1iGHHp8gQjn2xbob/PtZLmcsrt1q0bbdq0oXfv3rRs eflLcF5O2TKNcxJwC3q8SsV27NjBww8/zE033VTldWcItPU9cQZdpA4NmYBPOKG10JxfvxHo COzetkFPZyomQ3jyySd5//336zdqKV2DIOAZNhGPliOqlFU43nfffbfKa84SKB2ws1hS6iEJ XAUC/q52w6+s+U+YMIH58+cjOsjITRK4XALuQY/jFTHlcpM7RTrpgJ3CjFIJSaD2CbTV+nK3 V+sLMhYrI2VmZiqzE11wUQZIAg4QUJxveNXOt6CggFGjRilTnzqQVYOOIh1wgzafFF4SuDoE hPN91DcSf5cLa8CiRNEJ0dVVdiG5OvSdO1eb83Vxj6hS0dGjR+Pr60ukmPfTyTfpgJ3cwFI9 SeBSCVzM+dryE7XgTxcf53yOLUTuJYGaCWh978ArfArVOd///Oc/7N27l6lTp9ackZNclQ7Y SQwp1ZAEaoOAj8atxpqvfRlBQUGEBbvz6KtIJ2wPRh5XSUA4X5/I+dU6X7HkoJhwY+PGjXh6 VprTtcocG36gdMANxIZVdYZpIKJLMRsIAeF8X/DvUm2zc1VqDOjTnIfuhqenqjNEVRVHhkkC F3O+4ruvWPHo3//+NwEBAY0GmPyI0wBMLR6MVXWGaQCiSxEbCIHLcb5CNY+gx3nx+dZE33yK Eu+maAI8cNPJSWoaiNmvupg6LbgEROAVPKLamu+WLVvIyspi0KBBV12e+laAdMD1zSKV5Lnc B2OlbOSpJFAtgSu5xwLajkD8tb+lPPuzZ8/SvHn9mla0XDp5VJ8IfPfdd4hOV3/88Ud9EqvO ZJEOuM5QX3pBl/pgbK1tSpGb36UXJFM0SgIaFxe0Ri2PB0ZdUrPzxWDNnDlTmS3rqaeeulhU eb0RExD3ifhbt24doj9BY9ykA66nVne0J6q9+HEtb0D8yU0SuJYEXnjhBfr378+KFSv45JNP aNGixbUUR5ZdTwmcOXMGMd2kn1/jrTTITlj18Oa8HOdbD9WQIjVSAsLhJicnExMTo0xb2Ugx SLUrEdi/fz+zZs0qC33rrbcatfMVIKQDLrsd6seBdL71ww5SiisjoNPpeP3115UpK205/fjj j6SkpNhO5b6REBBNzGL1LLGAh+jpLLdyAtIBl7O45kfS+V5zE0gBapmAffOzVqvl3nvvpXv3 7rzxxhvk5ubWcmkyu/pA4Ny5cxQVFZWJ8q9//Ys777yTY8eOcf/995eFywNoYrFYLI0FxPen /2B/zpl6p66rhxuhgUHc7RFWq51h6p2iUqBGT0A8bn799VfWrFlDXFyc0kwtoIwbNw4xFtTH x0eZhOHpp58mODhY4fXpp59y8uTJMnZjxoyR14D6xGXKlCkkJCQoC3RkZ2crvZpDQ0PLbCYP qibQqDphyU5KVd8EMlQSqCsCTZo04fbbb1f+7MsUzjg1NZWcnBwMBoP9JUQaF5eqG+vktfrB RawT3atXL9q1a6f0gK9gQHlSLYFGVQOuloK8IAlIApKAJCAJ1DGBql+f6lgIWZwkIAlIApKA JNDYCEgH3NgsLvWVBCQBSUASqBcEpAOuF2aQQkgCkoAkIAk0NgLSATc2i0t9JQFJQBKQBOoF AemA64UZpBCSgCQgCUgCjY1AoxqG1NiMW5O+/9r0dU2X5TVJQBKQBOoFgfbt2/NEqx71Qpba FkI64Nom2gDye3r1Z5wrzGsAkkoRJQFJoDETaBbRihAvrdMikE3QTmvaqhWTzrdqLjJUEpAE 6hcB4Xx9W4fUL6FqWRrpgGsZaH3OTjrf+mwdKZskIAnYCDQG5yt0lQ7YZnEn30vn6+QGlupJ Ak5CwLdFc6ev+dpMJR2wjYQT76XzdWLjStUkASciIJxv0wjnbna2N5d0wPY0nPBYOl8nNKpU SRJwQgI256t1c3NC7apWSTrgqrk4Rah0vk5hRqmEJOD0BBqj8xVGlcOQnPTWnrZjFfkupbg1 9XZSDaVakoAk4AwEvAL88GwRQGOq+drsJh2wjYST7X0Cm+FFoZNpJdWRBCQBZyKgcXXFK7g5 TSzOpJXjukgH7DirBhVTLFSu0UjzNiijSWElgUZGQOvuhkbrSqmxpJFprqorvwE3SrNLpSUB SUASkASuNQHpgK+1BWT5koAkIAlIAo2SgHTAjdLsUmlJQBKQBCSBa01AOuBrbQFZviQgCUgC kkCjJCAdcKM0u1RaEpAEJAFJ4FoTkA74WltAli8JSAKSgCTQKAlIB9wozS6VlgQkAUlAErjW BKQDvtYWkOVLApKAJCAJNEoC0gE3SrM3DqVLDXoMebnoz2ahzy7AXIXahrNnKTibi9l6sdRg pNRsxqykLcBkqCqVGb1IdyoLQ56e0gr5irRGJazUrO7BGmY2Yq4yvwoZXPGJ0MFsU6hSbqpu NrlsF40Yioy2k4p7s56iUyqjauOIFEI3oxFTkZVfkV7laJXDVq5gY5NNYa2UZkaRWVyzslOZ Wdkr9lCvVc/PqNiiovBQWpRLUbbeGizsllvxPhD6VQ6rnAlmNW+zEZPhgosyQBK4bAKayZMn T77s1DJhvSWQlHeCs/r8eivf1RVMz9GPphH/7Fx2/fd7Spv6cW71Mn78x2yatL+ZkLZ+QC77 3nid3w+Yyf/mTdas9OfGv4RxZuF/WDJyOjt2n8O8azk/vfo5513aEt4jFA1gOraTX2JfYOMJ 8Dy1h1UvTifdpQvX92iuqmTOZN/kD1j+j9ns2Hgcn/adCQwuYP87/8d3L23GI6YzQaFeV1F9 IyfmfcjXo2awfbs3N/wlEq21tHNfvcvCJ2awY7eWDnffgLt1ojTDjiXM/8s+rh/TpSyuSJKT uJz/xU0mz92bgsTvWfOP/9Ak5h5Cgt0ryl+UTkLPN+G2UHbf9yJrP40n/bQXIR3M7Jr6Hj++ 9imnT+rJO5DC8Q2JrHlpOu53DKBkw5csGf4229enYjp3hpNbdnFkwdusXeHPjQObsv/d//Dd ix+yfecZLCfSOL5lG3tefJeDPtF07OxfLoPhLHtfGcGKSX50HhOpTnBvzuLwx7NY+vzvNLuj C4FBBez6x0T2bd/BhiXnuG7gDbie2cnK3h9SFJDFtjd3EXRPNzyrWIjn3FdTWPy3Qjo/7cfW 6P/g+uAt+HjJuku5AS7/SMyCpfXywGKu+Bprn2MzjTvRHi3sg5zmWM5V6DSmlIqUE/Cg7Qtv 0Ofoo2wqeJ6eo2PRcD9RcfEsGP0y5o/n0iNkL5tXhfPwrqH4cSdu036nFB2hTz5Dn8QEDt49 hFuHhNImfBI/zHmH9AGLae+bxpoHppEx7DVGjYtGPIK7PNKTtW8dxUAnlGe3piVRU0dyctXL 8PAjdOzuq4h1/SuPUdDWlagYq6MuF7aWj3SEjX6CTnOSSE2ex5HUO4jq5A2GdLa/lwT0Zujc ofiJtwllM3J82bfK0dHUODUuYEhZxdfPLaDzzLnceoeQeShR/ePZuucMWHVS0+ey69aXYeZc 2tzYnPDvnubQA4n0nXo//hq4+cX7SNk4m3ZPPsb1HXRKkus6+/BniQuhfx1Fn+S1bCroQ88X hI1EwX1xn3qAUsFxwjAylyZhuvt+YoaEK2lNcR35LdFu2kLzabZP/Vqd9Txaq9gEzrK9xxiO PTuZUbs6K2EF62aybeM9PL2rPweGPsjGlTfT9dA0Moa8xn1PRtMs8UGW/e8mnn6hs6qW9b/p 0CqWvbcXYnvhogml13fd+LzfZzy6fQw+ZQwrJJEnkoDDBORrnMOoZMSGRcCMuUBIbML2uPaM GUCvaNg5IwmDq3j3TODroe+yd90ZOr3SX3WgFKBPBoxiIYtc8jL3AlF4eevI2riaDKDXwCjr gx5cmnfj7g8HWtNaCZWoTadGo13ztdL0XALmXNKXxrOi64Nsmb+cpOmL2PvLUUqyj7Lvo5l8 0vVddn21nC3T40lPzbVmmEv6V/FsUeKmU4qZokO/8dPQd9ky/b8cSLHFs0YvysN9yCA6AImf JitNrgWbk/B4apCic9aftiZZIPsARw7GECHiLkyxNs/qSZs3D4ghMrr8hcEzZih9n4y0FqLu Cn75lm0MoqvipMFihV1qbao1FxcpEUuLRZlmMr+KxxA7gq6dxSpdekyKjYoQDeCl2alsX2bg 1jettigqVByr0ahmpt/xMwfyo+ltL4OmJT3eHEuXPjGQY5NpJb8TRffbm1FwXLAxkrk1ATqY MIuS/CDjzwwKTwK+Qg4jBcLme05RoYXZfJLk+UX0m9AbTqh5a9rcTq8Oa/nlu6NqgPwvCVwB AemArwCeTFqfCZQ7v/KbXINWPG/9tGjDbuWBKYPgUBKJ4yawoOdMMvOAohzOABkbv2NF15Fs Wgq9Fr9CsD+UmooVhbWVWmAdouCqITs5DZPGm6Z+BYoj9+lwPcER+SSOfYXdh3S4G9KFRyCg 2/X4Ff/GmkencDLbyPHpI1nznSeRd4eQOPZldqacIm3+dNIOJVFcXMFlqKKUmNFc14suU3rD xtmkH0vn8EZPou4RbhaKi8vZZK3/EYbdS8RAYFU8GdlqFmoMX1xqrOXpOb18JQxsj61RPf+w cEyeaiZ2/48t+Zakj77ku/eOYr9GiGKb5CR2frSIrVMnkGGs2Cgn6swZG1eT9NEiEkZ+Ah5V C1RqUh294mw3r4QOwZjSkll830gSVqdTJNBiUr/Xi3sg4RwthgyGLyawfekmiqIBb1sNWhX8 5JylBL00lCAv1e7qfeRByweiyPg6taKzttNVHkoCjhIofzY5mkLGkwQaCAHlq5J42JZtRvSi JpNjUjr9+A8awdPb5vHAzJEEkEBGegFqOyhEDHqC+9a+pqQ8tvmYstd5qc3JVj9clqtZdDgq O1Mqemp8nZ2zEF6nQDgADb7hoUrtMuSmSMKGPEGvDnBsXxF+ES2gQ1tCOkVy/ctjCCGdsycy yVwIIQODcHEP54EF79OhVRDX/e1pYCR3TBhDaNa3fNL1QeVv6fyDStlmoyuB/foTAqx94GWK 7r0NvwteHLI49lMRgaZTmML7AensWy8cqAb3AJFNLqXlvlrJV3Syst+MBRDSrbUNG6WFFWvj 2vAOigyiCTrmhRE8OS+GvJMFmLJFPG+CYqMguhc9X3iMWz+cRyRnMBgK0BeZwTOEsA4QIpqg X3iMuxOmUZKWhbkoF1MlucplMmM6L16yOtJhwP08+FI4qd8exCUIOGSNJWrdvVvj3+sxHl8x i3Y3+JOfDBF92pZ/AzccZOUXCax/fRJrxifBoU/YtlpUmcFF5wmHMqmD/nTlajXiI3/XC25c p6EhHbDTmFIqUpGAtba78Sj51spRQeLPbDsE3V6KweXgSuY9sgqTmy9Bd/TjOpHYVaP+KS3Q RdA8mn5DIGPOZA4c0uPTd4DarLtwa1ntx3BoI5/furLsXJFBo1Ee5Gn7/yzrcWs4uAdjdAel qVp11mesTeNmSg5BsxaiDlkEh6y1NMxKLdnbzwuPaMjYnYl727YEhntSWmzGUmIqU9ft+gE8 /N0s5a//wDBEL6QSsVrPOJEAACAASURBVLybZye6PiW+nfbj+l6+YEsj9BTvCakJZEQ/QY8h /YkaPZLbYyFt2i/koSPs4eeBJPasLW9qzfp+JvPmHCgr13aQsT+jTE9bWJlHtr6DGItVx+3W PZawkl/4/mP1RUGJn2P7TOBLxyc7c+T5iZxS/LhGebExFFhr+T6d6HpHIetu/RaD3btNWZnC OeJBC9Ecnawa3ZSfDh1DaN1fvGB4KmKZkqFzd/ESBB5hoRh3biCNfvS8J5zS7INsn76KHGMY D8d/wNDXn6DzEBFzEG26NisvqkMQbtXIUB5JHl0pgbZaX+72an2l2dTb9LIXdL01zZUJ1rh7 QRtJ/3Qm63b5E9LuFIfX7OL4xm/Z/LOJ2995na63tEDj50fpt2+xeu1p8jYuw/DQ37mpb3NO fr6QozlNMa9YRE77vkQNjCJ9wa+kxh+kedy9dBl5E5YNX7Hmi10U7V7LujdX0mnCY7S9PoAm NpO5+hHQ2Y290z9lx/o0Jd6+vcHc/nwv3LVQmnWEnfHryTtVxPmVX5N+0wjueioK07497EtY TkFBEQdnzyVs7PvcGBOCX+e2ZL/zEQmffsOOX0206R/Osc9/oJj9ZJWEEH5zOzz9fXD398HN PYddU2eyY8EySjv15bpb/DntGUXnztlsfWMVrqFBnFm1D22zfLZPX09R1hmaRndHl7aJlM0G PL2Oc3BtHmGPDqT7HSEce/Hf7DqQzellb7N5Edz+ShzNW9hqJFo0xjT2rW9K14ci4Xgyv36w Fc92LhxJyKBFJzO/vzaPPC8/snbv49zBQxyJX86G6T/RfuQQXLYu5tf3TuEZcIxTu4+R+Vsi u16cyR8Zd9JzbAsOvT2DxF898Dx/gNMH0zj+08+see1LNMMG0/nW0LLv8HmJy1n3xSE8OUxW URDth96B9tCXpO49xsH/BXLHmwMJ6tIR9wPz2LxsHee6Daf3k9ejzTvKlmF/45fTPXlw0RM0 83ah5MR2Vv3rc1oOHkpImwA8/P1xzd7HH5si6fXK9Wgwc2rRDI62H0j0rcHlNrfZXu4viUBN vaCF833UNxJ/F9v9dklZN4jITSwWi6VBSCqFvCQCHx3fyh9ZosuQ3K4OATG210wTN12ZI7iw HDOmPD24eqD1LK8umQ79zLyhO3kwYRzN3MDFWpXKWjqJ+J968eRnd6I1ayp9f1XL07ipPYkv LOsqhogxviUaNFVV+YqOsuLWV7hh9Te0DS7X8SpK43DWgr3Gx6OCfUQTutbTytBsxFAIbj4X Y2pWxoNrBfu8VD7pPYF+qxfTNvhi6RwWtdFG1Hq44RHUjFLRYmO3NQbnK9SVTdB2RpeHkoDj BIRDqsn5ipw0aH28KzhfEap+/0xCbyh3vqKHsD5rLySL75uVna+a1zVxvkrRuqqdr7jm2Zb+ C0aydsCX5FXRH0xEuVabtpLzFXKUOV9xotE54HyViCjOl1z2PjWBTtM/ls73KhrVR+Pm9DVf Gz5ZA7aRcLK9rAHXU4MaznJ42U7wh2JjMJ3iOivfJc2nUkndeBp3XRHm1jF0vOrjhWuXj+FQ Kvl+7Qhs7sS1QsNZTh2E4M7lQ7Nql2Ljy61yDVg43xf8uzh1s7O9laUDtqfhRMfSATuRMaUq koCTErB3wI3N+QqTyiZoJ72xpVqSgCQgCTQUAo3R+QrbVBz13lCsJeW8KIHW2qYUuYk5j+Um CUgCkkD9JKBxcUFr1PJ4YFSjaXa2t4RsgranIY8lAUlAEpAEJIE6IiBrwHUEur4V89TO5+qb SFIeSUASkAQuINC6TTiT/F69INwZAqQDdgYrXqIObX6OIq3wz0tMJaNLApKAJFDHBFpq6KPp w6Q6LrauipOdsOqKdD0pRzrfemIIKYYkIAnUTKClBiJsq1nXHLWhXpUOuKFa7jLkls73MqDJ JJKAJFD3BGzO171sgte6l6EOSpQOuA4g14ciYhPulc3O9cEQUgZJQBKomYC/i1rzdXLnKyBI B1zzreAUV4Xz3XT+V6fQRSohCUgCTkxAON+OOmgEzldYUTpgJ76XhWrS+Tq5gaV6koCzEGhk zleYTTpgZ7l5q9Bj5I5nZc23Ci4ySBKQBOoZAVHjbUQ1Xxt9OQzJRsLJ9iMPPsd/z30FXvId y8lMK9WRBJyLgFi/oxE6X2FE6YCd61Yu0+aY2wkIrF/rs5YJJw8kAUlAErARaKuFRrosvXTA tpvA2fbirdLNubvwO5vJpD6SQKMj4NEExFBfY6PTXFFYtk82TrtLrSUBSUASkASuMQHpgK+x AWTxkoAkIAlIAo2TgGyCbpx2dy6tzUCxBQwWKAG8mqh/9loaSiETaGZ3zSB6QVigGBB5+FTR ZF9YCll2ebrZZWq2lid+RSIPsYmyxVZoAdcm5fmLcCVMvazIKQ5F70/xqV6Ub9uL8Jo+34u4 Jdb8q4qnyNUE7GXNs1Stnygrs1QtX8hYFQOryIr84ljohQWw7m2fOgR/2ybChJxis+klZBab SC/CRPzq0qoxK/63MbXXK6tU7WhoHyZ0Ffnah9nnlGVR7wNbmIgvdK+KpYgjyrXZ1ZZG7iWB WiAga8C1AFFmcQ0JHDPCjeehZxZM1sPKYvX4RT3kWeXaUww9CmGVXr22zwKnTNDjPNyYBbOL 4NYsiMqHYzYnYoF5BdAzG9YaYFwW9MhRnbFN3d0G6JGl5jG9SM17cCGIB7ooS8k/F1aJtwIg Ucgh8smCZSb4t0h7HqJy4LdSNc6yQjVsm/VchO4xwimbXMJhCtmtaXfYxcsrgSirTlts3g/I M6n6iRcJ++2YSY0/TQ/f6NU4c032McqPVxXCbBN8Xajq1SMXks0QX6TmMTgP5uphRhE8kwUj i1U5/56jXn+jEOYWwTtW/faV1py2vGTV2c/Nh38XqWXvseos7DNZyJMHp8RLTCmMPK/qIdj/ asdAyc8CC/Ohdy4UWgvYVqzG/8OOb4WygU1FUB2XynHluSRwCQSkA74EWDJqPSTQRgcrvFXB nveEkZ6w1x9OCKeqB1EbnFEI0zxhjBd85KnWkoO1sMILpQfIP71gi4/aE+QTqwMSD+oPDLA2 AEZ6wLwAeN4VTtg9qLu7wzRRzdLBJC/Y0BQOFsMPZnjIE/oCMR7wkHVC+f4e8JoWYrzgcR28 0wxihOga6GL9KQqRvvSHnnY/zS3FqoOx4Reyf+Cuns22672yQa+GTfSDWLvq3GZR1Qd+tL4I iGPhrO/Lg+FNYZYXjBXy+8C+yk4L2KGHfwL/1MFIL1XmiU3hNg0M81L19HODsZ4gWP7HD4IA IeffPdSyhV1EGZO8YZo7lDSpOa2aSv2fWQKzXeAdL/jKA74zwykjfFAKs5rCROANA4gXor/4 wd5mMBT4wP5lwqK+ABwRWVrZbNTDGqu+NbUFDvSEpDz4uQo29nLKY0ngEgnY/covMaWMLgnU FwJ6q1Ms8y8uMFl4siI4YFGdwYQcmFkMoW7QxdpMnG1NJ2rKJ6y1qsgmYDDDOybVUQbbKTnG uzytLdhozUP4uBw756w00YpIFrUp1v7ZnWNL3ATebKo6/rdELdcIv2uhu/VnWdak2wRMIh/R zG5Nm9MEhusgqRAOinLNsNVFdYY7ykAApfBTqRr+jqG8WXiDtc38PrvVZoK0MMvq2G0iivSP F8FHVkdqC7fpLfQrEIFW3bNMEG+Bd6z52GwjPhGIbaEe+npZOV4krZoClKyK4V1Rw9bDnRpI sTpXhWsTSDLDDe5wn3CuTdQ0rax2VvJpor6AiRcfm6yxHjDBTt+DRngtD14shHmi1ltsbfFo AuO84OWi8pqzTTa5lwSugIB0wFcATyatxwTKnqtN4FVfiAQ+K4TB2fCN1UHtE3sTTMiDhwpU xzBSq35fFaoF2T/Aa9K1CcSLvAsgxhMesKtOJRXDGwXq34t5qmNvZZdXsA7edYeV+dBPyCIc hPg+WqI2M4smZVHLfSpbbep+xuo4jU3gr1YlvzPBr0YY5A6eoona7kVAOBXxMfQ2UVMvht+t Lxo2B1rJr9pJph6KZmqxRVhZiG/pSWpQhf9JRphZBJPzqh5S8pUeZhbCOyVlFdCy9BdL66OF 4cCCIrVsoaPyslOqtmbohGwlYLB+xz1ugAUamFDFR+B8uyZ7IYDtu7Q4FivwrDRBgAZu1sLs QvibtVUhXNjUCOl2bMsUkAeSwOURsHtSXF4GMpUkUG8I2N/NBXYPSlcNfBsAx0vU77pLSuAh V6XlWHFOs7xhynmIN0KmO/hanY29I1OUFDXQqjr3WOABb3jU60LnEuNeXhsUeXyTB0sqEbtL ONJimOhent7NFXYHqOfz8qGrl1ozLqtJi5q9Fp4XjiIfFrjDXhf4plLeq03QVQtGa7PrIiP0 dC+fIc3qX8pSVe5wJGreook9xMrE3mEpiZpAX1GL1sFYoYc7zBPOUHRQawKK40L9NCBaF243 wEkLBIqOUKLGXkNa0YghNsWhukOCO3yUA4/rYar1mtgpLxNaEF8RCktggAE2+EGAkN0qty16 TZP8+7iozeudtHC9Br7xgoeKodCjfMqig6XqNVt+ci8JXAEBWQO+AngyaT0hYHO8omOP2EQT 8rQilOpgR9RONqLjVZgrPOoOB61yK5XNUrVZd7RoCjap333dNOq3XdG8K9IpmwVezIJdlWpQ IVbHJmSwHloTVL1LNYFfpUs2+SsFl+VnFF7X6khsZYiKrajAP2StworvqrY4tnxELfoXLYx0 h2EeMFEHGwrhOKA4ffG92e4b8kED9LR157ZlIvZGyLByUHpAC39bybGVNau7gGhFeCZX7QRn 082WbXc3KDHAR3bN5NWltYmg1FpdoJkGHhdeuQncIoznovZ0LjDDUFcwm6FnLkzzUB3xqALI LlVr5mWd66yZWhsP1B7dleYEtL28KS8bWmsTuFXftvKRaTOL3F85AdvP48pzkjlIAteCwHEj DC6GGC18mQ8bNLDBCMO91FqhcFgfiI5QWTDUDdKbwFpPtRf0l2a1xvNoEcR7wHAtLCiA4CZq hyGtizWdO8QLD+IOk+0ewKLsMXqI0cArenjfo3zoyzdFcELU7ophrguM0cHCQki3hs10gbE6 1WmIl4VIDSwphOZeFTtQCaZ9vSHQDq7oufuBHn5tAvPcYZAO+orab6Fapl8xfGiBFPHB2AV+ 1UEXM/xqdaID8mG1N2zwhWkFMNgIkRa1+XWir11BlNdglZqyBf5bpLJekg9+3pBpgHdKIbIY XjODhwXiRbkeYDbBM4WqbjMKoKMLnDTDBvGi46vyqC6t6MRl2zq6Qd9seLEUhLP90huCXeA1 YXvxAV8L87WwTPkYrX5SEGkjPcGtFD7TQyc3cC+F14rVzxHTiuEVLUwV3aE18E4RTPEA0Z/v gyLI18BnZvimqfpilWFtemhZ6cXDJqPcSwKXQaCJxdJIJ+G8DFgNKUnsqTg2ZSU2JJHrr6yi OdU2drX+SnllktmPya2c08I82Cua0q3fpytfr6tz0TxuGzdtK7Nyk7kt/LL2FhiZBX19YVil usnc85DW9NozuCy96nEiMRVlC431M0LVcvZxvZWNTb+r+mIDD7V7nW/gmkjxJYGrRUBM6mBr +r1aZVzrfG0TYlQlxzBR082/9sNwqposozYnyBC9zEUHs/O2zw5WGHv0MNsdplzjF5CqbCPD GjQB6YAbtPmk8JJAXRBwgXn+UKl1ui5KrtMydptgmjcEiHHGdk7Y1RW2e5V/XqhToWRhzkyg UjuLM6sqdZMEJIHLJ+ACPS8/dYNIKTqIda9C0uvFd3u5SQK1T0DWgGufqcxREpAEJAFJoJYI PK59qJZyqn/ZSAdc/2wiJZIEJAFJQBJADI3/ByPcH3VaFtIBO61ppWKSgCQgCTRcAo/rHmKE 2yMNVwEHJJcO2AFIMookIAlIApJA3REQzneKxytEuLSuu0KvQUnSAV8D6LJISUASkAQkgaoJ 3OF6S6NwvkJ76YCrvgdkqCQgCUgCkkAdExDOd77XLKev+dqwSgdsIyH3koAkIAlIAteMQGNz vgK0dMDX7HaTBUsCkoAkIAkIAo3R+Qq95UQcTnr/P+72EK09QpxUO6mWJCAJOA2BUg1TvF5t NM3O9naTizHY05DHkoAkIAlIApJAHRGQTdB1BFoWIwlIApKAJCAJ2BOQDtiehjyWBCQBSUAS kATqiECtfwOeNGlSHYkui5EEJAFJQBKQBGqXwIgRI4iIiKjdTKvJrVa/AU+ZMoXJkycrf9WU J4MlAUlAEpAEJIF6SeCXX37h6NGjpKWl1Yl8tV4DnjhxIrIWXCe2k4VIApKAJCAJ1CIB4YCF D6urTX4DrivSshxJQBKQBCQBScCOgHTAdjDkoSQgCUgCkoAkUFcENJPFR9ta2kT13WKxEBsb WynHYlI2LGf5z5vJMDenYyu/Stcv8bTkLNuSj9OyVeAFU3md3Z9CrncLmorG9fwjrPnpEC06 tsLtEou4nOjpKSmczs7G6G5h34bN7Ni3jwPHTmLxDCSwqSpBfvo2ln29iu1peQS1bUNT1xKO bNvErztSOHDgAMdOFhIQFoyH8mpUwv7NK1n2/SYy8Kdjq2YVxCrJPsLKr+PZtCsN79BIAr1c oDiffNxwu5RXK8Fz1zlaBTtml7Mp2ziua0mgKmQFmcTJ2R0bOGAJJlgxwgWXlYCS/HyMbhoO b07GEtoKIfrFtrMpOzjt2ZxminLF7N+2B02rYDwqJSwrX6u/KIuSsykkHnUhvIVXWS4X2ghU ed2qmLmmhPx8I25uF/uaU0zKtlSyM9Mo9G+FX6XoJdn7+XntFvYp90AOvsGt8KoUp0xABw+E nY66BBJgPMymtVtIOXBAucdSDpzEL9ybfeus96gITzmGa1gETY4l88uWHYocBw6kcNLYnDZ2 bCoWXYMNrGW3qFYJcd//zJqth/EMjqCZhwuCwcrvNpHjE0Yrv/JfbMaOHRQ3D7beIyWkbDuI b6vAC2xxoS2z2bb5MIHhLSrEtXGpSrbs/ZtZ9XMqbq1UmchPZ8OKdRwr9qNNcNOK6itn4jea SGGLcNWm4reUeJyW4Rc+myonzj6yg9//OMyfp09z/mQmRV7NFQ6V4132efYR9md7Emj7HVY4 L+HI5pWs2Z1Jy3bhCtuz+zez+udkin3CCLbjX1Z+hfRQnL6Dw6bm1udOBhuW/8SBfDciWjVT nssXza8s4/pzkJ6ezsaNGxEdsepic+Cxd+Vi7J8/imHrjNx6a1f2j49g+FdHrixT/X5G3xxP fhW57I+fx34TUJzCcJ/27PFuSVU/myqSXmHQWTYuX038h59wuvgoowe8R5ZOBwWHeDbUh09S 8uHsGuIi5tEs+lZaF3xNqMd7ZJPPspvvZLfRG39/fwp+n0qzEV9RTDE//L0HD6/OIjq2K2lv t6fvrB3lMpYc4ZVmozjVOpro1ufpFNSfHcWwY1YcM7Znl8dz5KjkKON7fImjqY6vHs+Xe6ui rxZWVJhFjrBBtVs+c26LIzk/nx96j+doSbURK1w4unwEX+yylavnh5tHsNN2ahfTVr4jLEqO r+b5xfvLU1djI1Xe8mhlR/m/MXFGctlp9Qd6tv+8kR2//syRKmTOP/gDc7dmodPpyPp9NkH3 znLYHtWVeXT5aBbv16M/+AN3/mu3kreIq8MLD5PdPapkYKSouIRjP4znvd0FiFv34pvVBlXc OLayq8tj//whtJ93mnbN0hncbCLpHOGVPq9REObNkog4NpwVKUtIWfo6oT1GcFQvTrP54XUt XW7+AXFaeXM1HaN3l7ll3IpTFnDzp8dwrxSxOtmK98+nWadvaRZWwOQ+z5GSn8G/b/sLv+ta 8OcnA3h9TUalnMSpnp979yZi/Br1mng29a762XRBYlMOR44c50zq9/S4uQfbshz8IVyQ0YUB +ekbGN6sPfHHVVKVz/fPH8Go1UbaGVcTNOQrclJmEdRpNS2u8+bDMv7l+VZOn7FtPh4RPfjh qLiZi5n/SCiJuhZkLRnFxA0Z5F8kv/KcG/mRpRa3yZMnWyZOnHhBjtvfjbUM++9WS564ok+z bE/NtJhObrW8FBdriYuNtYxftN1iseRZVr872hIbG2uJHTbTclhvseRtn2mJe1dcq7TlbbXE dZlpyaoULE63zpxqSTi8x/ISWOZut8bQp1nmjo6zxMbFWoaNj7dkWfIsi0bHKuddugyzrE7T Ww7Hj7ZAF0tsFyyj5261mCwWS+r3U1V5Ykdb1qedtfx39GjLVkWJNMvUYe9a0iqUr7dsT0iw JKxfb0k7u9USFzvTordeNx1eZOkSt8iSnTrXQpd3LYez1Ctpe/ZYMk1ZlpmxcZattsgn4y0w 1ZKVl2DpIva2MkwnLevXpypyKUH67ZZY4izr09QYWYdTLZn6VEVvRsdbsg9/bxkWG2cZFhdr GT0zwWLS77GMHzbMMiyui6VL3FRLap7Fkrl1riW2S6wSRuxcS17eHsv4uP9v72ygo6ruBP47 u/lEJxJCIAYQIUIjlcFGs3wZcCil4AeTBQSko9V6OnY5roYWYeNZ6TZ6sINdJWyXTehiUEkU E9kkiokumcjEQlJMbCaVZDWBRE0KQSYyEWcyM+3dc99kJpMPKi0Y4+HOEee9N/fjf3//r/vu e3nPKEwmgzCY80SnxgkBCHNetSjMlAyN2n52rVPY87OE0WQSBkOGqA4KKkRzYZbIs3eIfLNe 6A1GYdDrRXZFe2AkwtUsx4gwZL4sthsQyDLohaWiVbOP/roKVhO1FqPICnbk52ZzDqXLLJH3 3rtBFt2DbE2I2rwMv2xSjuw+G3MNoaOPmgLyloj3K7KF0WjS7NZS1ioqLCYBBlHY2DHIfvvz 6RS11bXavxBUwcE5bNkip1Zanfw4RCYGUd1pFxkGvQCjeMteKczSNwwGkZFXK7zCJcosJqHv 9ZfWQNXeFuRXgJez1iIMWdUhv0h389uoZs4hv2h1bENJGFIouBnQgUPkZ+VrtupqzBcZ2bX+ vg+9IzJM2aJTlu+sEOaMkmDNTnutaNVs3iUsGES5zSIMvb7urLYIY7ZdCKddZGfnCLPeqPmd 014oLJZMoTcM7ftCuES+US/ye2GUmQ0ip9El7IV9flzW7AxyCQrTuyHHbqn1O6LdYhCZ5Qc0 H9SOOCuEKaOkz/+ClZ0ix+j3EYsMDt5aYdRbtBhTltWrH6NF87dglQEbrYUZwpRjH3DUv+u0 5wuTyaz5sTE0dkm/641dgys6RaHFIvJzskS25i8D9x0i25QhbI12YauwicZ2p3A0Vgt7p9+I bJkGkW0PtYwB9V2NwpKVI3IyDMLS236O0ShK2l2iMd8szHmNX9LeYIlHypG3335bLFiwYNjE kUvGl+xzvgQsRKcozJIJDoHeLGztLmHL1AtzoV04HbXCiF4cfDdPSzzNToewZRuEQRqk1ykc ziEiy19IwPYcGRClQxhFII60l5gFGSXC4WwXeUaEpfYjkW0waUnPacsU+qxqIScJ5hKZJNpF lgwaWoIziIp2h2guyxSYy0RznkmYSzqF154tDJYBAS2U4kD5XAGnFKK1IkcY9X6HzSyUgbTX gWUg1Y7LYO4QMggZMm2hrQ7adjaWCbNRBmiEMatEC4BaEKl2iHZboahodAhXu02YjNnC4awW ht6EXp1lEJm2D4TFYBJavGkvEXp9tuhotYkSW6twOZtFpl7yc4psvV7kS3lqLUKfUaHJIB00 q/q4sGiTnFbRXFsRdF5ZwB/4P/LXbfYK4awQei0oBYbg9E86nPJbL/JlGZdNGPQWcWyQrvoC gb/dQHLwt2FzyCQwUJf+RB1gMdDWbB19LDorMgfpcigdaZMkp1dU5+eL2k6X6LTnCeQk0Fkt Mi3VwtU40H7fOS+fAIXQb2dtjtDrjcJsNmv2oc8sE15NZ5mi2dWtJZa8RpkKHMKiN4iDR7IF Zn9CayzM0SaRoe3J7QAvpz3HbyNGozAa9MKQUSic0ibl5EMeMxqE3pApZPP2HDnB0gujUU6c DCKvXyAe2EMgAXeKnIwcLdFqdqv5k9RBpygxG7SEKH0ns0JLxf0asVkMQm+xafYVsHf/hCFg +y7NVmwBMwgmuH7NBHcctixhsMhkZhdGfZbo7LV72bOcCBtMheJ3/SZywarahB+DRdTaKzQ2 ltrfiwz0Iq+6VpRkGQTIxDrwIxmYRXWrTRgwi8bOWmEyZIuParOF3lymFW4tyRDG8yRY4bUL E2bRPLDZ3v3+fqfX/C7baPb7bWuhNp4hIqRW21WdI7Jtfcz79p0iR48wWvJFYbZJyAm7f9oh RKuMdXIyLrzC4XBo/wLt99X3C2cPcnSJkgy9wOiPvTkhNtPX3nkGOMIOD3cCHoYlaDfWgkMs fDxXuz7s3DeXBcv+g/ePAccryXvxHeZZNhDv6QS9g4MFr3CMpdw7eRSE6YgNXL/QVqBaaJHL XdHh2rLHUIsX3p5R5DS6cNkXsWDME8iVrJNNpzDQxCt5RTjnZXPzVRA56xamy7WpK0YTpzUU Q9J4uVgdzbixkeD1EgO8+9orHGxLIDslgnFGM18U5rH7uaOsX3PTUN33HYsLedPFqSZOxI3j 87pSGic/QHG9QIhWXHfdz5EuHz1OI7YSK9aDNozEMH58LLoZc+HAkb5ldl8TO7aV4+7twd1m 5bUOPbnF9Qjh5UefGHm6KrAWGIbX28GT//Iv7Cg6AuNjwOdhjuVWYoHwyBii/76TFlKZJhmM m8iUODc+VxeFP3+ErLwDuKaMJyLMB3FTSJoQC94eGOO/Tpp4wywiPaP5cXM1PUVbWXHTkzR8 PHBdtbfuuDAIv4IpfWS0pUVtN1wuuU0hSZYhQuN9apCupK79H2+Pk8jwwIXRbk6emUK8zjeE LgM15LeblgG2lhjuYVpmqsZCF58APX3lT59HR1qJcPB0H2XjTzN5qbIe7Gfx+TzINU7vFwPt N+FL+PT1Kbd8g0wZQgAADlpJREFU3h5WPfFLfvXLJ8l720X91qWE4WGWZRlJUYJPnXr010pl xTL3B7Nwd5/FkDRRayQ5/YfcOmHgQmtI+96zGCx2iouLKbbWY312FTqvFwzZvCGPFVupt24l WY7jLFhqa7Sy1nor980c4gKOu4MGbR299+p778qplCB6VKgcYRgeTKfshb0UFI/l3gXxIUJ1 U7RhFv/OL6jflAbyksXovuvwE8YF7kcYsNjskgVD+whpUtJJW8es8mKspS8xfvM64n1S1/OR PYdNTiZmbyPn+lcJ7ulSzDT+Yir2//OQbtbT472GLa27iGhsIiJ1DaasmzWbCVYIbpyCCWns K4vj+jUbscfI+HGWuKRxWonxU6bgbPssWDp04/SRYtotD5IUejB02xvFnNTJ2pHRCVPA4yNy yly/306YSoz9eF+MCK2nLY6HGHa/fR9nMfLEpnWsevgZsr7wt9FQ8CDX5kym0/ogOncjT9+/ kpUrn6ax17VdoY6CX2Val91HeXz7KlzFLyKcFex7pECTqV97A2RTu34Cw5CAw/j80F0s3rCH mro63iwsxrBqDvOXTeHDqO9wz6rZNOQfIWKiHr09mtQ772Ty2cN8QBjutiqKrG1BXbk+KOC6 lblUFRdREneVLEFVUREtgawEnHOPYtr4KKJmPowtawvjHrMydfE8Kj8dx5333A6Hi3EAPV/0 oMUNbw9nXB68PSf4zOOPJPI3oscyHkhevIKFV5/EejYcXexc7hq1mZ9Yb+H7k33UlJbSFtJ3 UFDAWWnlTauV8tI9LLr2B2zYuZL4UQ6WXbeKgqoaaqzlbEfP6GhwVzrxyq7j08irvkmbOHTo Ulk/ZzPGbaU0tTSQe//17CY2GHqixozmv787gW2lVdTVvMGBXXBDYjReTnD49+9x8MlHSN/y c0yzr2LvrgpO+byc6fVHOVbXn6bzvWm72V7eRN0ruZRUQkvp43Tf+wSPGm+gvmQX59xSthN4 ZGBNmEVc0VvUtTRQYNlOT8RJfr3iKaY/8CS7cmJ45eip4PC19j19dfF6OGHvHwzcZ0q0G+kC 7QfKJA2hq0DDk1LnsPn+7dQ0NWHN3cxT+vlcFza0Ll0eGSAki4+4cYCteaMS4altlDa18NZL j1AZ6ADQnU9Hmry/Y/9P6tn05GMYxn4BRBIWBseKD+GIH2i/Z87LR7u2WV7e33Y8biKvjEMX G09sbG+C8Xl7Jwc6DOndbNxhpa2plIc2f0rSDfMhv4i6tiZ23BTN842fDfKFgB5kcqssL6Oq qgqrtElrDaf/5LfR13uPWcutNJ2WRuik/ODrVFVZtbLWqiZ8vjZKS2uCkz9cTZiu24K1aj+7 K8eTqAujx7qPV+sa2LvNzzPQty5lFdO33E/RvLUkB+ZOyHsVbuGu7Yt4eGEEVmsN7m8vY1p+ LlUtDfzXxnyWLb0+qBXNP4J70pbO+vcGyqUdTeJH6ZV813iAB+9MAp3U9QaKGtqo2v0szqxb iZb274G2qiKqQhy4u24Xa/ZGsCQ1ghd2zSF9lpOnlz/FpCW34nlzJ5NSk2GIPqV857ohfukW 8mMqsZf0EDVpFmc2S/20sP+53cxKSRzUnxT3eFkRcxYGpqc+GgbaRTjsshTQ0NZA8W4n118T D/XPklfVRM3uZ2H9MqIHxMk+VG7Oht6L4Qnsx3Lz7SfYlltFkzWPLd0TcVc9gf4Hu8j/2Y00 Wa00dV/P1mJpA1sJzsGC9f09BHRMdDxzKGJ/XQs1r+4Dw42D29NsKyiZ2uglcMmfhPXnP/8Z +USs/p9u6spf46D9E8YlL2bl8hR0uKkrfZ4DTXDrmnWkTdbR1WTlxcLfEpOaztqlM6Gjhrda Elie5p8BQjd1RQUc7NCx/J7VJMf6qCs/zKTFi4jvde6Ouhq8M2YzWcYw32nKX6lFv3op3iNF 7Hv7OMlLTCyfPYaGqg+ZljaTsI46bCcTSKaJkwkLSEn09f12uoG9L5XhjLmZu03+PtqKHmQr j5G7agy56RtJfTmXlIETct9prMWHOOnxQMQYZs6bz8xE/5lEV0sVJQeO0MlElt29mpnx/jEk LF5EojYGH3WlxTA3nZR4FzWlr3KovpOJ85ezelFyv7s5faebKN7/FsfPRnLz8tUsSo7F3VHH y68dZ8HyqdhePEiEfiFJEeeYlJLMx8dhdkoiHXVWTibMI2Wcg9Lde/mjbipXJ3yLJfPieOv5 vfwx7mZSx3sg6RZGtbxHTGoaiVHQ1VTObwo/QD//O0xITmUa9Ty/9xBMXcjqVbODZwf+9v+B q1reI1rWDevAevAk85amBCcQpxvK2d8QQ9qkPzF6QJlTVaG66v9KxbaaUkoONcHEm7l7tdSJ u09f/XQ5jxkc01gseeAOTr7R39Z8p+vYnfcOkRPHck3K91iU3Hd2NlhHYfjljeW2mV38T9kH TF94C1d4wklNu5ajBa/C/LXc4Do8yH6H4iPPyos2PMKYLbkskksS8jy9o4FjTCNFgg583B3U HPPrTNp+TVEBh45Hsti0Vivn95d3SVyyhlWzxw/yhdMNVXwcl0qKrp3yN2twyJkU4PFcyZK1 c2l6vddGtYOQtGQFU88c5lDDSW3SpRW+MpkVt8Ft4Qd4VTzeq2N5B20xrx45w9yV60hL0iHv HC/YV4Mu+VoSpswl2dvAmUkLmBkfhnVDOh899DL3JQXG5qau/C0+8Xj4/HOPXx7TcnTtVeS9 cKR3PAGfl2UP0+cfXdRYP2HWoplE+epY1E8uTWLk3dBv1IZz21K/v8j9vXll9Eydy7pVaXTX WTXZ4j4+yMdxtzJbCxayrkyAeym293C76YcaY3dbDbteOMTYgP8N6nOAfN1NlB/1snjRTC2e vVT4rlZ33aJkOurKB/QHHXVVuKalkaSFh8F20V23g5iNJ8lbM5mEeStYOjOM3A1Po5s/nW5P EuvWpRE+KE76OQy0qf77XVQVlXDs8zEsXbuc8GNWDh93SOOQ/5F8+wpS4gP6Gro96ecBHcu4 s/+1d+jWfYfV69Jw1X15e/5WR9b/Aw/ikN/D8rmUS/DnvwZ8KXv5+tpqLswQkCHkJUvh7ex/ U9TXJ5bq+RtHwCvsFTb/zUnfBNldzcJW23cT3YWL7BIlmXqBKd9/A+aFV7ywkn+zXBfW/JCl vtI+B9uFszpLGLL6bhKU99Nkm893E9qQEquDfwWB4b4GPExnwMMyl/jKO/F1d+GKjvX/jfFX 3pvqQBH45hNwd3cTptP1W7n55o9qOEfgw+2DKHmto/fjc/sIi+rbDxxX3xdPYLjPgJUW/wqd helih+lviv8KoVRRRWAEE4jSDXET1wiWd+SJFsbAXKuS78jT0t8q0SVNwFdccQWPPvoop09r f0X/t8qk6ikCioAioAgoAsNOwOl08umnnw5bv5d0CVpKvXPnzosS/vXXX7+o+qqyIqAIKAKK gCJwIQTuuOOOQcXS09NJTOx/8+egQpfowCU9A5YyrV+//qJEU2fPF4VPVVYEFAFFQBG4QAIX m68usJvzFrvkZ8Dn7Un9oAgoAoqAIqAIKAJBAsPwII5gXxe2If92d08uO/bsoaC0ZtBTXrrq ithRFPLw/L/QasOebVg7/A/XGKqYu6WIJ/Y0DPWTOqYIKAKKgCKgCHylBEZcAm7a/WPevGY1 D9+Xxh8KQ56+04shdtKVnDgun0L05Z+Za/+JedpjDocuG5WUzkMrpw39ozqqCCgCioAioAh8 hQRG3BL06aptjFtwmLLmPBZPiKbr2Mv8a9GV/PzBMTyd6yArcxIb73mOUboPOTF9E8/e7mDD xjJmzBnFGb5NyugTlLXM4je/mkPe+hdYvDOLcwXP8B4wNvXHzP+shJKPnLi5hcURReR2303u AzHseWYfzp7PiLn1IW46tZtH9jqYM/4Eo9fsZNOi4bkg/xXqWTWtCCgCioAiMMIIjLgz4Pi0 TbRXp7P5ujEs2XGU2Bl6Th04zpjJ80h2deCWD8mb8Y88++IbLKvN4UR8Es7K6WRu/RUpH59k 6aZnyUyqp8GXzMKZcM7n4r19+TB5IbMnRXPmD8W8zw0sS5vEtKTRfNj5BQ07H+GDuQ/z8OP3 Urzg10R9axzMWMHW/8zkj7+9yHcXjzCFK3EUAUVAEVAERgaBEZeA64pKCZ99H/WinVmbH+JI 1zmcXEUUXnrkw+/lS3YS5FtGophx0xTtlUMxhquIJpzIsdO1FyiER41BvjQnPCoawqJZ9Zu9 jLVl8rP9HzLt7mzW8Br6f/tf/hQeBZHheN1OoiPkU8uvZZkJ/u7aG5mTIN/GEk70VRf0ZvKR oU0lhSKgCCgCisA3hsAl/zOkix55x3OseczBpjk9kPk4N159DYa4h9jwRBv1249xwz/PB+tu ChKP8ofI7/PTsx9zovIE9rZj1FsrSGiaQ9vRSrhlLZFHK3HOXsuxl8uY/P01zDgJH+5/gZPT DGRO8tBy/ASVDWOZ8swv+GDNFnLvvZqzxnuhMpen3p/PA40eqq2f0rZ+NpNHHqmLRq0aUAQU AUVAEfj6CIy4a8A+n48wfHR1e4mNDTzGzo3bFxXySDYf3V0+dPK1bT4fPpkc5c3OYaA9J1V7 bmqY9qo4Da3PHdKerNtNdGxs/+fT+rrp6g7vexXc16cT1bMioAgoAorAZUBgxCXgy4C5GqIi oAgoAoqAIsCIuwasdKIIKAKKgCKgCFwOBFQCvhy0rMaoCCgCioAiMOIIqAQ84lSiBFIEFAFF QBG4HAioBHw5aFmNURFQBBQBRWDEEVAJeMSpRAmkCCgCioAicDkQUAn4ctCyGqMioAgoAorA iCOgEvCIU4kSSBFQBBQBReByIKAS8OWgZTVGRUARUAQUgRFHQCXgEacSJZAioAgoAorA5UBA JeDLQctqjIqAIqAIKAIjjsD/A6//x+HeOVKPAAAAAElFTkSuQmCC --------------7433A0057E90344F37ECC9D6-- From nobody Tue Jul 19 09:33:40 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A5B12D08E for ; Tue, 19 Jul 2016 09:33:37 -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 cRWCxRNigAhI for ; Tue, 19 Jul 2016 09:33:33 -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 F256D12D762 for ; Tue, 19 Jul 2016 09:33:25 -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 u6JGXL0H008594; Tue, 19 Jul 2016 18:33:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8579520317E; Tue, 19 Jul 2016 18:33:21 +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 7347E202944; Tue, 19 Jul 2016 18:33:21 +0200 (CEST) Received: from [132.166.85.0] ([132.166.85.0]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6JGXJwe029448; Tue, 19 Jul 2016 18:33:20 +0200 To: dickroy@alum.mit.edu, its@ietf.org References: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> <327b204c-02eb-0a5a-0029-5d72e2aef69c@gmail.com> <86B0E9FF9C4E4D82B57AA3F3E9157801@SRA5> From: Alexandre Petrescu Message-ID: <294d575c-18bc-c658-f5ee-b207d113b1a7@gmail.com> Date: Tue, 19 Jul 2016 18:33:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <86B0E9FF9C4E4D82B57AA3F3E9157801@SRA5> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: hjfischer@fischer-tech.eu, knut.evensen@q-free.com Subject: Re: [its] CAM as UDP payload of IPv6 over 802.11p - MTU, MAC X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:33:37 -0000 Le 12/07/2016 à 08:27, Dick Roy a écrit : > A few points you might want to consider: > > 1) In Europe, currently, and I stress currently, CAM's and DENM's > are messages that some (C2C-CC in particular) are "adamant" be sent > using the ETSI TC ITS GeoNetworking protocol. So when you say > "sending CAMs", those of us involved in writing the standards and > building the products can only interpret that as meaning using the > "accepted protocols" in the various regions. There are so many > reasons NOT to use GeoNotworking, however, if you insist on doing so, > you need to revisit the numbers you quote below. The minimum header > is 80 bytes of mostly redundant information, and that does not > INCLUDE any useful information, like the portion of the rather > bloated CAM payload that actually does have useful information or > the certificates that will be mandatory! > > 2) To make matters needlessly more complicated, there is a standard > (and I believe some have actually tried to implement it:^)) that does > describe a means for "tunneling" GeoNotworking frames in IPv6 frames. > Talk about header bloat!!!!! And all this in a medium with a channel > configuration that is hopelessly and needlessly outdated and > ill-suited to the task (congestion reigns!). It's a really long sad > story ... > > 3) The 1500 byte limit is a MIB parameter that can be changed (and > should be for communications that do not involve ethernet, since only > in ethernet is there the magical 1500 byte MTU (a leftover from the > last century I might add). Also, as long as the MAX_PDUsize > parameter is less than 2309 bytes, there will be no fragmentation at > the MAC. Do y ou mean that the MTU size on 802.11 is 2309 bytes? In order to put that as such in an IPv6-over-802.11-OCB document there would need to be a reference; lacking that I will cite this :-) > The current thinking is that in 5.9GHz operation all packets should > be kept below that limit to avoid fragmentation. I happen to think > such blanket restrictions are not good ideas. There are scenarios in > which fragmentation is useful, acceptable, and easily doable. I do > not believe there are any restrictions in the latest version of > 802.11 that prohibit fragmentation at the MAC in 5.9GHz operations in > Europe or the US ... NPDUs/MSDUs of length > 2308 bytes can and will 2308 or 2309? > be fragmented at the MAC unless you have a non-compliant device. If MAC fragments and reassembles then IP does not need to, and as such we should write it down (in other cases it's IP who needs to fragment and MAC no). Also, I would like to add that there may be some cases like RSUs sending lists of POIs, or to some extent multiply signed messages, that may require > 1500 MTU. > 4) CAMs and DENMs are generally exchanged between MR's, not an MR and > an AR. I dont see why not. ETSI CAMs are very popular so I would expect even my watch to send one if it so wanted to advertise its position or a very precise time. The problem is that you dont have at IETF one unique message to advertise presence, position or time in a periodic manner. At IETF there are periodic broadcast messages like ICMP Router Advertisements, OSPF Link State Advertisements, SAP Session Advertisements; but none of these advertises position or time. There are messages giving the time in NTP but these are request-response nature, not advertisements like beacons. There are RFCs that describe how to encode geographical coordinates, but they dont say which protocol to use to advertise them. > AR's are located in RSUs, not OBUs by definition. CAMs and > DENMs are messages generally exchanged between OBUs. (There are god > reasons to also receive them at RSUs and share that information ... > welcome to the world of Cooperative ITS! ... but that's somewhat off > track for this discussion.) Referring to 1), the current thinking is > that BTP will be used above GN since that's the ONLY choice (though > you could say there is a UDP-like protocol ... just it doesn't have a > checksum which means it's the simplest possible transport layer > protocol that does NOTHING other than pass packets to the identified > higher layer entity:^)) > > 5) As for MAC addresses, generally (meaning almost always!) for CAMs > and DENMs, the dst addr is the broadcast address (all 1's). The tx > addr is the MAC address of the transmitter which will likely be drawn > from a local addr space and changed every "so often" to preserve > anonymity. The BSSID (addr 3 in the 802.11 data frame header) will > be all 1's if you care. As far as choosing some other MAC address as > mentioned below: > > " What is the dst MAC address used? The MAC address 33-33-0-0-0-0-1 > is expected, but also are ff-ff-ff-ff-ff-ff, and "01-00-5E-" and > "01-80-C2-". There is a need to decide which one of these to use, or > maybe request a new one." > > I think there is some confusion that needs to be cleared up, and > perhaps this paragraph achieves that goal. So I think there is choice to be made between all 1s and 33-33-0-0-0-0-1. > 6) Finally, as a general point to be remembered, IEEE 802.11 > operation in 5.9GHz OCB involves NO (layer 2) networking at all. The > phrase "IEEE 802.11 OCB network(s)" is an oxymoron, whether the > intent is to imply layer 2 OR (especially) layer 3 networking! When > it is used in documents, I have no idea what it means. IMO, the > phrase should be replaced with something more meaningful wherever it > occurs. I will make it into a question, because we need a good title for this document. Alex > > Hopefully, this is useful. > > Cheers, > > RR > > > > -----Original Message----- From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Sent: Monday, July 11, 2016 > 5:22 AM To: its@ietf.org Subject: Re: [its] CAM as UDP payload of > IPv6 over 802.11p (was: A New I-D on "Survey on IP-based Vehicular > Networking for Intelligent Transportation Systems") > > Hello José, > > Thank you for the message. There are many aspects you said that need > to be considered. Let me reply to just one now. > > Le 08/07/2016 à 10:55, José Santa Lozano a écrit : [...] >> 4- In all of our papers we transmit IPv6 packets over IEEE >> 802.11p, but we have also tested the possibility of also sending >> ETSI *CAM/DENM* messages over this platform by using UDP. This >> approach could be interesting for the IETF ITS group. I am not >> completely sure about the place to add this contribution, but in >> this case I doubt about the need to create a new section, given >> that I am not sure if there are many other works in this line. >> >> José Santa, Fernando Pereñiguez-García, Antonio Moragón, Antonio >> F. Skarmeta. Experimental Evaluation of CAM and DENM Messaging >> Services in Vehicular Communications. Transportation Research Part >> C: Emerging Technologies, vol. 2014, pp. 98-120, doi: >> http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014. >> >> In this work we provide an implementation of the ETSI messaging >> algorithm over our IPv6-o-11p basis. >> >> Please, let me know if you need further text, depending on the >> interest you find in my previous suggestions. > > The freely-avaliable paper is very important. It is probably the > best example mentioning CAM being transported as payload of IPv6 over > 802.11p. Literally it says: >> CAM and DENM messages are exchanged between MR [MobileRouter] and >> AR [AccessRouter] using UDP datagrams that are destined to the >> well-known IPv6 multicast address referring to all the nodes >> present on the local network segment (ff02::1). The use of this >> transport is based on the fact that there is no sense in using a >> connection-oriented transport since vehicles enter sporadically in >> an AR communication range. > > It is a highly desirable behaviour exposing application-layer > working together with a network layer over a link layer. > > Do you happen to have a packet dump available for this operation? > (ideally in monitor mode). See more packet dumps in 802.11-OCB > context at > http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files > > What is the maximum size of a UDP packet thus sent? (other reports > mention a max for CAM message of 102 bytes; others 300 bytes; they > all fit within 802.11-OCB definition of max MTU 1500 bytes, but I > want to make sure; also do you know at what size will 802.11OCB start > to fragment - this can be seen in the wireshark monitor mode, 802.11 > Data header, Flags "More Fragments"?) > > What is the src MAC address used? Because there may be a privacy > worry of listeners along roads identifying which car uses which > Organizational Unique Identifier. > > What is the dst MAC address used? The MAC address 33-33-0-0-0-0-1 is > expected, but also are ff-ff-ff-ff-ff-ff, and "01-00-5E-" and > "01-80-C2-". There is a need to decide which one of these to use, or > maybe request a new one. > > This will help writing a single "IPv6-over-802.11-OCB" document which > is the first goal in this group. > > Alex > >> >> Regards, >> >> -- José Santa Lozano Dept. Ingeniería de la Información y las >> Comunicaciones Facultad de Informática Universidad de Murcia 30100 >> Murcia, Spain Telf: +34-868-888771 / +34-868-884455 Fax: >> +34-868-884151 Web: http://ants.inf.um.es/~josesanta >> >> >> >>> El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong >>> > >>> escribió: >>> >>> Hi all, I have posted a new its I-D: - Title Survey on IP-based >>> Vehicular Networking for Intelligent Transportation Systems >>> >>> - File >>> >>> > https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey-00 >>> >>> >>> >>> >>> > > - Abstract >>> This document surveys the IP-based vehicular networks, which are >>> considered a key component of Intelligent Transportation Systems >>> (ITS). The main topics of vehicular networking are vehicle-to- >>> vehicle (V2V), vehicle-to-infrastructure (V2I), and >>> infrastructure- to-vehicle (I2V) networking. Vehicular networks >>> deal with some critical aspects, such as IP address >>> autoconfiguration, routing, handover, and mobility management. >>> This document summarizes and analyzes the previous research >>> activities that use IPv4 or IPv6 for vehicular networking" >>> >>> In this draft, we show the survey on IP-based Vehicular >>> Networking for Intelligent Transportation Systems. This draft >>> will be a good foundation to figure out the state-of-the-art >>> schemes for IP-based vehicular networking, so we can use it for >>> "ITS General Problem Area" that is one of work items in our its >>> group: https://trac.tools.ietf.org/wg/its/trac/ >>> >>> It will be great for you to take a look at this I-D and give us >>> comments or suggestions. >>> >>> Thanks. >>> >>> Best Regards, Paul -- =========================== Mr. Jaehoon >>> (Paul) Jeong, Ph.D. Assistant Professor Department of Software >>> Sungkyunkwan University Office: +82-31-299-4957 Email: >>> jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: >>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > > > > From nobody Tue Jul 19 10:14:22 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B542312D0F8 for ; Tue, 19 Jul 2016 10:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 TZ07sIpDK-MV for ; Tue, 19 Jul 2016 10:14:19 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 C0B4212D091 for ; Tue, 19 Jul 2016 10:14:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 35A8F62191; Tue, 19 Jul 2016 13:14:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id f7O2RfHo7ciS; Tue, 19 Jul 2016 13:14:13 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [31.133.139.93]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id C4FB36218F; Tue, 19 Jul 2016 13:14:10 -0400 (EDT) To: Alexandre Petrescu , dickroy@alum.mit.edu, its@ietf.org References: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> <327b204c-02eb-0a5a-0029-5d72e2aef69c@gmail.com> <86B0E9FF9C4E4D82B57AA3F3E9157801@SRA5> <294d575c-18bc-c658-f5ee-b207d113b1a7@gmail.com> From: Robert Moskowitz Message-ID: <2980c477-9dbb-9490-1d90-0291df083a22@htt-consult.com> Date: Tue, 19 Jul 2016 19:14:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <294d575c-18bc-c658-f5ee-b207d113b1a7@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: hjfischer@fischer-tech.eu, knut.evensen@q-free.com Subject: Re: [its] CAM as UDP payload of IPv6 over 802.11p - MTU, MAC X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 17:14:22 -0000 On 07/19/2016 06:33 PM, Alexandre Petrescu wrote: > > > Le 12/07/2016 à 08:27, Dick Roy a écrit : >> 6) Finally, as a general point to be remembered, IEEE 802.11 >> operation in 5.9GHz OCB involves NO (layer 2) networking at all. The >> phrase "IEEE 802.11 OCB network(s)" is an oxymoron, whether the >> intent is to imply layer 2 OR (especially) layer 3 networking! When >> it is used in documents, I have no idea what it means. IMO, the >> phrase should be replaced with something more meaningful wherever it >> occurs. > > I will make it into a question, because we need a good title for this > document. A quick google search on definition of Network and the second definition is: 2. a group or system of interconnected people or things 802.11-ocb is a network. I can argue that it is even a OSI Layer 2 service, but don't have the energy after today's meetings. Trying to call it anything other than 'network' will just add confusion and I would really be interested to see one word that describes it better. From nobody Tue Jul 19 12:19:54 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 8573012D0D9 for ; Tue, 19 Jul 2016 12:19:53 -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 cuZmtDaWVr4f for ; Tue, 19 Jul 2016 12:19:52 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 0765A12B016 for ; Tue, 19 Jul 2016 12:19:52 -0700 (PDT) Received: by mail-pa0-x22b.google.com with SMTP id pp5so9729605pac.3 for ; Tue, 19 Jul 2016 12:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=ua4FYxaa/w5xLpbR0tb4ylqPyLjWOGFeoL/kiA4Zy3c=; b=QO7hHo3MWipGy3IdIJlvClyBeEVWGVOovN0F71/Z7YObf/FZSAwvlEeyaxz9J5dkT0 KcwnmDWNBY5vWtrSGUfzxAvdkKRZ8H+P1ds/qJEuZDp2EdvUoHVeDE9F6Lwp2NCZk0dN CfKl5JyVQI1M0sx2HmN99Mfw5PLO4U60Re+Dw9gwVA2I7WdmfT6BcWgknsBXFwqOJnWw iefKoBw/sTsI59b668TJ0yHiXmb/UpZJhfde966b0YqQwq8mDVu/fahh/AesGn3QC6OE FSq/KYHfcsSWSN8lN88mwaAqBUGSvb8HSffPSO9BNj9B6DFFs/855lrbndW2H43aIVur vpmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=ua4FYxaa/w5xLpbR0tb4ylqPyLjWOGFeoL/kiA4Zy3c=; b=T5o3DxUx5uDvbtptjSP5S9uNzBe1tKnYuV8iQ2/HBWKU7c+YKPDYM0qW6o8Dtz65i/ 76eCVMmulfJqtQZuF1XQD3Wp3FJM9NyJwoNzlS6bI3kKRDU2YNjg7ewJxHeKHHuaTOYc npw35iFdBweaAwTSR2D2qZB2JDXHWIdUaI1FQzNiBxjJujjEgRzeVMCbJn8T9WX7g9IG XAjbKU4VoQxx2BNQ1Lgj/jNX2Vwy8kiqPqU5M3JnbUJKn+u1ziRGUsDaCJ/FLiHFkdRI hhdb5S2+HcMxvBROhkdCkeWNCzXvge78ptJlPUB/14F/5wqf9CbjEWTIlaudg8oiMkKn jVtw== X-Gm-Message-State: ALyK8tKgEukRACcWuyHNtA1lzGSGUPHczOd3IfNYqcl5PToPuNuXZuAguL6aqS3u3yEEOA== X-Received: by 10.66.164.227 with SMTP id yt3mr68471234pab.117.1468955991607; Tue, 19 Jul 2016 12:19:51 -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 18sm6721986pfn.33.2016.07.19.12.19.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 12:19:51 -0700 (PDT) Message-ID: <1468955989.4470.45.camel@gmail.com> From: Rex Buddenberg To: Alexandre Petrescu , dickroy@alum.mit.edu, its@ietf.org Date: Tue, 19 Jul 2016 12:19:49 -0700 In-Reply-To: <294d575c-18bc-c658-f5ee-b207d113b1a7@gmail.com> References: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> <327b204c-02eb-0a5a-0029-5d72e2aef69c@gmail.com> <86B0E9FF9C4E4D82B57AA3F3E9157801@SRA5> <294d575c-18bc-c658-f5ee-b207d113b1a7@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: hjfischer@fischer-tech.eu, knut.evensen@q-free.com Subject: Re: [its] CAM as UDP payload of IPv6 over 802.11p - MTU, MAC X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 19:19:54 -0000 On Tue, 2016-07-19 at 18:33 +0200, Alexandre Petrescu wrote: > > > be fragmented at the MAC unless you have a non-compliant device. > > If MAC fragments and reassembles then IP does not need to, and as > such  > we should write it down (in other cases it's IP who needs to > fragment  > and MAC no). ?? IPv6 is not supposed to fragment like IPv4.  Rather, a probe is supposed to reveal the smallest MTU along a path; then datagrams are trimmed to size at origin If the internetwork is probed every time -- likely in presence of volatile routing -- I can see an awful lot of interactivity-eating thrashing going on.  Since low latency seems to be an important desideratum, something needs to be worked out. Does anyone have any on-the-ground experience? From nobody Tue Jul 19 16:13: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 647D512D106 for ; Tue, 19 Jul 2016 16:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCt-haxbKpeV for ; Tue, 19 Jul 2016 16:13:34 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 5F4D812B04D for ; Tue, 19 Jul 2016 16:13:34 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id j12so23338866ywb.2 for ; Tue, 19 Jul 2016 16:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=Ics/sHhvAx1tqpu0Wae+hJSceciZuYwpqV29DF6koto=; b=e1Qf3sYkvCU4XycMBwg97LaafCWdZUiOw/DPHsSIQCKo4ySBukYL07kBj1c73HgpdX y5vuAYLx1Bghzn3Vf7TJkD+gdqESYHb0rt36Nglz0qekLxIw0w40TlgDo8k0iD4f9kWu nqCT/7McIiINcd2zX7Q7njWBzJVgP66mD0zJpxXJbYNjvIwvWuC3xPQM+0ckWqo/lmHh zRwB6Dw2HupK0DUfaTPoqibgRoDJWrdvZH9GhKSDi38k/shlnlyb+RGM2BIDSS1XqQzu 6cqyFzDlpGdJJc7YOv1wIonYxpULZo+RRTroxADv9OUiz/VskUnnRFT4gcuVSV6yEcRu d7Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Ics/sHhvAx1tqpu0Wae+hJSceciZuYwpqV29DF6koto=; b=BDkuZ8MtAsgWTFVRyZJtRxsZHqJLnS2IV1m2gf5Bqrjlxylda10EjpNYE4RfUh+w9S wO/Ls2t1eUwHQX9s1faKwAturAhjLU2SJZzhmihEUSbJGwOc8S6u84pD3xaf089MZ1JA neHFOAT/8vsgWCzT/m+2hii0avEmjBwgr9Spo7q2w9lLGTyelU+UAhnuObB+9UobwhOB gI+8V2N5SpblVFIadyv/fjafQysnITmRj0lk3skPswASAlU4nVpssfNkh+Lcu32+G5ot XYjtEBkreYPPCjHxRQyavsK61HD22KlmmbkNLnE3vHsYKOWwvXeqc09xzuK8op9Gq98Y 4S4Q== X-Gm-Message-State: ALyK8tI9e2mTG1VZxxkp1a5ljRXY0LXQrnd/OwTC33g3AUTBlZZe+DXLXX82Lz8Bnpl5ObldDDrOcVr+vx7avA== X-Received: by 10.37.83.202 with SMTP id h193mr26477651ybb.124.1468970013485; Tue, 19 Jul 2016 16:13:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.231.134 with HTTP; Tue, 19 Jul 2016 16:13:04 -0700 (PDT) From: "Mr. Jaehoon Paul Jeong" Date: Wed, 20 Jul 2016 08:13:04 +0900 Message-ID: To: its@ietf.org Content-Type: multipart/alternative; boundary=001a113e65ecd6f28d0538053bf0 Archived-At: Cc: "Mr. Jaehoon Paul Jeong" , =?UTF-8?B?7KCV7KSA7Iud?= , Chris Shen , Jong-Hyouk Lee , =?UTF-8?B?7KGw7JiB7ZmU?= Subject: [its] A New I-D on "IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular Networks" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 23:13:36 -0000 --001a113e65ecd6f28d0538053bf0 Content-Type: text/plain; charset=UTF-8 Hi all, I have posted a new its I-D: - Title IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular Networks - File https://tools.ietf.org/html/draft-jeong-its-vehicular-neighbor-discovery-00 - Abstract This document specifies an extension of IPv6 Neighbor Discovery (ND) for rapid network prefix and service discovery in vehicular networks. It is assumed that a vehicle or a Road-Side Unit (RSU) have an external network interface and their internal network. This document defines new ND options to allows a vehicle to announce the network prefixes and services inside its internal network to another vehicle or RSU. In this draft, we show a possible approach for the prefix and service discovery for vehicular services, such as adaptive cruise control, blackbox camera sharing, emergency notification, and navigation. We can use it for "ITS General Problem Area" that is one of work items in our its group: https://trac.tools.ietf.org/wg/its/trac/ It will be great for you to take a look at this I-D and give us comments or suggestions. Thanks. Best Regards, Paul -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a113e65ecd6f28d0538053bf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
I have posted a new its I-D:
<= div>- Title
=C2=A0 =C2=A0IPv6 Neighbor Discovery for Prefix and S= ervice Discovery in Vehicular Networks

- File

- Abstract
=C2=A0 =C2=A0This document specifies an extension of IPv6 Neighbor = Discovery (ND)
=C2=A0 =C2=A0for rapid network prefix and service = discovery in vehicular networks.
=C2=A0 =C2=A0It is assumed that = a vehicle or a Road-Side Unit (RSU) have an
=C2=A0 =C2=A0external= network interface and their internal network.=C2=A0 This document
=C2=A0 =C2=A0defines new ND options to allows a vehicle to announce the n= etwork
=C2=A0 =C2=A0prefixes and services inside its internal net= work to another vehicle
=C2=A0 =C2=A0or RSU.

=
In this draft, we show a possible approach for the prefix and service = discovery
for vehicular services, such as adaptive cruise control= , blackbox camera sharing,=C2=A0
emergency notification, and navi= gation.

We can use it for "ITS General Proble= m Area" that is one of work items in our its group: https://trac.tools.ietf.org/wg/its/trac/=

It will be great for you to take a look at th= is I-D and give us comments or suggestions.

Thanks= .

Best Regards,
Paul
--=C2=A0<= br>
=
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr= . Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Softw= are
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com= ,=C2=A0pauljeong@skku.edu
Personal Homepage: http://i= otlab.skku.edu/people-jaehoon-jeong.php
--001a113e65ecd6f28d0538053bf0-- From nobody Tue Jul 19 16:17:55 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0529312D127 for ; Tue, 19 Jul 2016 16:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LN03AnIJA5iH for ; Tue, 19 Jul 2016 16:17:50 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB36012D95E for ; Tue, 19 Jul 2016 16:17:44 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id u134so29889854ywg.3 for ; Tue, 19 Jul 2016 16:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=z+ja1XE1Pu8MHXWa5/+wtPUsRudTV5IC6uU+fSuaCOY=; b=PwlES7KHIUhbohwDOC00M1q1VcGHCtxYfgNh7U7uddecci0CDWzt7AR4goYHFQOCCu TPLue34Vu/iBKtLmYrCcgX+gvSncOyhm/FIL8bS1Bw2nwZwiDOV4c3zoEDdRIbVI1W6n +lGyJDMBw8ecgUofbOIEp33piZ9wXM7xiTK62OBzeOlochJGSUbtsu1suwXrae9ZNn9S cv2gHsdARhBlZGq/ov7X/XiSpZupoNeo28rn34Vphnke8coMMNYKWO0uFJUPnxIa0wB4 2rPKr2ISLoylpvLqzFxZsudNNGZWTSOnHDj+MGnWQL1tTmnqkJ2gjnsmbglBRdnrTvIx jjcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=z+ja1XE1Pu8MHXWa5/+wtPUsRudTV5IC6uU+fSuaCOY=; b=EREQ00+fj6coXDEgWRs52u+K+++pIc3Zeky6NXcNXRnENZTUnhiLX40UMIXGHFOl1D 9O9owASKJy80bOr4VAdvo42Oybx0mBafj91eKinwIWsOHf1cmxj1GvOj4lYyatjhxUcV ccOAtwy9RxJR2hDzWGHFsGXzFzqldY2tQhP8PNW6v/tphjWKs1cGiBEXZ457EGnIkTNf Jxx0AAy4PAlJK0G/qjBO2GP1H7HDpHgoeuECBQq12h69n8QhFDRGRWhPuQgyTNrcyy+U GFxSpXp7Uk0Bo/fqM4l5ZDisz7KVEC2Iu43y70nU/qMeLtu77Mbx7an8NwyemuqG76B8 S6Cw== X-Gm-Message-State: ALyK8tI+CmEcVBRxQ89MXS5gp2CUew80kz1r3oWgItaLJFppPU6UGrAfDZODZ69nAOj6Ug+mlO59kALkJPKAPw== X-Received: by 10.37.196.5 with SMTP id u5mr19493437ybf.39.1468970263824; Tue, 19 Jul 2016 16:17:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.231.134 with HTTP; Tue, 19 Jul 2016 16:17:14 -0700 (PDT) From: "Mr. Jaehoon Paul Jeong" Date: Wed, 20 Jul 2016 08:17:14 +0900 Message-ID: To: its@ietf.org Content-Type: multipart/alternative; boundary=94eb2c053e46c2cf650538054a9c Archived-At: Cc: Tae Oh , "Mr. Jaehoon Paul Jeong" Subject: [its] Updated I-D on "Problem Statement for Vehicle-to-Infrastructure Networking" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 23:17:54 -0000 --94eb2c053e46c2cf650538054a9c Content-Type: text/plain; charset=UTF-8 Hi all, I have posted a revised its I-D: - Title Problem Statement for Vehicle-to-Infrastructure Networking - File https://tools.ietf.org/html/draft-jeong-its-v2i-problem-statement-02 - Abstract This document specifies the problem statement for IPv6-based vehicle- to-infrastructure networking. Dedicated Short-Range Communications (DSRC) is standardized as IEEE 802.11p for the wireless media access in vehicular networks. This document addresses the extension of IPv6 as the network layer protocol in vehicular networks and is focused on the networking issues in one-hop communication between a Road-Side Unit (RSU) and vehicle. The RSU is connected to the Internet and allows vehicles to have the Internet access if connected. The major issues of including IPv6 in vehicular networks are neighbor discovery protocol, stateless address autoconfiguration, and DNS configuration for the Internet connectivity over DSRC. Also, when a vehicle and an RSU have an internal network, respectively, the document discusses the issues of the internetworking between the vehicle's internal network and the RSU's internal network, such as prefix discovery, prefix exchange, and service discovery. In this draft, we reflected the comments from IETF95 ITS BoF meeting and included Service Discovery as a new section. We can use it for "ITS General Problem Area" that is one of work items in our its group: https://trac.tools.ietf.org/wg/its/trac/ It will be great for you to take a look at this I-D and give us comments or suggestions. Thanks. Best Regards, Paul -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --94eb2c053e46c2cf650538054a9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
I have posted a revised its I-D:
- Title
=C2=A0 =C2=A0Problem Statement for Vehicle-to-Inf= rastructure Networking

- File

- Abstract
=C2=A0 =C2=A0This docu= ment specifies the problem statement for IPv6-based vehicle-
=C2= =A0 =C2=A0to-infrastructure networking.=C2=A0 Dedicated Short-Range Communi= cations
=C2=A0 =C2=A0(DSRC) is standardized as IEEE 802.11p for t= he wireless media access
=C2=A0 =C2=A0in vehicular networks.=C2= =A0 This document addresses the extension of IPv6
=C2=A0 =C2=A0as= the network layer protocol in vehicular networks and is focused on
=C2=A0 =C2=A0the networking issues in one-hop communication between a Ro= ad-Side
=C2=A0 =C2=A0Unit (RSU) and vehicle.=C2=A0 The RSU is con= nected to the Internet and
=C2=A0 =C2=A0allows vehicles to have t= he Internet access if connected.=C2=A0 The major
=C2=A0 =C2=A0iss= ues of including IPv6 in vehicular networks are neighbor discovery
=C2=A0 =C2=A0protocol, stateless address autoconfiguration, and DNS confi= guration
=C2=A0 =C2=A0for the Internet connectivity over DSRC.=C2= =A0 Also, when a vehicle and an
=C2=A0 =C2=A0RSU have an internal= network, respectively, the document discusses
=C2=A0 =C2=A0the i= ssues of the internetworking between the vehicle's internal
= =C2=A0 =C2=A0network and the RSU's internal network, such as prefix dis= covery,
=C2=A0 =C2=A0prefix exchange, and service discovery.

In this draft, we reflected the comments from IETF95 I= TS BoF meeting and=C2=A0
included Service Discovery as a new sect= ion.

We can use it for "ITS General Problem A= rea" that is one of work items in our its group: https://trac.tools.ietf.org/wg/its/trac/


--94eb2c053e46c2cf650538054a9c-- From nobody Tue Jul 19 16:27: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 9F76512D995 for ; Tue, 19 Jul 2016 16:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V51mAL8jp1xR for ; Tue, 19 Jul 2016 16:27:13 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7631B12D98E for ; Tue, 19 Jul 2016 16:27:13 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id z8so8800177ywa.1 for ; Tue, 19 Jul 2016 16:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=3IUhRNh7U75YVG2ZLy8mJwwKXJr3RMoHuhAyQjaJ3wU=; b=lvqdjhsSEA90nppW2rzg9j45A2Kt5aXkBdyO+BrHLKsB7EOF5pu+zg2wY6AlwzguwE xgpmhxhQbDL4gpsPGFf0E9xrois40lhrimefT9T9SG202tSoJcKvtgbl9mW40iGAvHOI hrF9JOfpDznTs4DEMAXkbSF1kl6VQXhHQq8pHlo8wJ83PQtc2JlcBT5xNX1gpRL7oA4C 1rE9nGMhug+mrwKDW70ycEUrMcVe0u9c9wSsQibnkXNJdjm3o3arEHT7Kig9MiGCzNTi avX29q7wRR6gQ5427nDxsNgv98rhcau4WgOxqW4hRhiX7Z2U/EF3rHWzM44XhOEc2JZu j0pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=3IUhRNh7U75YVG2ZLy8mJwwKXJr3RMoHuhAyQjaJ3wU=; b=dIFICh7QSZ+mydH3FtAu/0Q/QehjY/t+2rT7IqfNT8xcA2oQ4z/rlJBVOvt7ChmcCG DGI1YFWbtVmkFDjLyaHFYYv69Bo0kmS0loeBoYjHyMJlonECvhwoczVkwEHs0fs8yB3K 2Mh+0mmcKyJIqxsKbZKP73s1QlLayZxGvRAnY6yjuoFUqtSrtX/tff3J2qE8YEZEXzFr nhMpZnVqDWqQ6hMz4dulgpZlF+us/WhYKnPvW1ErCmLE/pFpSJIfFAwtRc7a/mk4M6FC KS2QmHR8/DSxRwIak5nwpnJVbnyXf1Mt6IZjNUdAx/97ZSzIrgt7WHTtDDFIdG8lwWVG uxPA== X-Gm-Message-State: ALyK8tIYbsc8uHkIgPgo2E6dmnt/k4BjM7hV1JCaoG6ytGyPRw6cd6xHgubyJQoKVJjSdPMTFlNXD045i3spEw== X-Received: by 10.37.198.18 with SMTP id k18mr15003921ybf.27.1468970832545; Tue, 19 Jul 2016 16:27:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.231.134 with HTTP; Tue, 19 Jul 2016 16:26:43 -0700 (PDT) From: "Mr. Jaehoon Paul Jeong" Date: Wed, 20 Jul 2016 08:26:43 +0900 Message-ID: To: its@ietf.org Content-Type: multipart/alternative; boundary=001a114d9d70a8cd7c0538056c5b Archived-At: Cc: =?UTF-8?B?7J206re87YOc?= , Sejun Lee , "Mr. Jaehoon Paul Jeong" , JungSoo Park Subject: [its] Updated I-D on "DNS Name Autoconfiguration for Internet of Things Devices" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 23:27:15 -0000 --001a114d9d70a8cd7c0538056c5b Content-Type: text/plain; charset=UTF-8 Hi all, I have posted a revised its I-D: - Title DNS Name Autoconfiguration for Internet of Things Devices - File https://tools.ietf.org/html/draft-jeong-its-iot-dns-autoconf-01 - Abstract This document specifies an autoconfiguration scheme for the global (or local) DNS names of Internet of Things (IoT) devices, such as sensors, actuators, and in-vehicle units. By this scheme, the DNS name of an IoT device can be autoconfigured with the device's model information in wired and wireless target networks (e.g., vehicle, road network, home, office, shopping mall, and smart grid). This DNS name lets IoT users (e.g., drivers, passengers, home residents, and customers) in the Internet (or local network) easily identify each device for monitoring and remote-controlling it in the target network. In this draft, we propose DNS naming services for IoT devices including ITS devices. This draft seems to be input for DNS autoconfiguration, DNS name resolution, device discovery, and service discovery for vehicles, RSUs, in-vehicle devices, and vehicular applications. These DNS naming and service discovery are parts of the Problem Statement for V2I networking: https://tools.ietf.org/html/draft-jeong-its-v2i-problem-statement-02 It will be great for you to take a look at this I-D and give us comments or suggestions. Thanks. Best Regards, Paul -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a114d9d70a8cd7c0538056c5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
I have posted a revised its I-D:
- Title
=C2=A0 =C2= =A0DNS Name Autoconfiguration for Internet of Things Devices

=
- File

- Abstract
=C2=A0 =C2=A0This document specifies an autoconfiguration scheme for = the global
=C2=A0 =C2=A0(or local) DNS names of Internet of Thing= s (IoT) devices, such as
=C2=A0 =C2=A0sensors, actuators, and in-= vehicle units.=C2=A0 By this scheme, the DNS
=C2=A0 =C2=A0name of= an IoT device can be autoconfigured with the device's model
= =C2=A0 =C2=A0information in wired and wireless target networks (e.g., vehic= le,
=C2=A0 =C2=A0road network, home, office, shopping mall, and s= mart grid).=C2=A0 This DNS
=C2=A0 =C2=A0name lets IoT users (e.g.= , drivers, passengers, home residents, and
=C2=A0 =C2=A0customers= ) in the Internet (or local network) easily identify each
=C2=A0 = =C2=A0device for monitoring and remote-controlling it in the target
=C2=A0 =C2=A0network.

In this draft, we propose= DNS naming services for IoT devices including ITS devices.
This = draft seems to be input for DNS autoconfiguration, DNS name resolution,
device discovery, and service discovery for vehicles, RSUs, in-vehic= le devices, and vehicular applications.

These DNS = naming and service discovery are parts of the Problem Statement for V2I net= working:

It will be great for you to= take a look at this I-D and give us comments or suggestions.
Thanks.

Best Regards,
Paul
--=C2=A0
<= div dir=3D"ltr">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Pr= ofessor
Department of Software
Sungkyunkwan University
Office: +82= -31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
= Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
--001a114d9d70a8cd7c0538056c5b-- From nobody Tue Jul 19 22:20:48 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0286D12D73E for ; Tue, 19 Jul 2016 22:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.506 X-Spam-Level: X-Spam-Status: No, score=-4.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 HjtNv01UEFps for ; Tue, 19 Jul 2016 22:20:43 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 ECA5112D113 for ; Tue, 19 Jul 2016 22:20:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2356662129; Wed, 20 Jul 2016 01:20:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6ZmgniDaT6-3; Wed, 20 Jul 2016 01:20:16 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [31.133.139.93]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id EEBA462122; Wed, 20 Jul 2016 01:20:12 -0400 (EDT) To: dickroy@alum.mit.edu, 'Alexandre Petrescu' , its@ietf.org References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> <1f22077d-e464-c39f-ba3e-b3c10ab24bc3@htt-consult.com> <914a7f56-d99b-f8ca-3705-68f27c67884e@gmail.com> From: Robert Moskowitz Message-ID: <1661f2e1-2ee1-ea8d-2d35-80d5f60ec7b2@htt-consult.com> Date: Wed, 20 Jul 2016 07:20:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------29C6E43050E005BD1DBBCABF" Archived-At: Subject: Re: [its] protocol layers 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, 20 Jul 2016 05:20:47 -0000 This is a multi-part message in MIME format. --------------29C6E43050E005BD1DBBCABF Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dick, thanks for adding in. On 07/20/2016 05:05 AM, Dick Roy wrote: > > See below … highlighted in yellow! > > RR > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Monday, July 18, 2016 8:08 AM > To: Robert Moskowitz; its@ietf.org > Subject: Re: [its] protocol layers > > Le 18/07/2016 à 13:05, Robert Moskowitz a écrit : > > > > > > > > > On 07/18/2016 12:58 PM, Alexandre Petrescu wrote: > > >> > > >> > > >> Le 18/07/2016 à 12:44, Robert Moskowitz a écrit : > > >>> > > >>> > > >>> On 07/18/2016 12:28 PM, Russ Housley wrote: > > >>>> Bob: > > >>>> > > >>>> I do not understand the text that you want changed. The > > >>>> current charter text is here: > > >>>> https://trac.tools.ietf.org/wg/its/trac/. Can you propose > > >>>> alternate text? > > >>> > > >>> From https://trac.tools.ietf.org/wg/its/trac/ > > >>> > > >>> > > >>> "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." > > >>> > > >>> Replace with: > > >>> > > >>> "In the future, some vehicle communications will 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 gets the charter out of even mentioning that there is > > >>> non-IP safety messages. > > >>> > > >>> > > >>> I should also point out that for the text: > > >>> > > >>> "However, IPv6 on 802.11-OCB is not yet defined." > > >>> > > >>> 1609.3 DOES define IPv6 for WAVE over 802.11p. > > >> > > >> IETF does not yet define IPv6-over-80211-OCB (aka 802.11p). > > >> > > >> IETF has defined many other "IPv6-over-foo". > > >> > > >> Whereas 1609.3 may tell IPv6 were possible over 802.11p it also > > >> required an intermediate layer, whereas an IETF IPv6-over-80211-OCB > > >> would define direct operation over MAC. > > > > > > I suspect that arguing 'over MAC' and 'over LLC' is a rathole. > > Not a rathole: LLC is part of any MAC deserving that name. > > */[RR>] LLC resides in the LLC sublayer and is a sublayer ABOVE the > MAC (sublayer) and together they comprise the Data Link Layer (DLL). > While 802.2 is disappearing, the LLC sublayer will not. It is simply > evolving into solely EPD (see 802 O&A) which involves only appending > an ethertype with no additional services./* > This is the ratehole I meant. 802 people know and work with the distinction. Over in the IETF you tend to get conversations that do not bother with the distinction. In fact disbelief in some quaters that anyone, going forward, would even bother to NOT run only IP for everything. Do not mean to include all IETFers, but I have encountered this over the years. > > Look at what 802.15 is doing with 802.15.12 (I *think* it is .12, > > > anyway) to address that it lost its LLC for 802.15.4 with the > > > sundowning of 802.2. > > */[RR>] The LLC sublayer is NOT lost … see below for more on 802.2, > 802.3, etc../* > WIth the sundowning of 802.2, .15.4 reved their standard to pull all references to 802.2 and did not put anything in to replace it. Now there is 15.12 to add an LLC function where its cost (in bytes over the air) is of value. Again the rathole discussion. > *//* > > Huh, didnt know that. I know 802.11 does have an LLC, yet we dont even > > have a specification called "IPv6 over 802.11". > > */[RR>] No, 802.11 does NOT have an LLC. It stops at the MAC (MAC SAP > to be more precise). 802.11, being an 802 protocol family member, > originally specified 802.2 as the LLC sublayer protocol to be used > (and they are the last protocol on the planet that does so). Howecver > that has lead to 6 useless bytes in EVERY 802.11 frame. 802.11 (in > 5.9GHz operations) currently specifies EPD, NOT LPD! The rest of > 802.11 is slowly transitioning to EPD as well (see previous comment)./* > > To come back to my initial statement "1609.3 may tell IPv6 were possible > > over 802.11p and required an intermediate layer". That intermediate > > layer is "DSRC Upper-MAC IEEE 1609.4" as pictured in the attachment. > > */[RR>] For the purposes of these discussion, 1609.3 simply states > that IPv6 can be used as specified in the IETF RFCs describing IPv6! > Nothing more, nothing less. Any 5.9GHz radio that receives a properly > formed IPv6 (NPDU) packet, simply needs an off-the-shelf IPv6 stack to > process the packet. That said, 1609.3 does provide for a “router > advertisement” that streamlines the process of forming a valid IPv6 > packet, however, that too is beyond the scope of these discussions./* > Yes, look at 1609.3, not 1609.4 for ipv6 support process. Ethertype usage is clearly called out as the LLC feature. > Private comment told me that 1609.4 layer may be just "control > > messaging", not "header". But how can one know? How can one find out > > whether that layer is "control messaging" and not "header". > > */[RR>] 1609.4 deals only with multi-channel operations at 5.9GHz in > the US, and can be completely ignored for all these discussions. It is > not a laye, but specifies functionality that synchronizes and allows > channel switching in single-channel devices. /* > > To come back to the documents currently written as IPv6-over-802.11-OCB. > > An IPv6-over-802.11-OCB document will have to specify something in the > > Frame Format section. Currently the thought is the following: > > - should it be 802.11 QoS Data (as in some US prototypes), or 802.11 > > Data (as in some EU prototypes)? We dont know for now. > > -it should carry the IPv6 ethertype > > */[RR>] If it’s an IPv6 packet, it should carry the appropriate > ethertype. Nothing prevents ARPs, RARPs, NDPs, etc. from being sent > over the 802.11 MAC & PHY at 5.9GHz. As for whether to use QoS or > non-QoS data types, that should be left to the ITS station management > in conjunction with the particular application requirements! IETF RFCs > should say NOTHING about this!. > /* > But in for what it is worth category, 1609.3 did not bother to mention that there are other ethertypes that might be of value to an IPv6 implementation. ;) > Alex > > > > > >> > > >>>> More below... > > >>>> > > >>>> Russ > > >>>> > > >>>> > > >>>> On Jul 18, 2016, at 6:12 AM, Robert Moskowitz > > >>>> <rgm-ietf@htt-consult.com> > > >>>> wrote: > > >>>> > > >>>>> I am new to this list. I worked, a bit, on both IEEE > > >>>>> 802.11p an 1609. I am currently working on a contract for > > >>>>> General Motors on automotive Ethernet security (a little > > >>>>> orthogonal to this work, perhaps. M0re 802.1 issues). > > >>>>> > > >>>>> > > >>>>> In the draft you state: > > >>>>> > > >>>>> "In the future, some vehicle communications may not use IP > > >>>>> for exchanging safety messages with other vehicles and > > >>>>> infrastructure." > > >>>>> > > >>>>> IEEE 1609.3 does define IPv6 configuration, but does not > > >>>>> mandate it. > > >>>>> > > >>>> > > >>>> Right. You are confirming that the “may not” is correct. > > >>> > > >>> So I turned the text around to drop mentioning of non-IP > > >>> messages. > > >>> > > >>>> > > >>>>> > > >>>>> "5.3 Internet Protocol version 6 > > >>>>> > > >>>>> Support for IPv6 is conditionally mandatory as specified in > > >>>>> 5.1. An IPv6 implementation shall comply with IETF RFC 2460. > > >>>>> Related features defined in other RFCs are specified in 6.5. > > >>>>> IP traffic is sent and received through the LLC sublayer as > > >>>>> specified in 5.2." > > >>>>> > > >>>>> You have to have it, but don't have to use it. There will > > >>>>> well be non-IP safety messages. > > >>>>> > > >>>>> I feel you need to fix this text in the charter. > > >>>>> > > >>>> Yes, there will be non-IP safety messages, and the are not > > >>>> part of our scope. > > >>>> > > >>> > > >>> think my change fixes the scope. > > >> > > >> I read. > > >> > > >> 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 > > > > > > > --------------29C6E43050E005BD1DBBCABF Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Dick, thanks for adding in.


On 07/20/2016 05:05 AM, Dick Roy wrote:

See below … highlighted in yellow!

 

RR

-----Original Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
Sent: Monday, July 18, 2016 8:08 AM
To: Robert Moskowitz; its@ietf.org
Subject: Re: [its] protocol layers

 

 

 

Le 18/07/2016 à 13:05, Robert Moskowitz a écrit :

> 

> 

> On 07/18/2016 12:58 PM, Alexandre Petrescu wrote:

>> 

>> 

>> Le 18/07/2016 à 12:44, Robert Moskowitz a écrit :

>>> 

>>> 

>>> On 07/18/2016 12:28 PM, Russ Housley wrote:

>>>> Bob:

>>>> 

>>>> I do not understand the text that you want changed.  The

>>>> current charter text is here:

>>>> https://trac.tools.ietf.org/wg/its/trac/.  Can you propose

>>>> alternate text?

>>> 

>>> From https://trac.tools.ietf.org/wg/its/trac/

>>> 

>>> 

>>> "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."

>>> 

>>> Replace with:

>>> 

>>> "In the future, some vehicle communications will 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 gets the charter out of even mentioning that there is

>>> non-IP safety messages.

>>> 

>>> 

>>> I should also point out that for the text:

>>> 

>>> "However, IPv6 on 802.11-OCB is not yet defined."

>>> 

>>> 1609.3 DOES define IPv6 for WAVE over 802.11p.

>> 

>> IETF does not yet define IPv6-over-80211-OCB (aka 802.11p).

>> 

>> IETF has defined many other "IPv6-over-foo".

>> 

>> Whereas 1609.3 may tell IPv6 were possible over 802.11p it also

>> required an intermediate layer, whereas an IETF IPv6-over-80211-OCB

>> would define direct operation over MAC.

> 

> I suspect that arguing 'over MAC' and 'over LLC' is a rathole.

 

Not a rathole: LLC is part of any MAC deserving that name.

[RR>] LLC resides in the LLC sublayer and is a sublayer ABOVE the MAC (sublayer) and together they comprise the Data Link Layer (DLL). While 802.2 is disappearing, the LLC sublayer will not.  It is simply evolving into solely EPD (see 802 O&A) which involves only appending an ethertype with no additional services.


This is the ratehole I meant.  802 people know and work with the distinction.  Over in the IETF you tend to get conversations that do not bother with the distinction.  In fact disbelief in some quaters that anyone, going forward, would even bother to NOT run only IP for everything.

Do not mean to include all IETFers, but I have encountered this over the years.

 

> Look at what 802.15 is doing with 802.15.12 (I *think* it is .12,

> anyway) to address that it lost its LLC for 802.15.4 with the

> sundowning of 802.2.

 

[RR>] The LLC sublayer is NOT lost … see below for more on 802.2, 802.3, etc..



WIth the sundowning of 802.2, .15.4 reved their standard to pull all references to 802.2 and did not put anything in to replace it.  Now there is 15.12 to add an LLC function where its cost (in bytes over the air) is of value.  Again the rathole discussion.

 

Huh, didnt know that.  I know 802.11 does have an LLC, yet we dont even

have a specification called "IPv6 over 802.11".

[RR>] No, 802.11 does NOT have an LLC.  It stops at the MAC (MAC SAP to be more precise).  802.11, being an 802 protocol family member, originally specified 802.2 as the LLC sublayer protocol to be used (and they are the last protocol on the planet that does so).  Howecver that has lead to 6 useless bytes in EVERY 802.11 frame.  802.11 (in 5.9GHz operations) currently specifies EPD, NOT LPD!  The rest of 802.11 is slowly transitioning to EPD as well (see previous comment).

 

To come back to my initial statement "1609.3 may tell IPv6 were possible

over 802.11p and required an intermediate layer".  That intermediate

layer is "DSRC Upper-MAC IEEE 1609.4" as pictured in the attachment.

[RR>] For the purposes of these discussion, 1609.3 simply states that IPv6 can be used as specified in the IETF RFCs describing IPv6!  Nothing more, nothing less. Any 5.9GHz radio that receives a properly formed IPv6 (NPDU) packet, simply needs an off-the-shelf IPv6 stack to process the packet. That said, 1609.3 does provide for a “router advertisement” that streamlines the process of forming a valid IPv6 packet, however, that too is beyond the scope of these discussions.


Yes, look at 1609.3, not 1609.4 for ipv6 support process.  Ethertype usage is clearly called out as the LLC feature.

 

Private comment told me that 1609.4 layer may be just "control

messaging", not "header".  But how can one know?  How can one find out

whether that layer is "control messaging" and not "header".

[RR>] 1609.4 deals only with multi-channel operations at 5.9GHz in the US, and can be completely ignored for all these discussions. It is not a laye, but specifies functionality that synchronizes and allows channel switching in single-channel devices.   

 

To come back to the documents currently written as IPv6-over-802.11-OCB.

 

An IPv6-over-802.11-OCB document will have to specify something in the

Frame Format section.  Currently the thought is the following:

- should it be 802.11 QoS Data (as in some US prototypes), or 802.11

   Data (as in some EU prototypes)?  We dont know for now.

-        it should carry the IPv6 ethertype

 

[RR>] If it’s an IPv6 packet, it should carry the appropriate ethertype.  Nothing prevents ARPs, RARPs, NDPs, etc. from being sent over the 802.11 MAC & PHY at 5.9GHz. As for whether to use QoS or non-QoS data types, that should be left to the ITS station management in conjunction with the particular application requirements! IETF RFCs should say NOTHING about this!.  


But in for what it is worth category, 1609.3 did not bother to mention that there are other ethertypes that might be of value to an IPv6 implementation.  ;)

 

 

Alex

 

> 

>> 

>>>> More below...

>>>> 

>>>> Russ

>>>> 

>>>> 

>>>> On Jul 18, 2016, at 6:12 AM, Robert Moskowitz

>>>> <<mailto:rgm-ietf@htt-consult.com>rgm-ietf@htt-consult.com>

>>>> wrote:

>>>> 

>>>>> I am new to this list.  I worked, a bit, on both IEEE

>>>>> 802.11p an 1609.  I am currently working on a contract for

>>>>> General Motors on automotive Ethernet security (a little

>>>>> orthogonal to this work, perhaps.  M0re 802.1 issues).

>>>>> 

>>>>> 

>>>>> In the draft you state:

>>>>> 

>>>>> "In the future, some vehicle communications may not use IP

>>>>> for exchanging safety messages with other vehicles and

>>>>> infrastructure."

>>>>> 

>>>>> IEEE 1609.3 does define IPv6 configuration, but does not

>>>>> mandate it.

>>>>> 

>>>> 

>>>> Right.  You are confirming that the “may not” is correct.

>>> 

>>> So I turned the text around to drop mentioning of non-IP

>>> messages.

>>> 

>>>> 

>>>>> 

>>>>> "5.3 Internet Protocol version 6

>>>>> 

>>>>> Support for IPv6 is conditionally mandatory as specified in

>>>>> 5.1. An IPv6 implementation shall comply with IETF RFC 2460.

>>>>> Related features defined in other RFCs are specified in 6.5.

>>>>> IP traffic is sent and received through the LLC sublayer as

>>>>> specified in 5.2."

>>>>> 

>>>>> You have to have it, but don't have to use it.  There will

>>>>> well be non-IP safety messages.

>>>>> 

>>>>> I feel you need to fix this text in the charter.

>>>>> 

>>>> Yes, there will be non-IP safety messages, and the are not

>>>> part of our scope.

>>>> 

>>> 

>>> think my change fixes the scope.

>> 

>> I read.

>> 

>> 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

> 

> 


--------------29C6E43050E005BD1DBBCABF-- From nobody Tue Jul 19 22:45: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 3295212DA80 for ; Tue, 19 Jul 2016 22:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 0FtQbZGiLCMt for ; Tue, 19 Jul 2016 22:45:40 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 3EA9E12DA66 for ; Tue, 19 Jul 2016 22:45:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id C94CC62132; Wed, 20 Jul 2016 01:45:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2FLibiVgRrzp; Wed, 20 Jul 2016 01:45:20 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [31.133.139.93]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 01AEF62131; Wed, 20 Jul 2016 01:45:16 -0400 (EDT) To: "Mr. Jaehoon Paul Jeong" , its@ietf.org References: From: Robert Moskowitz Message-ID: <30ac2066-530b-d1d9-14cf-786d8d737032@htt-consult.com> Date: Wed, 20 Jul 2016 07:45:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EBF0C8C150A32EF9359D00BA" Archived-At: Cc: Tae Oh Subject: Re: [its] Updated I-D on "Problem Statement for Vehicle-to-Infrastructure Networking" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 05:45:43 -0000 This is a multi-part message in MIME format. --------------EBF0C8C150A32EF9359D00BA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Although AutoSAR has added support for IPv6 (e.g. v4.2.2), many auto OEMs are still only planning on using IPv4 for the internal networks. In fact, for some, a given device will have the same MAC and IPv4 address in all vehicles. ARP, DHCP and related protocols will be locked down and not run, being considered a security risk. IPv6 will only be used in the DSRC and TCP components, and perhaps the Infotainment VM(s) with strong SELinux policies to prevent bleed-over to the control (e.g. safety) VLANs. Don't think that an internal breaking control ECU will have IPv6 connectivity through the DSRC. All messaging to the ECU will be app-leveled firewalled in the DSRC (and TCP). Even there, there is concern about compromised DSRC interacting inappropriately with ECUs. Thus, for example, the MAC bridging table in the CGM would allow traffic from the safety network(s) to the DSRC MAC, but not the other way. You may listen, but not directly control. Tell the CGM what emergency steps are needed. It will tell the OEMC which will tell the ECU (I think I have all the generic component acronyms right...). Or the CGM will generate the CAN message to the appropriate CAN device (OEMC could do this as well through the CGM to CAN). It is considered a serious security risk to have direct addressing from outside, whether DSRC, TCP, WiFi, or USB, to ECUs. On 07/20/2016 01:17 AM, Mr. Jaehoon Paul Jeong wrote: > Hi all, > I have posted a revised its I-D: > - Title > Problem Statement for Vehicle-to-Infrastructure Networking > > - File > https://tools.ietf.org/html/draft-jeong-its-v2i-problem-statement-02 > > - Abstract > This document specifies the problem statement for IPv6-based vehicle- > to-infrastructure networking. Dedicated Short-Range Communications > (DSRC) is standardized as IEEE 802.11p for the wireless media access > in vehicular networks. This document addresses the extension of IPv6 > as the network layer protocol in vehicular networks and is focused on > the networking issues in one-hop communication between a Road-Side > Unit (RSU) and vehicle. The RSU is connected to the Internet and > allows vehicles to have the Internet access if connected. The major > issues of including IPv6 in vehicular networks are neighbor discovery > protocol, stateless address autoconfiguration, and DNS configuration > for the Internet connectivity over DSRC. Also, when a vehicle and an > RSU have an internal network, respectively, the document discusses > the issues of the internetworking between the vehicle's internal > network and the RSU's internal network, such as prefix discovery, > prefix exchange, and service discovery. > > In this draft, we reflected the comments from IETF95 ITS BoF meeting and > included Service Discovery as a new section. > > We can use it for "ITS General Problem Area" that is one of work items > in our its group: https://trac.tools.ietf.org/wg/its/trac/ > > It will be great for you to take a look at this I-D and give us > comments or suggestions. > > Thanks. > > Best Regards, > Paul > -- > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com , > pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --------------EBF0C8C150A32EF9359D00BA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Although AutoSAR has added support for IPv6 (e.g. v4.2.2), many auto OEMs are still only planning on using IPv4 for the internal networks.  In fact, for some, a given device will have the same MAC and IPv4 address in all vehicles.  ARP, DHCP and related protocols will be locked down and not run, being considered a security risk.  IPv6 will only be used in the DSRC and TCP components, and perhaps the Infotainment VM(s) with strong SELinux policies to prevent bleed-over to the control (e.g. safety) VLANs.


Don't think that an internal breaking control ECU will have IPv6 connectivity through the DSRC.  All messaging to the ECU will be app-leveled firewalled in the DSRC (and TCP).  Even there, there is concern about compromised DSRC interacting inappropriately with ECUs.


Thus, for example, the MAC bridging table in the CGM would allow traffic from the safety network(s) to the DSRC MAC, but not the other way.  You may listen, but not directly control.  Tell the CGM what emergency steps are needed.  It will tell the OEMC which will tell the ECU (I think I have all the generic component acronyms right...).  Or the CGM will generate the CAN message to the appropriate CAN device (OEMC could do this as well through the CGM to CAN).


It is considered a serious security risk to have direct addressing from outside, whether DSRC, TCP, WiFi, or USB, to ECUs.


On 07/20/2016 01:17 AM, Mr. Jaehoon Paul Jeong wrote:
Hi all,
I have posted a revised its I-D:
- Title
   Problem Statement for Vehicle-to-Infrastructure Networking

- File

- Abstract
   This document specifies the problem statement for IPv6-based vehicle-
   to-infrastructure networking.  Dedicated Short-Range Communications
   (DSRC) is standardized as IEEE 802.11p for the wireless media access
   in vehicular networks.  This document addresses the extension of IPv6
   as the network layer protocol in vehicular networks and is focused on
   the networking issues in one-hop communication between a Road-Side
   Unit (RSU) and vehicle.  The RSU is connected to the Internet and
   allows vehicles to have the Internet access if connected.  The major
   issues of including IPv6 in vehicular networks are neighbor discovery
   protocol, stateless address autoconfiguration, and DNS configuration
   for the Internet connectivity over DSRC.  Also, when a vehicle and an
   RSU have an internal network, respectively, the document discusses
   the issues of the internetworking between the vehicle's internal
   network and the RSU's internal network, such as prefix discovery,
   prefix exchange, and service discovery.

In this draft, we reflected the comments from IETF95 ITS BoF meeting and 
included Service Discovery as a new section.

We can use it for "ITS General Problem Area" that is one of work items in our its group: https://trac.tools.ietf.org/wg/its/trac/

It will be great for you to take a look at this I-D and give us comments or suggestions.

Thanks.

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


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

--------------EBF0C8C150A32EF9359D00BA-- From nobody Wed Jul 20 10:57: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 CA33B12D991 for ; Wed, 20 Jul 2016 10:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 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, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yogoko.fr 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 NjJoPPgagJOa for ; Wed, 20 Jul 2016 10:57:04 -0700 (PDT) Received: from mx2.yogoko.fr (mx2.yogoko.fr [212.129.44.112]) by ietfa.amsl.com (Postfix) with ESMTP id 8165B12D979 for ; Wed, 20 Jul 2016 10:57:03 -0700 (PDT) Received: from mail.yogoko.fr (mail.yogoko.fr [95.130.15.246]) by mx2.yogoko.fr (Postfix) with ESMTP id 1146C60095; Wed, 20 Jul 2016 19:55:55 +0200 (CEST) Received: from mail.yogoko.fr (localhost [127.0.0.1]) by mail.yogoko.fr (Postfix) with ESMTP id 1BF85C67B5; Wed, 20 Jul 2016 19:56:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=yogoko.fr; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=dkim; bh=D3YNqrD22/CBi5LRDwRf1ZbZkq E2dBTVHYCjcDvBYMg=; b=IcK/h2M2h3kuzqfYpofTErTiAyzT4hVis0aS4wR7dK VGN6B/hlRJxJRRWhaefkfsecumJdUfuRH6rS6CGYKiFYsN3gma41AdbjcgLgxCfY 15e7eIsg3iAsOfN5Xn0wsbkanifai6KBCJ6/cxX/75nJ3jIRKprOXpKfVLb4/Zvc U= Received: from [IPv6:2a01:e35:2f7d:ee00:1a6:b8f5:4d46:5752] (unknown [IPv6:2a01:e35:2f7d:ee00:1a6:b8f5:4d46:5752]) (Authenticated sender: ernstty@yogoko.fr) by mail.yogoko.fr (Postfix) with ESMTPSA id 50F20C67B4; Wed, 20 Jul 2016 19:56:58 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0FC101A6-0EA3-409A-827F-C389FB11440F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Thierry Ernst - Bis In-Reply-To: Date: Wed, 20 Jul 2016 19:56:56 +0200 Message-Id: <5EEC6C7C-11B4-4C0A-9373-BAB3E3802F89@yogoko.fr> References: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> <45E6E584EBE2495EA455CD1487970A80@SRA5> To: its@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Inc.\) Roy Richard \(SRA" , "Mr. Jaehoon Paul Jeong" , =?utf-8?Q?Jos=C3=A9_Santa_Lozano?= Subject: Re: [its] A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems" 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, 20 Jul 2016 17:57:08 -0000 --Apple-Mail=_0FC101A6-0EA3-409A-827F-C389FB11440F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, I would just like to take the opportunity of this discussion to =C2=AB = advertise =C2=BB ISO 17429, a draft standard (for which I=E2=80=99m = serving as editor), currently under ballot and developed jointly within = ISO TC204 WG18 & CEN TC 278 WG16. ISO 17429 specifies a generic = mechanism allowing the transmission of any ITS-related message over any = type of access technology (11p and other WiFi variant, cellular, = satellite, infra-red, =E2=80=A6) using any type of networking protocol = (IPv6, or V2X-dedicated protocols as specified within IEEE or ETSI) for = any type of ITS exchange (point-to-point or broadcast, vehicle to other = vehicles, infrastructure, Internet, nomadic devices, etc) over any type = of underlying protocol stack (IPv6 or non-IP).=20 This standard paves the way for more interoperability between ITS silos = as currently deployed (eCall, V2X safety, connectivity, fleet = management, ..). Once adopted, this standard could be used in = compliancy with both US V2X non-IP standards (IEEE), European V2X non-IP = standards (ETSI) and general-purpose IETF TCP-IP based standards.=20 Many forthcoming ITS use cases will require the use of IPv6 and this is = why we (the ISO TC204 community which I=E2=80=99m serving as liaison to = toward the IETF) need the IETF to work on IPv6 related issues as the = ones being discussed on the IETF list so that IPv6 could be properly = used for vehicular communications.=20 Unfortunately I=E2=80=99m not able to be physically present in Berlin, = but Alexandru Petrescu - acting as IETF liaison toward ISO TC204 will = relay any input, discussion and material between both organizations. So, = if you have a message to pass, I=E2=80=99m sure Alexandru will be happy = to listen to any request you may have.=20 Regards, Thierry Ernst. YoGoKo & ISO TC204 liaison toward the IETF. > Le 12 juil. 2016 =C3=A0 19:06, Jos=C3=A9 Santa Lozano = a =C3=A9crit : >=20 > Dick, >=20 > Probably our system did not pass any interop test, but this was not = the purpose of the research. Our intention was to implement and test a = proof of concept, and we are not pursuing a final system to be put in = the market. I simply noticed that this work could be of interest for the = group. Having said that, if this imply that I should rephrase the usage = of =E2=80=9CETSI CAM/DENM=E2=80=9D, I do not have any problem. We used = packets that could not be totally compliant. >=20 > Regards, >=20 > --=20 > Jos=C3=A9 Santa Lozano > Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones > Facultad de Inform=C3=A1tica > Universidad de Murcia > 30100 Murcia, Spain > Telf: +34-868-888771 / +34-868-884455 > Fax: +34-868-884151 > Web: http://ants.inf.um.es/~josesanta = >=20 >=20 >=20 >> El 12 jul 2016, a las 9:14, Dick Roy > escribi=C3=B3: >>=20 >> Jose, >> =20 >> Perhaps you could explain in a bit more detail what you mean by = =E2=80=9Calso sending ETSI CAM/DENM messages over this platform by using = UDP=E2=80=9D. As per previous postings, this is a very involved = procedure if you intend it to be compliant to =E2=80=9Ccurrent = thinking=E2=80=9D, and I am pretty sure you are not thinking along those = lines. >> =20 >> RR >> =20 >> From: Jos=C3=A9 Santa Lozano [mailto:josesanta@um.es = ]=20 >> Sent: Friday, July 8, 2016 1:55 AM >> To: Mr. Jaehoon Paul Jeong >> Cc: its@ietf.org >> Subject: Re: [its] A New I-D on "Survey on IP-based Vehicular = Networking for Intelligent Transportation Systems" >> =20 >> Dear Paul, >>=20 >> Thanks for the work. Please consider the next comments and = suggestions of papers to add: >>=20 >> 1- I think it would be interesting to also include a section about = security. Even though you have added a small note at the end of the = document, I think that probably some works in the area could arise. =46rom= our side we propose the next paper to add: >>=20 >> Pedro J. Fern=C3=A1ndez, Jos=C3=A9 Santa, Fernando Bernal, Antonio F. = Skarmeta. Securing Vehicular IPv6 Communications. IEEE Transactions on = Dependable and Secure Computing, vol. 13, no. 1, pp. 46-58, 2016. >> =20 >> In this paper we evaluate the usage of IPSec in vehicular (to = infrastructure) communications. >> =20 >> 2- In the same line I think the document lacks in more evaluation = deployment works in the scientific literature. For sure, some of the = currently included papers include evaluations, but I think a concrete = section or an update with paper of this line would be beneficial to = people to understand the feasibility of IPv6 in vehicular = communications. =46rom our side we propose the next one: >> =20 >> Jos=C3=A9 Santa, Pedro J. Fern=C3=A1ndez, Fernando Pere=C3=B1iguez, = Antonio F. Skarmeta. Deployment of Vehicular Networks in Highways Using = 802.11p and IPv6 Technologies. International Journal of Ad Hoc and = Ubiquitous Computing, in press these days, 2016. >> =20 >> In this paper we present the work carried out in frames of the FOTsis = project to deploy real IPv6 vehicle-to-infrastructure networks around = Europe, together with the main evaluations performed. >> =20 >> 3- In the document there is a lack in mentioning the synergy between = currently standardized architecture at ISO/ETSI and the usage of IPv6. = However, IEEE WAVE has been cited multitude of times. Our next paper = could help to improve this needed part of the document, which could be = probably added in the mobility management section: >> =20 >> Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Fernando = Bernal, Pedro J. Fern=C3=A1ndez, Rafael Mar=C3=ADn-L=C3=B3pez, Antonio = F. Skarmeta. A Framework for Supporting Network Continuity in Vehicular = IPv6 Communications. IEEE Intelligent Transportation Systems Magazine, = vol. 6, no. 4, pp. 17-34, doi: 10.1109/MITS.2013.2274876, 2014. >> =20 >> In this work we present an architecture that complements the ETSI/ISO = communication architecture by using IPv6 (IETF) technologies. >> =20 >> 4- In all of our papers we transmit IPv6 packets over IEEE 802.11p, = but we have also tested the possibility of also sending ETSI CAM/DENM = messages over this platform by using UDP. This approach could be = interesting for the IETF ITS group. I am not completely sure about the = place to add this contribution, but in this case I doubt about the need = to create a new section, given that I am not sure if there are many = other works in this line. >> =20 >> Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Antonio = Morag=C3=B3n, Antonio F. Skarmeta. Experimental Evaluation of CAM and = DENM Messaging Services in Vehicular Communications. Transportation = Research Part C: Emerging Technologies, vol. 2014, pp. 98-120, doi: = http://dx.doi.org/10.1016/j.trc.2014.05.006 = , 2014. >> =20 >> In this work we provide an implementation of the ETSI messaging = algorithm over our IPv6-o-11p basis. >> =20 >> Please, let me know if you need further text, depending on the = interest you find in my previous suggestions. >> =20 >> Regards, >>=20 >> --=20 >> Jos=C3=A9 Santa Lozano >> Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones >> Facultad de Inform=C3=A1tica >> Universidad de Murcia >> 30100 Murcia, Spain >> Telf: +34-868-888771 / +34-868-884455 >> Fax: +34-868-884151 >> Web: http://ants.inf.um.es/~josesanta = >>=20 >>=20 >>=20 >> El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong = > escribi=C3=B3: >>=20 >> Hi all, >> I have posted a new its I-D: >> - Title >> Survey on IP-based Vehicular Networking for Intelligent = Transportation Systems=20 >>=20 >> - File >> = https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey-00= = >>=20 >> - Abstract >> This document surveys the IP-based vehicular networks, which are >> considered a key component of Intelligent Transportation Systems >> (ITS). The main topics of vehicular networking are vehicle-to- >> vehicle (V2V), vehicle-to-infrastructure (V2I), and = infrastructure- >> to-vehicle (I2V) networking. Vehicular networks deal with some >> critical aspects, such as IP address autoconfiguration, routing, >> handover, and mobility management. This document summarizes and >> analyzes the previous research activities that use IPv4 or IPv6 = for >> vehicular networking" >>=20 >> In this draft, we show the survey on IP-based Vehicular Networking=20 >> for Intelligent Transportation Systems.=20 >> This draft will be a good foundation to figure out the = state-of-the-art >> schemes for IP-based vehicular networking, so we can use it for >> "ITS General Problem Area" that is one of work items in our its = group: >> https://trac.tools.ietf.org/wg/its/trac/ = >>=20 >> It will be great for you to take a look at this I-D and give us = comments or suggestions. >>=20 >> Thanks. >>=20 >> Best Regards, >> Paul >> --=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 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_0FC101A6-0EA3-409A-827F-C389FB11440F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Dear all,

I would just like to = take the opportunity of this discussion to =C2=AB advertise =C2=BB= ISO 17429, a draft standard (for which I=E2=80=99m serving as editor), = currently under ballot and developed jointly within ISO TC204 WG18 & = CEN TC 278 WG16. ISO 17429 specifies a generic mechanism allowing the = transmission of any ITS-related message over any type of access = technology (11p and other WiFi variant, cellular, satellite, infra-red, = =E2=80=A6) using any type of networking protocol (IPv6, or V2X-dedicated = protocols as specified within IEEE or ETSI) for any type of ITS exchange = (point-to-point or broadcast, vehicle to other vehicles, infrastructure, = Internet, nomadic devices, etc) over any type of underlying protocol = stack (IPv6 or non-IP). 

This standard paves the way for more = interoperability between ITS silos as currently deployed (eCall, V2X = safety, connectivity, fleet management, ..).  Once adopted, this = standard could be used in compliancy with both US V2X non-IP standards = (IEEE), European V2X non-IP standards (ETSI) and general-purpose IETF = TCP-IP based standards. 

Many forthcoming ITS use cases will = require the use of IPv6 and this is why we (the ISO TC204 community = which I=E2=80=99m serving as liaison to toward the IETF) need the IETF = to work on IPv6 related issues as the ones being discussed on the IETF = list so that IPv6 could be properly used for vehicular = communications. 

Unfortunately I=E2=80=99m not able to be physically present = in Berlin, but Alexandru Petrescu - acting as IETF liaison toward ISO = TC204 will relay any input, discussion and material between both = organizations. So, if you have a message to pass, I=E2=80=99m sure = Alexandru will be happy to listen to any request you may = have. 

Regards,
Thierry Ernst.
YoGoKo & ISO TC204 liaison toward the IETF.


Le = 12 juil. 2016 =C3=A0 19:06, Jos=C3=A9 Santa Lozano <josesanta@um.es> a = =C3=A9crit :

Dick,

Probably our system did not pass any interop test, but this = was not the purpose of the research. Our intention was to implement and = test a proof of concept, and we are not pursuing a final system to be = put in the market. I simply noticed that this work could be of interest = for the group. Having said that, if this imply that I should rephrase = the usage of =E2=80=9CETSI CAM/DENM=E2=80=9D, I do not have any problem. = We used packets that could not be totally compliant.

Regards,

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



El 12 jul 2016, a las 9:14, Dick Roy <dickroy@alum.mit.edu> escribi=C3=B3:

Jose,
 
Perhaps you could explain in a bit more detail what = you mean by =E2=80=9Calso sending ETSI CAM/DENM messages over this platform = by using UDP=E2=80=9D. As per previous postings, this is a very = involved procedure if you intend it to be compliant to =E2=80=9Ccurrent = thinking=E2=80=9D, and I am pretty sure you are not thinking along those = lines.
 
RR
 
From: Jos=C3=A9 = Santa Lozano [mailto:josesanta@um.es] 
Sent: Friday, July 8, 2016 1:55 = AM
To: Mr. Jaehoon Paul Jeong
Cc: its@ietf.org
Subject: Re: [its] A New I-D on = "Survey on IP-based Vehicular Networking for Intelligent Transportation = Systems"
 
Dear Paul,

Thanks for the work. Please consider the next comments and = suggestions of papers to add:

1- I think it = would be interesting to also include a section about security. Even though = you have added a small note at the end of the document, I think that = probably some works in the area could arise. =46rom our side we = propose the next paper to add:

Pedro J. = Fern=C3=A1ndez, Jos=C3=A9 Santa, Fernando Bernal, Antonio F. = Skarmeta. Securing Vehicular IPv6 Communications. IEEE = Transactions on Dependable and Secure Computing, vol. 13, no. 1, pp. = 46-58, 2016.
 
In this paper we = evaluate the usage of IPSec in vehicular (to infrastructure) = communications.
 
2- In the same = line I think the document lacks in more evaluation = deployment works in the scientific = literature. For sure, some of the currently included papers include = evaluations, but I think a concrete section or an update with paper of = this line would be beneficial to people to understand the feasibility of = IPv6 in vehicular communications. =46rom our side we propose the next = one:
 
Jos=C3=A9 Santa, = Pedro J. Fern=C3=A1ndez, Fernando Pere=C3=B1iguez, Antonio F. = Skarmeta. Deployment of Vehicular Networks in Highways Using = 802.11p and IPv6 Technologies. International Journal of Ad Hoc and = Ubiquitous Computing, in press these days, 2016.
 
In this paper we = present the work carried out in frames of the FOTsis project to deploy = real IPv6 vehicle-to-infrastructure networks around Europe, together with the main evaluations = performed.
 
3- In the = document there is a lack in mentioning the synergy between currently = standardized architecture at ISO/ETSI and the usage of = IPv6. However, IEEE WAVE has been cited multitude of times. = Our next paper could help to improve this needed part of the document, = which could be probably added in the mobility management section:
 
Jos=C3=A9 Santa, = Fernando Pere=C3=B1iguez-Garc=C3=ADa, Fernando Bernal, Pedro J. = Fern=C3=A1ndez, Rafael Mar=C3=ADn-L=C3=B3pez, Antonio = F. Skarmeta. A Framework for Supporting Network Continuity in = Vehicular IPv6 Communications. IEEE Intelligent Transportation = Systems Magazine, vol. 6, no. 4, pp. 17-34, doi: = 10.1109/MITS.2013.2274876, 2014.
 
In this work we = present an architecture that complements the ETSI/ISO communication = architecture by using IPv6 (IETF) technologies.
 
4- In all of our = papers we transmit IPv6 packets over IEEE 802.11p, but we have also = tested the possibility of also sending ETSI CAM/DENM messages over this platform = by using UDP. This approach could be interesting for the IETF ITS group. = I am not completely sure about the place to add this contribution, but = in this case I doubt about the need to create a new section, given that = I am not sure if there are many other works in this line.
 
Jos=C3=A9 Santa, = Fernando Pere=C3=B1iguez-Garc=C3=ADa, Antonio Morag=C3=B3n, Antonio F. = Skarmeta. Experimental Evaluation of CAM and DENM Messaging Services in Vehicular = Communications. Transportation Research Part C: = Emerging Technologies, vol. 2014, pp. 98-120, doi: http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014.
 
In this work we = provide an implementation of the ETSI messaging algorithm over our = IPv6-o-11p basis.
 
Please, let me = know if you need further text, depending on the interest you find in my = previous suggestions.
 

Regards,

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



El 7 jul 2016, a las 19:33, Mr. = Jaehoon Paul Jeong <jaehoon.paul@gmail.com> escribi=C3=B3:
Hi all,
I have posted a new its I-D:
- Title
   Survey on IP-based = Vehicular Networking for Intelligent Transportation Systems 

- File
   https://tools.ietf.org/html/draft-jeong-its-vehicular-networkin= g-survey-00

- Abstract
   This document surveys the IP-based vehicular = networks, which are
   considered a key = component of Intelligent Transportation Systems
  =  (ITS).  The main topics of vehicular networking are = vehicle-to-
   vehicle (V2V), = vehicle-to-infrastructure (V2I), and infrastructure-
  =  to-vehicle (I2V) networking.  Vehicular networks deal with = some
   critical aspects, such as IP address = autoconfiguration, routing,
   handover, and = mobility management.  This document summarizes and
   analyzes the previous research activities that = use IPv4 or IPv6 for
   vehicular networking"

In this draft, we show the survey on IP-based = Vehicular Networking 
for Intelligent Transportation = Systems. 
This draft will be a good foundation to = figure out the state-of-the-art
schemes for IP-based = vehicular networking, so we can use it for
"ITS General = Problem Area" that is one of work items in our its group:
https://trac.tools.ietf.org/wg/its/trac/

It will be great for you to take a look at this I-D and give = us comments or suggestions.

Thanks.

Best Regards,
Paul
-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) = Jeong, Ph.D.
Assistant Professor
Department = of Software
Sungkyunkwan University
Office: = +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

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

= --Apple-Mail=_0FC101A6-0EA3-409A-827F-C389FB11440F-- From nobody Wed Jul 20 16:00:40 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DFA12D103 for ; Wed, 20 Jul 2016 16:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw_lge0L7LGl for ; Wed, 20 Jul 2016 16:00:35 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 3D99B12D500 for ; Wed, 20 Jul 2016 16:00:35 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id r9so59401259ywg.0 for ; Wed, 20 Jul 2016 16:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g+f/mgU6Rl8cyJY5qQH2TgECFSnirWSxNDfDUCVjSOE=; b=u3sjQExsRRhE0Rljhl+FJzJ6rVTnSei4Pwtqbn32eZPopsDWOeX8oAqBGH/VuqmVs1 Lhwo+Rm05/ewsWMR75LBEy8vXGr3k5jmP9ZjGT5UwJ1L6NzAqcq6q9TCu0CE5uG/uu18 V5pfYTBEixOUOViR86EKKXG1rSDuBPn0ky9Ct8KA9kQ2i8t5rP6gMsyqCFkGWQgIKcYQ oUz2TcINJT+JCiUO767f5iDiapxGQCT651FBtJ1sWhwNhttPwO5E2XQ5tWtY/P6KUoZr 7kMFAzH/U0DfG5RS9y/tYQCObLg5eVJpejd0Y3ZgTfICaineMjXlIT9e01+IGeefW7l9 NW4w== 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=g+f/mgU6Rl8cyJY5qQH2TgECFSnirWSxNDfDUCVjSOE=; b=MgKYkI9G4R85yQRWrllTMcMXkXPD1i52dxq7Oes7HxkiV+i5w6z5XQJL8x6r+1jvuk EEcnK72/H+EMnCQcoPbHO0A1y2VsXvEV8taVd2dZwF2TL8IQEwSRoAAHZ3vjL63DPKv1 drKDFTiLHZGmTJ0mU8LE8JBWU5I5+h/u12uhfk6DO3I73nyRN2NZ60aEcDN3hSX4OFFl /rWHvb52tLUAuZcvssQYRtnTz6EaLyJz9aGKx/q4bHx16/3Iomq2dhWbxwFXuFCW/y6j uX+UdJZzhitOeDfEQ8/W+9rYshk1KvxqSnafUBvpEC8x9TkdgjduQKSqfx7FZ7ijtstC tS/A== X-Gm-Message-State: ALyK8tJpAEsCOiZPw/QcQMTIUeKMUgaOUvS3fcJvRUq6trz/dvSmpsxqMawCTA/s7JYNHaGzdsAzA7kq9NhOng== X-Received: by 10.13.232.70 with SMTP id r67mr33534108ywe.184.1469055634183; Wed, 20 Jul 2016 16:00:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.231.134 with HTTP; Wed, 20 Jul 2016 16:00:04 -0700 (PDT) In-Reply-To: References: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> From: "Mr. Jaehoon Paul Jeong" Date: Thu, 21 Jul 2016 01:00:04 +0200 Message-ID: To: =?UTF-8?B?Qm9rb3IgTMOhc3psw7M=?= Content-Type: multipart/alternative; boundary=94eb2c087d0c3b1cd70538192bdd Archived-At: Cc: "its@ietf.org" , =?UTF-8?Q?Jos=C3=A9_Santa_Lozano?= Subject: Re: [its] A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems" 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, 20 Jul 2016 23:00:39 -0000 --94eb2c087d0c3b1cd70538192bdd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bokor, This looks an interesting paper. I will read this paper and discuss whether to include it with my coauthors. Thanks. Best Regards, Paul On Wed, Jul 13, 2016 at 5:49 PM, Bokor L=C3=A1szl=C3=B3 = wrote: > Dear Paul and All, > > besides Jose's suggestions I also would recommend an extension to section > 7. (Mobility Management in Vehicular Networks). Solutions to efficiently > support mobility in HetVNets seems to be important in the future, > integrated solutions are required. Here you can find the preliminary > results of our activities in this topic: > > N. Varga, L. Bokor and H. J. Fischer, "LDM-based dynamic network discover= y > and selection for IPv6 mobility management optimization in C-ITS > environments," Models and Technologies for Intelligent Transportation > Systems (MT-ITS), 2015 International Conference on, Budapest, 2015, pp. > 483-490. > doi: 10.1109/MTITS.2015.7223298 > URL: > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D7223298&isnum= ber=3D7223230 > > Best regards, > Laszlo > > -- > L=C3=A1szl=C3=B3 BOKOR, Ph.D. > Budapest University of Technology and Economics (BME) > Department of Networked Systems and Services (HIT) > Tel: +36-1-463-2048, Fax: +36-1-463-3263 > web: http://medianets.hu/staff/laszlo-bokor/ > > > > 2016-07-11 18:48 GMT+02:00 Mr. Jaehoon Paul Jeong > : > >> Hi Jose, >> Thanks for your good comments and suggestions. >> >> My answers are inline below: >> >> On Fri, Jul 8, 2016 at 5:55 PM, Jos=C3=A9 Santa Lozano >> wrote: >> >>> Dear Paul, >>> >>> Thanks for the work. Please consider the next comments and suggestions >>> of papers to add: >>> >>> 1- I think it would be interesting to also include a section about >>> *security*. Even though you have added a small note at the end of the >>> document, I think that probably some works in the area could arise. Fro= m >>> our side we propose the next paper to add: >>> >>> Pedro J. Fern=C3=A1ndez, Jos=C3=A9 Santa, Fernando Bernal, Antonio F. >>> Skarmeta. Securing Vehicular IPv6 Communications. IEEE Transactions on >>> Dependable and Secure Computing, vol. 13, no. 1, pp. 46-58, 2016. >>> >>> In this paper we evaluate the usage of IPSec in vehicular (to >>> infrastructure) communications. >>> >> >> =3D> We authors are planning to add more papers (including your paper) = for >> security and privacy to the next revision. >> >>> >>> 2- In the same line I think the document lacks in more *evaluation >>> deployment* works in the scientific literature. For sure, some of the >>> currently included papers include evaluations, but I think a concrete >>> section or an update with paper of this line would be beneficial to peo= ple >>> to understand the feasibility of IPv6 in vehicular communications. From= our >>> side we propose the next one: >>> >>> Jos=C3=A9 Santa, Pedro J. Fern=C3=A1ndez, Fernando Pere=C3=B1iguez, Ant= onio F. >>> Skarmeta. Deployment of Vehicular Networks in Highways Using 802.11p an= d >>> IPv6 Technologies. International Journal of Ad Hoc and Ubiquitous >>> Computing, in press these days, 2016. >>> >>> In this paper we present the work carried out in frames of the FOTsis >>> project to deploy real IPv6 vehicle-to-infrastructure networks around >>> Europe, together with the main evaluations performed. >>> >> >> =3D> Sure. I agree that the evaluation for deployment is important. >> After reviewing your paper, we will consider to include your above >> paper into the next revision. >> >>> >>> 3- In the document there is a lack in mentioning the synergy between >>> currently standardized architecture at *ISO/ETSI and the usage of IPv6*= . >>> However, IEEE WAVE has been cited multitude of times. Our next paper co= uld >>> help to improve this needed part of the document, which could be probab= ly >>> added in the mobility management section: >>> >>> Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Fernando Bernal,= Pedro J. >>> Fern=C3=A1ndez, Rafael Mar=C3=ADn-L=C3=B3pez, Antonio F. Skarmeta. A Fr= amework for >>> Supporting Network Continuity in Vehicular IPv6 Communications. >>> IEEE Intelligent Transportation Systems Magazine, vol. 6, no. 4, pp. 17= -34, >>> doi: 10.1109/MITS.2013.2274876, 2014. >>> >>> =3D> After reviewing your paper, we will also consider to include th= is >> paper in the next revision. >> >> >>> In this work we present an architecture that complements the ETSI/ISO >>> communication architecture by using IPv6 (IETF) technologies. >>> >> =3D> It seems like this work will be able to broaden the vehicular netw= ork >> architecture along with IEEE WAVE Standards. >> >>> >>> 4- In all of our papers we transmit IPv6 packets over IEEE 802.11p, but >>> we have also tested the possibility of also sending ETSI *CAM/DENM* >>> messages over this platform by using UDP. This approach could be >>> interesting for the IETF ITS group. I am not completely sure about the >>> place to add this contribution, but in this case I doubt about the need= to >>> create a new section, given that I am not sure if there are many other >>> works in this line. >>> >>> Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Antonio Morag=C3= =B3n, Antonio F. >>> Skarmeta. Experimental Evaluation of CAM and DENM Messaging Services in >>> Vehicular Communications. Transportation Research Part C: >>> Emerging Technologies, vol. 2014, pp. 98-120, doi: >>> http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014. >>> >>> In this work we provide an implementation of the ETSI messaging >>> algorithm over our IPv6-o-11p basis. >>> >>> =3D> After reviewing the above paper, we will consider to include this >> paper to the next revision. >> >> >>> Please, let me know if you need further text, depending on the interest >>> you find in my previous suggestions. >>> >> >> =3D> Through the review of all of your papers, I will ask you further >> text if needed. >> >> Thanks. >> >> Best Regards, >> Paul >> >> >>> Regards, >>> >>> -- >>> Jos=C3=A9 Santa Lozano >>> Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones >>> Facultad de Inform=C3=A1tica >>> Universidad de Murcia >>> 30100 Murcia, Spain >>> Telf: +34-868-888771 / +34-868-884455 >>> Fax: +34-868-884151 >>> Web: http://ants.inf.um.es/~josesanta >>> >>> >>> >>> El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong < >>> jaehoon.paul@gmail.com> escribi=C3=B3: >>> >>> Hi all, >>> I have posted a new its I-D: >>> - Title >>> Survey on IP-based Vehicular Networking for Intelligent >>> Transportation Systems >>> >>> - File >>> >>> https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey= -00 >>> >>> - Abstract >>> This document surveys the IP-based vehicular networks, which are >>> considered a key component of Intelligent Transportation Systems >>> (ITS). The main topics of vehicular networking are vehicle-to- >>> vehicle (V2V), vehicle-to-infrastructure (V2I), and infrastructure- >>> to-vehicle (I2V) networking. Vehicular networks deal with some >>> critical aspects, such as IP address autoconfiguration, routing, >>> handover, and mobility management. This document summarizes and >>> analyzes the previous research activities that use IPv4 or IPv6 for >>> vehicular networking" >>> >>> In this draft, we show the survey on IP-based Vehicular Networking >>> for Intelligent Transportation Systems. >>> This draft will be a good foundation to figure out the state-of-the-art >>> schemes for IP-based vehicular networking, so we can use it for >>> "ITS General Problem Area" that is one of work items in our its group: >>> https://trac.tools.ietf.org/wg/its/trac/ >>> >>> It will be great for you to take a look at this I-D and give us comment= s >>> or suggestions. >>> >>> Thanks. >>> >>> Best Regards, >>> Paul >>> -- >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>> Assistant Professor >>> Department of Software >>> Sungkyunkwan University >>> Office: +82-31-299-4957 >>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>> >>> >> >> >> -- >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Assistant Professor >> Department of Software >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> > --=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 --94eb2c087d0c3b1cd70538192bdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bokor,
This looks an interesting paper.
I= will read this paper and discuss whether to include it with my coauthors.<= /div>

Thanks.

Best Regards,
Paul


On Wed, Jul 13, 2016 at 5:49 PM, Bokor L=C3=A1szl=C3= =B3 <goodzi@gmail.com> wrote:
Dear Paul and All,

besides Jose'= s suggestions I also would recommend an extension to section 7. (Mobility M= anagement in Vehicular Networks). Solutions to efficiently support mobility= in HetVNets seems to be important in the future, integrated solutions are = required. Here you can find the preliminary results of our activities in th= is topic:

N. Varga, L. Bokor and H. J. Fische= r, "LDM-based dynamic network discovery and selection for IPv6 mobilit= y management optimization in C-ITS environments," Models and Technolog= ies for Intelligent Transportation Systems (MT-ITS), 2015 International Con= ference on, Budapest, 2015, pp. 483-490.
doi: 10.1109/MTITS.2015.= 7223298

Best regards,
Laszlo

--
L=C3=A1szl=C3=B3 BO= KOR, Ph.D.
Budapest University of Technology and Economics (BME)<= /div>
Department of Networked Systems and Services (HIT)



2016-07-11 18:48 GMT+02:00 Mr. Jaehoon Paul Jeong <j= aehoon.paul@gmail.com>:
Hi Jose,
Thanks for your good comments and suggestions.

My answers are inline below:

On Fri, Jul 8, 20= 16 at 5:55 PM, Jos=C3=A9 Santa Lozano <josesanta@um.es> wrote:=
Dear Paul,

= Thanks for the work. Please consider the next comments and suggestions of p= apers to add:

1- I think it would be interesting to also include a s= ection about security. Even though you have added a small note at th= e end of the document, I think that probably some=C2=A0works in the area co= uld arise. From our side we propose the next paper to add:

Pedro J. = Fern=C3=A1ndez, Jos=C3=A9 Santa, Fernando Bernal, Antonio F. Skarmeta.=C2= =A0Securing Vehicular IPv6=C2=A0Communications. IEEE Transactions on Depend= able and Secure Computing, vol. 13, no. 1, pp. 46-58, 2016.

<= div>In this paper we evaluate the usage of IPSec in vehicular (to infrastru= cture) communications.

= =C2=A0=3D> We authors are planning to add more papers (including your pa= per) for security and privacy to the next revision.

2- In the same= line I think the document lacks in more evaluation deployment works= in the scientific literature. For sure, some of the currently included pap= ers include evaluations, but I think a concrete section or an update with p= aper of this line would be beneficial to people to understand the feasibili= ty of IPv6 in vehicular communications. From our side we propose the next o= ne:

Jos=C3=A9 Santa, Pedro J. Fern=C3=A1ndez, Fern= ando Pere=C3=B1iguez, Antonio F. Skarmeta.=C2=A0Deployment of Vehicular Net= works in Highways Using 802.11p and IPv6 Technologies.=C2=A0International J= ournal of Ad Hoc and Ubiquitous Computing, in press these days, 2016.
=

In this paper we present the work carried out in frames= of the FOTsis project to deploy real IPv6 vehicle-to-infrastructure networ= ks around Europe, together with the main evaluations performed.
=

=C2=A0=3D> Sure. I agree that th= e evaluation for deployment is important.=C2=A0
=C2=A0 =C2=A0 =C2= =A0 After reviewing your paper, we will consider to include your above pape= r into the next revision.

3- In the document there is a lack in me= ntioning the synergy between currently standardized architecture at ISO/= ETSI and the usage of IPv6. However, IEEE WAVE has been cited multitude= of times. Our next paper could help to improve this needed part of the doc= ument, which could be probably added in the mobility management section:

Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=AD= a, Fernando Bernal, Pedro J. Fern=C3=A1ndez, Rafael Mar=C3=ADn-L=C3=B3pez, = Antonio F.=C2=A0Skarmeta.=C2=A0A Framework for Supporting Network Continuit= y in Vehicular IPv6 Communications. IEEE=C2=A0Intelligent Transportation Sy= stems Magazine, vol. 6, no. 4, pp. 17-34, doi: 10.1109/MITS.2013.2274876, 2= 014.

=C2=A0=3D>=C2=A0= =C2=A0 After reviewing your paper, we will also consider to include this pa= per in the next revision.
=C2=A0 =C2=A0=C2=A0
In this work w= e present an architecture that complements the ETSI/ISO communication archi= tecture by using IPv6 (IETF) technologies.
<= div>=C2=A0=3D> It seems like this work will be able to broaden the vehic= ular network architecture along with IEEE WAVE Standards.

4- In al= l of our papers we transmit IPv6 packets over IEEE 802.11p, but we have als= o tested the possibility of also sending ETSI CAM/DENM messages over= this platform by using UDP. This approach could be interesting for the IET= F ITS group. I am not completely sure about the place to add this contribut= ion, but in this case I doubt about the need to create a new section, given= that I am not sure if there are many other works in this line.
<= br>
Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Antoni= o Morag=C3=B3n, Antonio F. Skarmeta.=C2=A0Experimental Evaluation of CAM=C2= =A0and DENM Messaging Services in Vehicular Communications. Transportation = Research Part C: Emerging=C2=A0Technologies, vol. 2014, pp. 98-120, doi: htt= p://dx.doi.org/10.1016/j.trc.2014.05.006, 2014.

In this work we provide an implementation of the ETSI messaging algorithm= over our IPv6-o-11p basis.

<= div>=C2=A0=3D> After reviewing the above paper, we will consider to incl= ude this paper to the next revision.=C2=A0
=C2=A0=C2=A0
Plea= se, let me know if you need further text, depending on the interest you fin= d in my previous suggestions.

=C2=A0=3D> =C2=A0Through the review of all of your papers, I will = ask you further text if needed.

=C2=A0 =C2=A0 =C2= =A0 =C2=A0Thanks.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Best = Regards,=C2=A0
=C2=A0 =C2=A0 =C2=A0= =C2=A0Paul

=

Regards,

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



El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong = <jaehoon.pau= l@gmail.com> escribi=C3=B3:

Hi all,
I have posted a new it= s I-D:
- Title
=C2=A0 =C2=A0Survey on IP-based Vehicular Networking f= or Intelligent Transportation Systems=C2=A0

- File
=C2=A0 =C2=A0<= a href=3D"https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-= survey-00" target=3D"_blank">https://tools.ietf.org/html/draft-jeong-its-ve= hicular-networking-survey-00

- Abstract
=C2=A0 =C2=A0This doc= ument surveys the IP-based vehicular networks, which are
=C2=A0 =C2=A0co= nsidered a key component of Intelligent Transportation Systems
=C2=A0 = =C2=A0(ITS).=C2=A0 The main topics of vehicular networking are vehicle-to-<= br>=C2=A0 =C2=A0vehicle (V2V), vehicle-to-infrastructure (V2I), and infrast= ructure-
=C2=A0 =C2=A0to-vehicle (I2V) networking.=C2=A0 Vehicular netwo= rks deal with some
=C2=A0 =C2=A0critical aspects, such as IP address aut= oconfiguration, routing,
=C2=A0 =C2=A0handover, and mobility management.= =C2=A0 This document summarizes and
=C2=A0 =C2=A0analyzes the previous r= esearch activities that use IPv4 or IPv6 for
=C2=A0 =C2=A0vehicular netw= orking"

In this draft, we show the survey on IP-based Vehicular= Networking=C2=A0
for Intelligent Transportation Systems.=C2=A0
This = draft will be a good foundation to figure out the state-of-the-art
schem= es for IP-based vehicular networking, so we can use it for
"ITS Gen= eral Problem Area" that is one of work items in our its group:
https://= trac.tools.ietf.org/wg/its/trac/

It will be great for you to tak= e a look at this I-D and give us comments or suggestions.

Thanks.
Best Regards,
Paul
--=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeon= g, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan U= niversity
Office: +82-31-299-4957
Email:=C2=A0jaehoon.paul@gmail.com,=C2=A0<= a href=3D"mailto:pauljeong@skku.edu" target=3D"_blank">pauljeong@skku.edu
Personal Homepage:=C2=A0http://iotlab.skku.edu/people-jaehoon-jeon= g.php
____________________________________________= ___
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
=


<= br clear=3D"all">

--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DMr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of So= ftware
Sungkyunkwan University
Office: +82-31-299-4957
Email: = jaehoon.paul@gm= ail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: h= ttp://iotlab.skku.edu/people-jaehoon-jeong.php

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





--
=
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon= (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Su= ngkyunkwan 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
=
--94eb2c087d0c3b1cd70538192bdd-- From nobody Wed Jul 20 16:09:03 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A285512B00D for ; Wed, 20 Jul 2016 16:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhCvzjPV9zp0 for ; Wed, 20 Jul 2016 16:08:59 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3837812B030 for ; Wed, 20 Jul 2016 16:08:59 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id r9so59553113ywg.0 for ; Wed, 20 Jul 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=0Fpkf2apIIBksAPZQ9YxGe+BZ7/p5hnvknjy/ZhuSIg=; b=kY3VSzlGXAe74VOeIMuslQ1fxkw8k426dNQrqbukfXGdE3nOSh7V19GdLe0ETnC9Vp 1CqExayF+K/Xo8sEi+2nxJwzgbqdOjGc2rxHVT1lF11xdDtUj2eeso83Htk/D9y/mhhe TjDfyF4ncKKdv6p6RWq2otb6p7DIh2pF+YtG3SGNuSN36gBzZXKjNKFlpN9odPXG839L 9o47zLK4KDsXiIR6+lm1VtdkHYPDtGOvSv1KP+UcUE/4CqTlQByvMzDe5Kzqz6jXuuD7 gwNCudd/SNK0gJpCEpbvhS4cLZcVN3Loo5k56GyCqJtPMlT2Uhc7PXa7xamZia0e7H8F m0fA== 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=0Fpkf2apIIBksAPZQ9YxGe+BZ7/p5hnvknjy/ZhuSIg=; b=JUECLJI+LNRlwPBYB/bt3IqcJQvesbw/0FSNB+eMa8jtY04rXu8vHvfT1MbZbNTYu5 g3YSvpLrZmnbEzGvihTXq1JmAu45XN7QWyEWAfAVQvcsF3JTphYhqUzHmpVoUYp60eV9 Pcw0a6rP33xsOSOlBVnHHhctdQX9sVJ4IOKA5bn9gmob8CMKOUL/BCJ7245TdYfIqvKA rvoUlcbD8Xyt5b+/w7bK8K87WP15hzrM0SEcB0RGOJH/6YBsYDS7CLPi4SlNZKV6Fjxw IxJABOK2B1U++qeGoMW00SR1iKnVnFdl9C4CECYdgwU/g8imZzDfqhotME2duNa9St+p rFUQ== X-Gm-Message-State: ALyK8tLv5DBsrOBtoskuHWrtvmbDRR2AML8E6fPbaPamrWV2xFKQd9/hvOk9lwqyLuoSqGIhg5drBqjWEKMKNQ== X-Received: by 10.129.128.194 with SMTP id q185mr33323759ywf.150.1469056138508; Wed, 20 Jul 2016 16:08:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.231.134 with HTTP; Wed, 20 Jul 2016 16:08:29 -0700 (PDT) In-Reply-To: References: From: "Mr. Jaehoon Paul Jeong" Date: Thu, 21 Jul 2016 01:08:29 +0200 Message-ID: To: Richard Roy Content-Type: multipart/alternative; boundary=94eb2c0363e44a7e86053819491b Archived-At: Cc: =?UTF-8?B?7KCV7KSA7Iud?= , Chris Shen , Jong-Hyouk Lee , its@ietf.org, =?UTF-8?B?7KGw7JiB7ZmU?= Subject: Re: [its] A New I-D on "IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular Networks" 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, 20 Jul 2016 23:09:02 -0000 --94eb2c0363e44a7e86053819491b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dick, As you know, the option length is the multiple of 8 bytes. If we provide a list of prefixes and services, it seems to require padding for this length rule. It is not impossible, but it seems not a neat solution. I will figure it out to pack them into a list. Thanks for your suggestion. Best Regards, Paul On Wed, Jul 20, 2016 at 2:58 AM, Dick Roy wrote: > I=E2=80=99ve skimmed the draft and it looks interesting. My initial thou= ght is > that both the VPI and VSI should/could contain a list of prefixes/service= s > rather than just a single entry in each. Is there a problem doing this? > > > > RR > > > ------------------------------ > > *From:* Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] > *Sent:* Tuesday, July 19, 2016 4:13 PM > *To:* its@ietf.org > *Cc:* Mr. Jaehoon Paul Jeong; =EC=A0=95=EC=A4=80=EC=8B=9D; Chris Shen; Jo= ng-Hyouk Lee; =EC=A1=B0=EC=98=81=ED=99=94 > *Subject:* [its] A New I-D on "IPv6 Neighbor Discovery for Prefix and > Service Discovery in Vehicular Networks" > > > > Hi all, > > I have posted a new its I-D: > > - Title > > IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular > Networks > > > > - File > > > https://tools.ietf.org/html/draft-jeong-its-vehicular-neighbor-discovery-= 00 > > > > - Abstract > > This document specifies an extension of IPv6 Neighbor Discovery (ND) > > for rapid network prefix and service discovery in vehicular networks. > > It is assumed that a vehicle or a Road-Side Unit (RSU) have an > > external network interface and their internal network. This document > > defines new ND options to allows a vehicle to announce the network > > prefixes and services inside its internal network to another vehicle > > or RSU. > > > > In this draft, we show a possible approach for the prefix and service > discovery > > for vehicular services, such as adaptive cruise control, blackbox camera > sharing, > > emergency notification, and navigation. > > > > We can use it for "ITS General Problem Area" that is one of work items in > our its group: https://trac.tools.ietf.org/wg/its/trac/ > > > > It will be great for you to take a look at this I-D and give us comments > or suggestions. > > > > Thanks. > > > > Best Regards, > > Paul > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > --=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 --94eb2c0363e44a7e86053819491b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dick,
As you know, the option length is the multipl= e of 8 bytes.
If we provide a list of prefixes and services, it s= eems to require padding for this length rule.
It is not impossibl= e, but it seems not a neat solution.
I will figure it out to pack= them into a list.

Thanks for your suggestion.

Best Regards,
Paul



= On Wed, Jul 20, 2016 at 2:58 AM, Dick Roy <dickroy@alum.mit.edu>= wrote:

I=E2=80=99ve skimm= ed the draft and it looks interesting.=C2=A0 My initial thought is that both the VPI and VSI should/c= ould contain a list of prefixes/services rather than just a single entry in each.=C2=A0 Is there a problem doing this?

=C2=A0

RR

=C2=A0

From: Mr. Jaehoon Paul Jeong [mailto:j= aehoon.paul@gmail.com]
Sent: Tuesday, July 19, 2016= 4:13 PM
To: its@ietf.org
Cc: Mr. Jaehoon Paul Jeong; = =EC=A0=95=EC=A4=80=EC=8B= =9D; Chris Shen; Jong-Hyouk Lee; =EC= =A1=B0=EC=98=81=ED=99=94
Subject: [its] A New I-D on "IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular Networks"

=C2=A0

Hi all,

I have posted a new its I-D:

- Title

=C2=A0 =C2=A0IPv6 Neighbor Discovery for Prefix and = Service Discovery in Vehicular Networks

=C2=A0

- File

=C2=A0

- Abstract

=C2=A0 =C2=A0This document specifies an extension of= IPv6 Neighbor Discovery (ND)

=C2=A0 =C2=A0for rapid network prefix and service di= scovery in vehicular networks.

=C2=A0 =C2=A0It is assumed that a vehicle or a Road-= Side Unit (RSU) have an

=C2=A0 =C2=A0external network interface and their in= ternal network.=C2=A0 This document

=C2=A0 =C2=A0defines new ND options to allows a vehi= cle to announce the network

=C2=A0 =C2=A0prefixes and services inside its intern= al network to another vehicle

=C2=A0 =C2=A0or RSU.

=C2=A0

In this draft, we show a possible approach for the p= refix and service discovery

for vehicular services, such as adaptive cruise cont= rol, blackbox camera sharing,=C2=A0

emergency notification, and navigation.

=C2=A0

We can use it for "ITS General Problem Area&quo= t; that is one of work items in our its group: https://trac.tools.ietf.org/wg/its/trac/

=C2=A0

It will be great for you to take a look at this I-D = and give us comments or suggestions.

=C2=A0

Thanks.

=C2=A0

Best Regards,

Paul

--=C2=A0

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




--
=3D=3D=3D=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) Jeon= g, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan U= niversity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.s= kku.edu/people-jaehoon-jeong.php
--94eb2c0363e44a7e86053819491b-- From nobody Wed Jul 20 16:31: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 8C8A312D5C7 for ; Wed, 20 Jul 2016 16:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-J-wEMrAEMl for ; Wed, 20 Jul 2016 16:31:02 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB9B12D103 for ; Wed, 20 Jul 2016 16:31:01 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id j12so52615650ywb.2 for ; Wed, 20 Jul 2016 16:31:01 -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=VT9KVADOe0euwYsVvKUekvtSLg+Dw1jbEIU0G5YE7zo=; b=Eg1E99Y+dkioekHc7C7xdGdGvYAeKhlHl0citUi0jwQSOK9RPNqXYKEP5gtYA8m7BH iUj0HcS5uQlE97lYTLJenYkA3Q/dUBoj/6ndd0HS1Wf1rlJU49W2XKbbdMcFELefJyAt 9qxMuX/OtAD86eTmZ1J+6Be7DsgUtIqxaWoJFUCBoA4FwWE67kMRy4zrTTu+hJUuEAqm iRTOZNZQEOs8SznGwgiWlAx2CuOT7DOgCiKHuM9I6iqk6mYvBiFz/9NXSsjezqglcVKJ t/gYoOkqcRgE05WIFE1E1AtFuSMwVKlpdilc9GzmvlM0P4TR2nIrIj+nhpZpAOD9jLL6 6Nyw== 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=VT9KVADOe0euwYsVvKUekvtSLg+Dw1jbEIU0G5YE7zo=; b=U0X1QtlZZy9Q0GwQ5VpO6QAr8siRxGF+/peTZHNo91DTq3KjTdUi0iZ9CVUVshP1Dn iScYwA3B/0N/N8erQJ/1taYxpKFLtEnTWPslVraCqndfsYJbIZuhmwbUxElU7dVhArHa U23mMyHdQoslk8JA+YALc9GVWwZG4w5H2OPTLdDqyW54JgTJkWU8IUHxxOMjmBvq/mZu nVcWoHx20JkVLq0SbJiZelebLCvELAIrp/YrWIGEjNaX8bb6cCWvWLSAwvKI8njUQWGP IW9fnAjNZTVhNiJntxfd19BoL63xx7TAm9pP4SQcpP3O9U+clXHPiTBnxYiMODvoAt6d Z0gg== X-Gm-Message-State: ALyK8tImwc1nvuXMS5Xu9KKmQetZVSzJsEyEHtOhOqsQCoKiCxv9tJJ5BKePW/mE19zOzljvBpXWFJZS3y47Kw== X-Received: by 10.37.196.5 with SMTP id u5mr23437691ybf.39.1469057461025; Wed, 20 Jul 2016 16:31:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.231.134 with HTTP; Wed, 20 Jul 2016 16:30:31 -0700 (PDT) In-Reply-To: References: From: "Mr. Jaehoon Paul Jeong" Date: Thu, 21 Jul 2016 01:30:31 +0200 Message-ID: To: Richard Roy Content-Type: multipart/alternative; boundary=94eb2c053e461e7fcd05381998d3 Archived-At: Cc: =?UTF-8?B?7J206re87YOc?= , Sejun Lee , its@ietf.org, JungSoo Park Subject: Re: [its] Updated I-D on "DNS Name Autoconfiguration for Internet of Things Devices" 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, 20 Jul 2016 23:31:04 -0000 --94eb2c053e461e7fcd05381998d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dick, RFC 4944 (Transmission of IPv6 Packets over IEEE 802.15.4 Networks) discusses how to handle the MTU size (i.e., 1280 bytes) for IPv6 packets over IEEE 802.15.4. We can support a long DNS name by using the techniques (such as adaptation layer and header compression) that are specified in RFC 4944. For the low capacity networks, we may think a compact DNS name format. However, in vehicular networks, since we consider Ethernet for the internal network of a vehicle or RSU, and also IEEE 802.11p for the external network between vehicles or between a vehicle and an RSU, the long DNS name format will be fine. Thanks. Best Regards, Paul On Wed, Jul 20, 2016 at 3:12 AM, Dick Roy wrote: > It strikes me that these IoT names will get quite long, perhaps much > longer than the max MTU size of an 802.15 PPDU. The transmission of the > name in every PDU would seem to be excessive overhead that somehow should > be avoided. Are such issues being considered? > > > > RR > > > ------------------------------ > > *From:* Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] > *Sent:* Tuesday, July 19, 2016 4:27 PM > *To:* its@ietf.org > *Cc:* =EC=9D=B4=EA=B7=BC=ED=83=9C; Sejun Lee; Mr. Jaehoon Paul Jeong; Jun= gSoo Park > *Subject:* [its] Updated I-D on "DNS Name Autoconfiguration for Internet > of Things Devices" > > > > Hi all, > > I have posted a revised its I-D: > > - Title > > DNS Name Autoconfiguration for Internet of Things Devices > > > > - File > > https://tools.ietf.org/html/draft-jeong-its-iot-dns-autoconf-01 > > > > - Abstract > > This document specifies an autoconfiguration scheme for the global > > (or local) DNS names of Internet of Things (IoT) devices, such as > > sensors, actuators, and in-vehicle units. By this scheme, the DNS > > name of an IoT device can be autoconfigured with the device's model > > information in wired and wireless target networks (e.g., vehicle, > > road network, home, office, shopping mall, and smart grid). This DNS > > name lets IoT users (e.g., drivers, passengers, home residents, and > > customers) in the Internet (or local network) easily identify each > > device for monitoring and remote-controlling it in the target > > network. > > > > In this draft, we propose DNS naming services for IoT devices including > ITS devices. > > This draft seems to be input for DNS autoconfiguration, DNS name > resolution, > > device discovery, and service discovery for vehicles, RSUs, in-vehicle > devices, and vehicular applications. > > > > These DNS naming and service discovery are parts of the Problem Statement > for V2I networking: > > https://tools.ietf.org/html/draft-jeong-its-v2i-problem-statement-02 > > > > It will be great for you to take a look at this I-D and give us comments > or suggestions. > > > > Thanks. > > > > Best Regards, > > Paul > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > --=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 --94eb2c053e461e7fcd05381998d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dick,
RFC 4944 (Transmission of IPv6 Packets o= ver IEEE 802.15.4 Networks)=C2=A0
discusses how to handle the MTU= size (i.e., 1280 bytes) for IPv6 packets over IEEE 802.15.4.
We = can support a long DNS name by using the techniques (such as adaptation lay= er and
header compression) that are specified in RFC 4944.
<= div>
For the low capacity networks, we may think a compact DN= S name format.

However, in vehicular networks, sin= ce we consider Ethernet for the internal network of a vehicle or RSU,
=
and also IEEE 802.11p for the external network between vehicles or bet= ween a vehicle and an RSU,
the long DNS name format will be fine.=

Thanks.

Best Regards,
Paul





On= Wed, Jul 20, 2016 at 3:12 AM, Dick Roy <dickroy@alum.mit.edu> wrote:

It strikes me that= these IoT names will get quite long, perhaps much longer than the max MTU size of an 802.15 PPDU= .=C2=A0 The transmission of the name in every PDU would seem to be excessive overhe= ad that somehow should be avoided.=C2=A0 Are such issues being considered?<= /u>

=C2=A0

RR <= /span>

=C2=A0

From: Mr. Jaehoon Paul Jeong [mailto:j= aehoon.paul@gmail.com]
Sent: Tuesday, July 19, 2016= 4:27 PM
To: its@ietf.org
Cc: =EC=9D=B4=EA=B7=BC=ED=83=9C; Sejun Lee; Mr. Jaehoon Paul Jeong; JungSoo Park
Subject: [its] Updated I-D o= n "DNS Name Autoconfiguration for Internet of Things Devices"

=C2=A0

Hi all,

I have posted a revised its I-D:

- Title

=C2=A0 =C2=A0DNS Name Autoconfiguration for Internet= of Things Devices

=C2=A0

- File

=C2=A0

- Abstract

=C2=A0 =C2=A0This document specifies an autoconfigur= ation scheme for the global

=C2=A0 =C2=A0(or local) DNS names of Internet of Thi= ngs (IoT) devices, such as

=C2=A0 =C2=A0sensors, actuators, and in-vehicle unit= s.=C2=A0 By this scheme, the DNS

=C2=A0 =C2=A0name of an IoT device can be autoconfig= ured with the device's model

=C2=A0 =C2=A0information in wired and wireless targe= t networks (e.g., vehicle,

=C2=A0 =C2=A0road network, home, office, shopping ma= ll, and smart grid).=C2=A0 This DNS

=C2=A0 =C2=A0name lets IoT users (e.g., drivers, pas= sengers, home residents, and

=C2=A0 =C2=A0customers) in the Internet (or local ne= twork) easily identify each

=C2=A0 =C2=A0device for monitoring and remote-contro= lling it in the target

=C2=A0 =C2=A0network.

=C2=A0

In this draft, we propose DNS naming services for Io= T devices including ITS devices.

This draft seems to be input for DNS autoconfigurati= on, DNS name resolution,

device discovery, and service discovery for vehicles= , RSUs, in-vehicle devices, and vehicular applications.

=C2=A0

These DNS naming and service discovery are parts of = the Problem Statement for V2I networking:

=C2=A0

It will be great for you to take a look at this I-D = and give us comments or suggestions.

=C2=A0

Thanks.

=C2=A0

Best Regards,

Paul

--=C2=A0

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




--
=3D=3D=3D=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) Jeon= g, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan U= niversity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.s= kku.edu/people-jaehoon-jeong.php
--94eb2c053e461e7fcd05381998d3-- From nobody Thu Jul 21 04:29:55 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA81712DEF7 for ; Thu, 21 Jul 2016 04:29:53 -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 KpJDLXGmwoYT for ; Thu, 21 Jul 2016 04:29:51 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0063112D51B for ; Thu, 21 Jul 2016 04:26:39 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id x72so29641896pfd.2 for ; Thu, 21 Jul 2016 04:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iaDic3UFKhsDSwLo64iS5MfHue3x+gYxhXQZyIUvffA=; b=qpZXx83G4uIHFBkov+CM+ZLyGaX2WJuzsv1yfs27GB2U1ggPaMya1ZP+YgTQ7FsdoC dg49d302wgpIZDB6iBqwzwYkYJjJNHMbBLo860wGjWzrJW9irLAEfPE+TNLgIqWhXTCj RErENJ3xpG0Lz/XkUluQ1/6KNS1dhOBk7HBNZr9dn/HNV4VccDq9oZPvnUqeoYDOfwTz 0UWzBl4zuB4FBNfNcrQaHVdMZR1rCTytC0lzT6nuLTWtObKuqIDwQd+T3TbqX9TEVgop qO5aCtqHph0otyqidrWiJfx4T09wI5Qars4zcE5kGgHSfuSl5RIBhj6LqBDUisAmZkWJ z0GQ== 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=iaDic3UFKhsDSwLo64iS5MfHue3x+gYxhXQZyIUvffA=; b=UfU5G4fjulr4TmLV8OwK0XLPvu/7yEPDI0S7lq/YScoCjYQDQDCuIgCem1nDtjmbWA xbTK1+v7lV2DIJpjNdEQ+UBVKTjxGsWCXbMLjMT+vZkWlfU+XjcXA3riDzPJzq3Gc99E 8W2ikF/09zMNOTeLi66EqNNTPcZ0xyKIJMSv7mIT+lbL0mTrgOu+k0p2l41uc1An9L1b xzhB+X9pdjbvVFwKM81rLfcddxTLyBt/L/ENCz/GkrHkpniEeSlyhQEIrC9m/t9Uj5Fi ewSElamFpgTIBloYwulIDUoq64IBciFQC2BQYNAB5zJ9msgIRzrRpEi0OgYVEI2ZQMNf oPPQ== X-Gm-Message-State: ALyK8tI9J1YK8INk6iuZkDBvr4Sy2yMrLQ8CwU8Xy0yR4Cr8LRwtu/eZgD1SYigXLrKbXaR0tiNCRMj/CmIXJw== X-Received: by 10.98.83.1 with SMTP id h1mr72124472pfb.78.1469100399542; Thu, 21 Jul 2016 04:26:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.251.37 with HTTP; Thu, 21 Jul 2016 04:26:38 -0700 (PDT) In-Reply-To: References: <39862AA7-31E6-447E-B247-453E73427B4D@um.es> From: =?UTF-8?B?Qm9rb3IgTMOhc3psw7M=?= Date: Thu, 21 Jul 2016 13:26:38 +0200 Message-ID: To: "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary=94eb2c0c80567448d905382397f4 Archived-At: Cc: "its@ietf.org" , =?UTF-8?Q?Jos=C3=A9_Santa_Lozano?= Subject: Re: [its] A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 11:29:54 -0000 --94eb2c0c80567448d905382397f4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Paul, thank you. If you have any questions or comments, please don't hesitate to mail me. Best regards, Laszlo -- L=C3=A1szl=C3=B3 BOKOR, Ph.D. Budapest University of Technology and Economics (BME) Department of Networked Systems and Services (HIT) Tel: +36-1-463-2048, Fax: +36-1-463-3263 web: http://medianets.hu/staff/laszlo-bokor/ 2016-07-21 1:00 GMT+02:00 Mr. Jaehoon Paul Jeong : > Hi Bokor, > This looks an interesting paper. > I will read this paper and discuss whether to include it with my coauthor= s. > > Thanks. > > Best Regards, > Paul > > > On Wed, Jul 13, 2016 at 5:49 PM, Bokor L=C3=A1szl=C3=B3 wrote: > >> Dear Paul and All, >> >> besides Jose's suggestions I also would recommend an extension to sectio= n >> 7. (Mobility Management in Vehicular Networks). Solutions to efficiently >> support mobility in HetVNets seems to be important in the future, >> integrated solutions are required. Here you can find the preliminary >> results of our activities in this topic: >> >> N. Varga, L. Bokor and H. J. Fischer, "LDM-based dynamic network >> discovery and selection for IPv6 mobility management optimization in C-I= TS >> environments," Models and Technologies for Intelligent Transportation >> Systems (MT-ITS), 2015 International Conference on, Budapest, 2015, pp. >> 483-490. >> doi: 10.1109/MTITS.2015.7223298 >> URL: >> http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D7223298&isnu= mber=3D7223230 >> >> Best regards, >> Laszlo >> >> -- >> L=C3=A1szl=C3=B3 BOKOR, Ph.D. >> Budapest University of Technology and Economics (BME) >> Department of Networked Systems and Services (HIT) >> Tel: +36-1-463-2048, Fax: +36-1-463-3263 >> web: http://medianets.hu/staff/laszlo-bokor/ >> >> >> >> 2016-07-11 18:48 GMT+02:00 Mr. Jaehoon Paul Jeong > >: >> >>> Hi Jose, >>> Thanks for your good comments and suggestions. >>> >>> My answers are inline below: >>> >>> On Fri, Jul 8, 2016 at 5:55 PM, Jos=C3=A9 Santa Lozano >>> wrote: >>> >>>> Dear Paul, >>>> >>>> Thanks for the work. Please consider the next comments and suggestions >>>> of papers to add: >>>> >>>> 1- I think it would be interesting to also include a section about >>>> *security*. Even though you have added a small note at the end of the >>>> document, I think that probably some works in the area could arise. Fr= om >>>> our side we propose the next paper to add: >>>> >>>> Pedro J. Fern=C3=A1ndez, Jos=C3=A9 Santa, Fernando Bernal, Antonio F. >>>> Skarmeta. Securing Vehicular IPv6 Communications. IEEE Transactions on >>>> Dependable and Secure Computing, vol. 13, no. 1, pp. 46-58, 2016. >>>> >>>> In this paper we evaluate the usage of IPSec in vehicular (to >>>> infrastructure) communications. >>>> >>> >>> =3D> We authors are planning to add more papers (including your paper) >>> for security and privacy to the next revision. >>> >>>> >>>> 2- In the same line I think the document lacks in more *evaluation >>>> deployment* works in the scientific literature. For sure, some of the >>>> currently included papers include evaluations, but I think a concrete >>>> section or an update with paper of this line would be beneficial to pe= ople >>>> to understand the feasibility of IPv6 in vehicular communications. Fro= m our >>>> side we propose the next one: >>>> >>>> Jos=C3=A9 Santa, Pedro J. Fern=C3=A1ndez, Fernando Pere=C3=B1iguez, An= tonio F. >>>> Skarmeta. Deployment of Vehicular Networks in Highways Using 802.11p a= nd >>>> IPv6 Technologies. International Journal of Ad Hoc and Ubiquitous >>>> Computing, in press these days, 2016. >>>> >>>> In this paper we present the work carried out in frames of the FOTsis >>>> project to deploy real IPv6 vehicle-to-infrastructure networks around >>>> Europe, together with the main evaluations performed. >>>> >>> >>> =3D> Sure. I agree that the evaluation for deployment is important. >>> After reviewing your paper, we will consider to include your abov= e >>> paper into the next revision. >>> >>>> >>>> 3- In the document there is a lack in mentioning the synergy between >>>> currently standardized architecture at *ISO/ETSI and the usage of IPv6= *. >>>> However, IEEE WAVE has been cited multitude of times. Our next paper c= ould >>>> help to improve this needed part of the document, which could be proba= bly >>>> added in the mobility management section: >>>> >>>> Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Fernando Bernal= , Pedro J. >>>> Fern=C3=A1ndez, Rafael Mar=C3=ADn-L=C3=B3pez, Antonio F. Skarmeta. A F= ramework for >>>> Supporting Network Continuity in Vehicular IPv6 Communications. >>>> IEEE Intelligent Transportation Systems Magazine, vol. 6, no. 4, pp. 1= 7-34, >>>> doi: 10.1109/MITS.2013.2274876, 2014. >>>> >>>> =3D> After reviewing your paper, we will also consider to include t= his >>> paper in the next revision. >>> >>> >>>> In this work we present an architecture that complements the ETSI/ISO >>>> communication architecture by using IPv6 (IETF) technologies. >>>> >>> =3D> It seems like this work will be able to broaden the vehicular >>> network architecture along with IEEE WAVE Standards. >>> >>>> >>>> 4- In all of our papers we transmit IPv6 packets over IEEE 802.11p, bu= t >>>> we have also tested the possibility of also sending ETSI *CAM/DENM* >>>> messages over this platform by using UDP. This approach could be >>>> interesting for the IETF ITS group. I am not completely sure about the >>>> place to add this contribution, but in this case I doubt about the nee= d to >>>> create a new section, given that I am not sure if there are many other >>>> works in this line. >>>> >>>> Jos=C3=A9 Santa, Fernando Pere=C3=B1iguez-Garc=C3=ADa, Antonio Morag= =C3=B3n, Antonio F. >>>> Skarmeta. Experimental Evaluation of CAM and DENM Messaging Services i= n >>>> Vehicular Communications. Transportation Research Part C: >>>> Emerging Technologies, vol. 2014, pp. 98-120, doi: >>>> http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014. >>>> >>>> In this work we provide an implementation of the ETSI messaging >>>> algorithm over our IPv6-o-11p basis. >>>> >>>> =3D> After reviewing the above paper, we will consider to include thi= s >>> paper to the next revision. >>> >>> >>>> Please, let me know if you need further text, depending on the interes= t >>>> you find in my previous suggestions. >>>> >>> >>> =3D> Through the review of all of your papers, I will ask you further >>> text if needed. >>> >>> Thanks. >>> >>> Best Regards, >>> Paul >>> >>> >>>> Regards, >>>> >>>> -- >>>> Jos=C3=A9 Santa Lozano >>>> Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones >>>> Facultad de Inform=C3=A1tica >>>> Universidad de Murcia >>>> 30100 Murcia, Spain >>>> Telf: +34-868-888771 / +34-868-884455 >>>> Fax: +34-868-884151 >>>> Web: http://ants.inf.um.es/~josesanta >>>> >>>> >>>> >>>> El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong < >>>> jaehoon.paul@gmail.com> escribi=C3=B3: >>>> >>>> Hi all, >>>> I have posted a new its I-D: >>>> - Title >>>> Survey on IP-based Vehicular Networking for Intelligent >>>> Transportation Systems >>>> >>>> - File >>>> >>>> https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-surve= y-00 >>>> >>>> - Abstract >>>> This document surveys the IP-based vehicular networks, which are >>>> considered a key component of Intelligent Transportation Systems >>>> (ITS). The main topics of vehicular networking are vehicle-to- >>>> vehicle (V2V), vehicle-to-infrastructure (V2I), and infrastructure- >>>> to-vehicle (I2V) networking. Vehicular networks deal with some >>>> critical aspects, such as IP address autoconfiguration, routing, >>>> handover, and mobility management. This document summarizes and >>>> analyzes the previous research activities that use IPv4 or IPv6 for >>>> vehicular networking" >>>> >>>> In this draft, we show the survey on IP-based Vehicular Networking >>>> for Intelligent Transportation Systems. >>>> This draft will be a good foundation to figure out the state-of-the-ar= t >>>> schemes for IP-based vehicular networking, so we can use it for >>>> "ITS General Problem Area" that is one of work items in our its group: >>>> https://trac.tools.ietf.org/wg/its/trac/ >>>> >>>> It will be great for you to take a look at this I-D and give us >>>> comments or suggestions. >>>> >>>> Thanks. >>>> >>>> Best Regards, >>>> Paul >>>> -- >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>>> Assistant Professor >>>> Department of Software >>>> Sungkyunkwan University >>>> Office: +82-31-299-4957 >>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> >>> >>> >>> -- >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>> Assistant Professor >>> Department of Software >>> Sungkyunkwan University >>> Office: +82-31-299-4957 >>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>> >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>> >> > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > --94eb2c0c80567448d905382397f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

thank you. If you have any que= stions or comments, please don't hesitate to mail me.

Best regards,
Laszlo

--
L=C3=A1szl=C3=B3 BOKOR, Ph.D.
Budapest University of Techn= ology and Economics (BME)
Department of Networked Systems and Ser= vices (HIT)
Tel: +36-1-463-2048, Fax: +36-1-463-3263


2016-07-21 1:00 GMT+02:00 Mr. Jaehoon Paul= Jeong <jaehoon.paul@gmail.com>:
Hi Bokor,
This looks an interesting pape= r.
I will read this paper and discuss whether to include it with = my coauthors.

Thanks.

Bes= t Regards,
Paul

<= div class=3D"h5">

= On Wed, Jul 13, 2016 at 5:49 PM, Bokor L=C3=A1szl=C3=B3 &= lt;goodzi@gmail.com> wrote:

Best regards,
Laszlo
=
--
L=C3=A1szl=C3=B3 BOKOR, Ph.D.
Bu= dapest University of Technology and Economics (BME)
Department of= Networked Systems and Services (HIT)



2016-07-11 18:48 GMT+02:00 Mr. Jaehoon= Paul Jeong <jaehoon.paul@gmail.com>:
Hi Jose,
Thanks for your good comment= s and suggestions.

My answers are inline below:

On Fri, Jul 8, 2016 at 5:55 PM, Jos=C3=A9 Santa Lozano <josesanta@um.es> wrote:
Dear Paul,

Thanks for the work. Please consider the next comments = and suggestions of papers to add:

1- I think it would be interesting= to also include a section about security. Even though you have adde= d a small note at the end of the document, I think that probably some=C2=A0= works in the area could arise. From our side we propose the next paper to a= dd:

Pedro J. Fern=C3=A1ndez, Jos=C3=A9 Santa, Fernando Bernal, Anton= io F. Skarmeta.=C2=A0Securing Vehicular IPv6=C2=A0Communications. IEEE Tran= sactions on Dependable and Secure Computing, vol. 13, no. 1, pp. 46-58, 201= 6.

In this paper we evaluate the usage of IPSec in vehic= ular (to infrastructure) communications.

<= /div>
=C2=A0=3D> We authors are planning to add more papers (= including your paper) for security and privacy to the next revision.
<= span>

2- In the same line I think the document lacks in more evaluation dep= loyment works in the scientific literature. For sure, some of the curre= ntly included papers include evaluations, but I think a concrete section or= an update with paper of this line would be beneficial to people to underst= and the feasibility of IPv6 in vehicular communications. From our side we p= ropose the next one:

Jos=C3=A9 Santa, Pedro J. Fer= n=C3=A1ndez, Fernando Pere=C3=B1iguez, Antonio F. Skarmeta.=C2=A0Deployment= of Vehicular Networks in Highways Using 802.11p and IPv6 Technologies.=C2= =A0International Journal of Ad Hoc and Ubiquitous Computing, in press these= days, 2016.

In this paper we present the work car= ried out in frames of the FOTsis project to deploy real IPv6 vehicle-to-inf= rastructure networks around Europe, together with the main evaluations perf= ormed.

=C2=A0 =C2=A0 =C2=A0 After reviewing your paper, we will consider to inclu= de your above paper into the next revision.

3- In the document the= re is a lack in mentioning the synergy between currently standardized archi= tecture at ISO/ETSI and the usage of IPv6. However, IEEE WAVE has be= en cited multitude of times. Our next paper could help to improve this need= ed part of the document, which could be probably added in the mobility mana= gement section:

Jos=C3=A9 Santa, Fernando Pere=C3= =B1iguez-Garc=C3=ADa, Fernando Bernal, Pedro J. Fern=C3=A1ndez, Rafael Mar= =C3=ADn-L=C3=B3pez, Antonio F.=C2=A0Skarmeta.=C2=A0A Framework for Supporti= ng Network Continuity in Vehicular IPv6 Communications. IEEE=C2=A0Intellige= nt Transportation Systems Magazine, vol. 6, no. 4, pp. 17-34, doi: 10.1109/= MITS.2013.2274876, 2014.

=C2=A0=3D>=C2=A0=C2=A0 After reviewing your paper, we will also conside= r to include this paper in the next revision.
=C2=A0 =C2=A0= =C2=A0
In this work we present an architecture that complements the ETSI/ISO= communication architecture by using IPv6 (IETF) technologies.
<= /blockquote>
=C2=A0=3D> It seems like this work will be able = to broaden the vehicular network architecture along with IEEE WAVE Standard= s.
4- In all of our papers we transmit IPv6 packets over IEEE 802.= 11p, but we have also tested the possibility of also sending ETSI CAM/DE= NM messages over this platform by using UDP. This approach could be int= eresting for the IETF ITS group. I am not completely sure about the place t= o add this contribution, but in this case I doubt about the need to create = a new section, given that I am not sure if there are many other works in th= is line.

<= /blockquote>
=C2=A0=3D> After reviewing the above paper, we w= ill consider to include this paper to the next revision.=C2=A0
<= div>=C2=A0=C2=A0
=
Please, let me know if you need further text, depending on = the interest you find in my previous suggestions.
<= div>
=C2=A0=3D> =C2=A0Through the review of all of = your papers, I will ask you further text if needed.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks.

=C2=A0 =C2=A0= =C2=A0 =C2=A0Best Regards,=C2=A0
= =C2=A0 =C2=A0 =C2=A0 =C2=A0Paul


R= egards,

--=C2=A0
Jos=C3=A9 San= ta Lozano
Dept. Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicacio= nes
Facultad de Inform=C3=A1tica
Universidad de Murcia
30100 Murci= a, Spain
Telf: +34-868-888771 / +34-868-884455
Fax: +34-868-8841= 51
Web:=C2=A0http://ants.inf.um.es/~josesanta



El 7 jul 2016, a las 19:33, Mr. Ja= ehoon Paul Jeong <jaehoon.paul@gmail.com> escribi=C3=B3:

Hi all,
I hav= e posted a new its I-D:
- Title
=C2=A0 =C2=A0Survey on IP-based Vehic= ular Networking for Intelligent Transportation Systems=C2=A0

- File<= br>=C2=A0 =C2=A0https://tools.ietf.org/html/d= raft-jeong-its-vehicular-networking-survey-00

- Abstract
=C2= =A0 =C2=A0This document surveys the IP-based vehicular networks, which are<= br>=C2=A0 =C2=A0considered a key component of Intelligent Transportation Sy= stems
=C2=A0 =C2=A0(ITS).=C2=A0 The main topics of vehicular networking = are vehicle-to-
=C2=A0 =C2=A0vehicle (V2V), vehicle-to-infrastructure (V= 2I), and infrastructure-
=C2=A0 =C2=A0to-vehicle (I2V) networking.=C2=A0= Vehicular networks deal with some
=C2=A0 =C2=A0critical aspects, such a= s IP address autoconfiguration, routing,
=C2=A0 =C2=A0handover, and mobi= lity management.=C2=A0 This document summarizes and
=C2=A0 =C2=A0analyze= s the previous research activities that use IPv4 or IPv6 for
=C2=A0 =C2= =A0vehicular networking"

In this draft, we show the survey on I= P-based Vehicular Networking=C2=A0
for Intelligent Transportation System= s.=C2=A0
This draft will be a good foundation to figure out the state-of= -the-art
schemes for IP-based vehicular networking, so we can use it for=
"ITS General Problem Area" that is one of work items in our i= ts group:
https://trac.tools.ietf.org/wg/its/trac/

It will be gre= at for you to take a look at this I-D and give us comments or suggestions.<= br>
Thanks.

Best Regards,
Paul
--=C2=A0
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. J= aehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software=
Sungkyunkwan University
Office: +82-31-299-4957
Email:=C2=A0<= a href=3D"mailto:jaehoon.paul@gmail.com" target=3D"_blank">jaehoon.paul@gma= il.com,=C2=A0pa= uljeong@skku.edu
Personal Homepage:=C2=A0http://iotlab.skku.edu/p= eople-jaehoon-jeong.php
__________________________= _____________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/= its




--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant ProfessorDepartment of Software
Sungkyunkwan University
Office: +82-31-299-4= 957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Perso= nal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php

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





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

--94eb2c0c80567448d905382397f4-- From nobody Thu Jul 21 04:30:23 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EB912DD2B for ; Thu, 21 Jul 2016 04:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 UHd67TjJu-51 for ; Thu, 21 Jul 2016 04:30:19 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 3EAF212DE36 for ; Thu, 21 Jul 2016 04:26:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2138C615EB for ; Thu, 21 Jul 2016 07:26:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pwq-+cecIG8B for ; Thu, 21 Jul 2016 07:26:44 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-a369.meeting.ietf.org [31.133.163.105]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 86B6A602B4 for ; Thu, 21 Jul 2016 07:26:41 -0400 (EDT) To: its@ietf.org From: Robert Moskowitz Message-ID: Date: Thu, 21 Jul 2016 13:26:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [its] V2P - potentially large use case for IPv6 within the DSRC infrastructure X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 11:30:22 -0000 I have seen a number of DSRC/WAVE demonstrations with cell phones being part of the network for pedestrians and bicycles. Honda also showed it for motorcycles, but future motorcycles can have an embedded DSRC device connected to the bike's CANbus for better information. The concern here is that DSRC is already quite congested in many areas where there are pedestrians and in places near mass-transit access, and pdestrians walking all over the place, how could a car listen to all the phones chirping away? Add to this the regulatory challenge of yet another radio on the phones. Qualcomm has demonstrated a duo radio with standard WiFi and DSRC, but many just change the radio, switch from the WiFi bands to the 11p bands and switch back and that has serious performance concerns. So let's keep the phones on IP and route the WAVE messages over IP to/from the phones. This would use Infrastructure components like traffic lights as the relays. There is the security question in that is the 1609.2 certificate that of the phone's or the infrastructure piece? In the former case, the PKI proposal from CAMP would have major challenges scaling that large. Of course the counter proposal Verizon submitted ;) could scale up to certs for all the phones. If the signing is done by the infrastructure cert which is not a anonymous cert (like in the vehicles), does this present any privacy issues for the phone holder? Probably not. But a real potential use case. Bob Moskowitz From nobody Thu Jul 21 04:45:23 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD2C12D119 for ; Thu, 21 Jul 2016 04:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 7KmNg8Cy7GjM for ; Thu, 21 Jul 2016 04:45:18 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 E506612DE2D for ; Thu, 21 Jul 2016 04:42:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 383596214B for ; Thu, 21 Jul 2016 07:42:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vPq6T4uK+1hq for ; Thu, 21 Jul 2016 07:42:39 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-a369.meeting.ietf.org [31.133.163.105]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 8F2AF62143 for ; Thu, 21 Jul 2016 07:42:38 -0400 (EDT) To: "its@ietf.org" From: Robert Moskowitz Message-ID: <948dd6e9-038a-5ce4-544f-8793e2690d97@htt-consult.com> Date: Thu, 21 Jul 2016 13:42:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [its] Referencing IEEE 802.11p-2010 in drafts X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 11:45:20 -0000 I should point out to all I-D authors that IEEE 802.11p-2010 is obsolete. It was part of the rollup that resulted in IEEE 802.11-2012. So procedurally it is incorrect to reference it any more. I just checked, and although it has not been listed on the ieee802.org's 'get 802' documents page for some years, the URL in the current drafts still works. But to be technically correct, you need to reference appropriate sections in 802.11. And even 802.11-2012 will soon be replaced by 802.11-2016. Bob Moskowitz From nobody Thu Jul 21 04:45:55 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD3412D150 for ; Thu, 21 Jul 2016 04:45:37 -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, 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 (1024-bit key) header.d=securityinnovation.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0pj9kWBKZRA for ; Thu, 21 Jul 2016 04:45:33 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 6C15912D5C4 for ; Thu, 21 Jul 2016 04:43:00 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id s189so109028300vkh.1 for ; Thu, 21 Jul 2016 04:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g+GXo9BuEfOvmFn/N3Z/T1xZu27ss2QR5AhPA1HTvzg=; b=PU4G8edlKSqCd49ZIqC8Haap6eCYCkFbf00qeXbsWTAalgKWQtARv5r9z6ALzWpgFx eRWswxMjOaICK9LxqSsAUMsEdUEi94hR0BIqouUGQL8W+NPj3iaQnU2utM7GSIrH/G1N UDIbC4S1WqboU/bskyOwX9iPR/q1YSrj0zcfk= 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=g+GXo9BuEfOvmFn/N3Z/T1xZu27ss2QR5AhPA1HTvzg=; b=jUeGQPAy8pHaqS0umxtuVqZMm0rt17aSxGZD1duukdPBJxSE6Pss3C/sI5nksPpzNP lg6+xOvcYQWmNKAhWcChWriPRfECXAObSDVbTtHgrChWtv0mxD56eezBF3IzXTGufAwB ARhCfoe16QPwqtKxxGSBILNwvpA/c4NZZRY+xNLD5yDCLmebu1R4GY1+FO7QR2zyfEph 9a9QC3+eB+Z0/vu7zY1mEy0Pi+GTuij6hoIRpYN04vqbd66q1Ii+wjM13onKGi9LdiJ5 UJ64YZWDuP4jqRWgqRWYVilHUoa1LxedKqSGXcoCV8kO3hygxqVtnPP/VLBiKsZqg81i PC8A== X-Gm-Message-State: ALyK8tLMHHQlM0/018PpBaZjIWodaw6rVCR+x+WoFQF8eIZNAd2P3PTYVd+Gx3/cxBrvBKKYXn7vSz1mLyv77J8N X-Received: by 10.176.67.6 with SMTP id k6mr11524802uak.96.1469101379557; Thu, 21 Jul 2016 04:42:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.67.134 with HTTP; Thu, 21 Jul 2016 04:42:58 -0700 (PDT) In-Reply-To: References: From: William Whyte Date: Thu, 21 Jul 2016 07:42:58 -0400 Message-ID: To: Robert Moskowitz Content-Type: multipart/alternative; boundary=001a114b19cede2dc6053823d1e3 Archived-At: Cc: its@ietf.org Subject: Re: [its] V2P - potentially large use case for IPv6 within the DSRC infrastructure X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 11:45:37 -0000 --001a114b19cede2dc6053823d1e3 Content-Type: text/plain; charset=UTF-8 Hi Bob, Who did Verizon submit that "counter proposal" to and is it available publicly? I don't remember seeing a specific proposal in the 1609 working group, or, to be honest, anywhere. Cheers, William On Thu, Jul 21, 2016 at 7:26 AM, Robert Moskowitz wrote: > I have seen a number of DSRC/WAVE demonstrations with cell phones being > part of the network for pedestrians and bicycles. Honda also showed it for > motorcycles, but future motorcycles can have an embedded DSRC device > connected to the bike's CANbus for better information. > > > The concern here is that DSRC is already quite congested in many areas > where there are pedestrians and in places near mass-transit access, and > pdestrians walking all over the place, how could a car listen to all the > phones chirping away? > > > Add to this the regulatory challenge of yet another radio on the phones. > Qualcomm has demonstrated a duo radio with standard WiFi and DSRC, but many > just change the radio, switch from the WiFi bands to the 11p bands and > switch back and that has serious performance concerns. > > > So let's keep the phones on IP and route the WAVE messages over IP to/from > the phones. This would use Infrastructure components like traffic lights > as the relays. > > > There is the security question in that is the 1609.2 certificate that of > the phone's or the infrastructure piece? In the former case, the PKI > proposal from CAMP would have major challenges scaling that large. Of > course the counter proposal Verizon submitted ;) could scale up to certs > for all the phones. If the signing is done by the infrastructure cert > which is not a anonymous cert (like in the vehicles), does this present any > privacy issues for the phone holder? Probably not. > > > But a real potential use case. > > > Bob Moskowitz > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --001a114b19cede2dc6053823d1e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bob,

Who did Verizon submit that &qu= ot;counter proposal" to and is it available publicly? I don't reme= mber seeing a specific proposal in the 1609 working group, or, to be honest= , anywhere.

Cheers,

Willi= am


On Thu, Jul 21, 2016 at 7:26 AM, Robert Moskowitz <rgm-= ietf@htt-consult.com> wrote:
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

--001a114b19cede2dc6053823d1e3-- From nobody Thu Jul 21 04:48: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 09C1D12DB02 for ; Thu, 21 Jul 2016 04:48:12 -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 AJP4YjBvX_vv for ; Thu, 21 Jul 2016 04:48:10 -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 4DBFC12DDA1 for ; Thu, 21 Jul 2016 04:46:59 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id p64so29848167pfb.1 for ; Thu, 21 Jul 2016 04:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aoqo18i8Uyk+c+nA5Z9WapsCAkKCbCEGqNtKte7+c1o=; b=ZMAbULu16OtiO1xk5BcoFuFznyphqbV17loHb5bFtF5uyc1KNxCw13fGZX8i2d7diC 0G/kKU5b3sQThCVsmByXvnC1fj3RYy/5s9QyA4BLNWacW1lDn1W/kZ84NCRrAhbTkYHD lPV1D+CE7NwPDvgom+/ks1S20ZvDobpH3mSxpD+vNmRlw34SrOwzPnt8fg+f3qN3faVl dlLswO3DZuDZPQh2HLwQ4Q+cMQm9GMkyAobLDbCalmAxn7V60gaNDlzoQbT5XRBOwXB1 moFGejSUJ60CDdjNfLcAUSpXsurnbKjv1CXK/mdE8JMXoKe4CHbTdHX6sQZBtwcFvbTo 9FdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aoqo18i8Uyk+c+nA5Z9WapsCAkKCbCEGqNtKte7+c1o=; b=GeFGnUld9kJ/gKnEPI2pmmIIqbRO6U5tzgZxlFzFMOcWhplR4zQOFeA1RHz7VbuH6h FHGF0VMVkZKxVJudzLkRJT3DsrpawDHmjb5P30OkSSq/RNyQpPCOhdJ4qbWLgeSiYfOL QTrUuhCASQkEkv6sjw+BeU1lF2XKS9bRkYwhvvv9kL/DMMk3EQYG+MSZX2w4a9Z4d3wW 4q+9UZCsct25X48ihIGRnRMc5dFzKiHRfLFy36pYHpDiXVYoz8SIKYXzSbhy28j7/fJW 1/AAmjdvqo+JFVO2GVuOIkAWSQAAWFluSpTONGMBfk2Y0/d2J8WcKSMmbL1S8ZuX6ONC jDow== X-Gm-Message-State: ALyK8tJk9bYiYR7LMG+p3V/ZUd5+MG7yEqlFToVWcquYyvPTKRHqCzc+uw4m7S04/V6ZIw== X-Received: by 10.98.69.81 with SMTP id s78mr71922529pfa.63.1469101618913; Thu, 21 Jul 2016 04:46:58 -0700 (PDT) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id e4sm11750086pfe.69.2016.07.21.04.46.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 04:46:58 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Jong-Hyouk Lee In-Reply-To: <948dd6e9-038a-5ce4-544f-8793e2690d97@htt-consult.com> Date: Thu, 21 Jul 2016 20:46:52 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2119B60C-7C12-47F4-B9EF-37AEEF5E7372@gmail.com> References: <948dd6e9-038a-5ce4-544f-8793e2690d97@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] Referencing IEEE 802.11p-2010 in drafts X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 11:48:12 -0000 Thx, noted. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Jul 21, 2016, at 8:42 PM, Robert Moskowitz = wrote: >=20 > I should point out to all I-D authors that IEEE 802.11p-2010 is = obsolete. It was part of the rollup that resulted in IEEE 802.11-2012. = So procedurally it is incorrect to reference it any more. >=20 >=20 > I just checked, and although it has not been listed on the = ieee802.org's 'get 802' documents page for some years, the URL in the = current drafts still works. But to be technically correct, you need to = reference appropriate sections in 802.11. And even 802.11-2012 will = soon be replaced by 802.11-2016. >=20 >=20 > Bob Moskowitz >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Thu Jul 21 04:48: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 493BB12DB6F for ; Thu, 21 Jul 2016 04:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 zXDWKvGM5evu for ; Thu, 21 Jul 2016 04:48:39 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 159A512D1AE for ; Thu, 21 Jul 2016 04:47:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 6D76261FDB; Thu, 21 Jul 2016 07:47:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AWBLDBHJmH3s; Thu, 21 Jul 2016 07:47:24 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-a369.meeting.ietf.org [31.133.163.105]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 08DA1615D9; Thu, 21 Jul 2016 07:47:22 -0400 (EDT) To: William Whyte References: From: Robert Moskowitz Message-ID: <90a9812d-8f0a-c1f6-49c2-9283da1a1104@htt-consult.com> Date: Thu, 21 Jul 2016 13:47:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EEA9BF7D3CDE6D33273B3A90" Archived-At: Cc: its@ietf.org Subject: Re: [its] V2P - potentially large use case for IPv6 within the DSRC infrastructure X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 11:48:41 -0000 This is a multi-part message in MIME format. --------------EEA9BF7D3CDE6D33273B3A90 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit It was submitted to the CAMP pilot RFI. I wrote it with Robert Hopley over at Verizon, remember him? It was a very similar PKI, but turned a lot of pieces around to work with phones as clients. The RFI said it was open to other proposals, they responded to Verizon that they really did not want any other approaches. I do not have it. Contact Hopley at Verizon and perhaps he can get it to you. On 07/21/2016 01:42 PM, William Whyte wrote: > Hi Bob, > > Who did Verizon submit that "counter proposal" to and is it available > publicly? I don't remember seeing a specific proposal in the 1609 > working group, or, to be honest, anywhere. > > Cheers, > > William > > > On Thu, Jul 21, 2016 at 7:26 AM, Robert Moskowitz > > wrote: > > I have seen a number of DSRC/WAVE demonstrations with cell phones > being part of the network for pedestrians and bicycles. Honda also > showed it for motorcycles, but future motorcycles can have an > embedded DSRC device connected to the bike's CANbus for better > information. > > > The concern here is that DSRC is already quite congested in many > areas where there are pedestrians and in places near mass-transit > access, and pdestrians walking all over the place, how could a car > listen to all the phones chirping away? > > > Add to this the regulatory challenge of yet another radio on the > phones. Qualcomm has demonstrated a duo radio with standard WiFi > and DSRC, but many just change the radio, switch from the WiFi > bands to the 11p bands and switch back and that has serious > performance concerns. > > > So let's keep the phones on IP and route the WAVE messages over IP > to/from the phones. This would use Infrastructure components like > traffic lights as the relays. > > > There is the security question in that is the 1609.2 certificate > that of the phone's or the infrastructure piece? In the former > case, the PKI proposal from CAMP would have major challenges > scaling that large. Of course the counter proposal Verizon > submitted ;) could scale up to certs for all the phones. If the > signing is done by the infrastructure cert which is not a > anonymous cert (like in the vehicles), does this present any > privacy issues for the phone holder? Probably not. > > > But a real potential use case. > > > Bob Moskowitz > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --------------EEA9BF7D3CDE6D33273B3A90 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

It was submitted to the CAMP pilot RFI.  I wrote it with Robert Hopley over at Verizon, remember him?


It was a very similar PKI, but turned a lot of pieces around to work with phones as clients.  The RFI said it was open to other proposals, they responded to Verizon that they really did not want any other approaches.


I do not have it.  Contact Hopley at Verizon and perhaps he can get it to you.


On 07/21/2016 01:42 PM, William Whyte wrote:
Hi Bob,

Who did Verizon submit that "counter proposal" to and is it available publicly? I don't remember seeing a specific proposal in the 1609 working group, or, to be honest, anywhere.

Cheers,

William


On Thu, Jul 21, 2016 at 7:26 AM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
I have seen a number of DSRC/WAVE demonstrations with cell phones being part of the network for pedestrians and bicycles.  Honda also showed it for motorcycles, but future motorcycles can have an embedded DSRC device connected to the bike's CANbus for better information.


The concern here is that DSRC is already quite congested in many areas where there are pedestrians and in places near mass-transit access, and pdestrians walking all over the place, how could a car listen to all the phones chirping away?


Add to this the regulatory challenge of yet another radio on the phones.  Qualcomm has demonstrated a duo radio with standard WiFi and DSRC, but many just change the radio, switch from the WiFi bands to the 11p bands and switch back and that has serious performance concerns.


So let's keep the phones on IP and route the WAVE messages over IP to/from the phones.  This would use Infrastructure components like traffic lights as the relays.


There is the security question in that is the 1609.2 certificate that of the phone's or the infrastructure piece?  In the former case, the PKI proposal from CAMP would have major challenges scaling that large.  Of course the counter proposal Verizon submitted ;) could scale up to certs for all the phones.   If the signing is done by the infrastructure cert which is not a anonymous cert (like in the vehicles), does this present any privacy issues for the phone holder?  Probably not.


But a real potential use case.


Bob Moskowitz


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


--------------EEA9BF7D3CDE6D33273B3A90-- From nobody Thu Jul 21 04:51: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 8B97512B042 for ; Thu, 21 Jul 2016 04:51:07 -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 ZQ9wQIMr4x2T for ; Thu, 21 Jul 2016 04:51:05 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 06A3412D147 for ; Thu, 21 Jul 2016 04:51:05 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id iw10so28516994pac.2 for ; Thu, 21 Jul 2016 04:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=MUrbGKlNWrzI+uL5wbLbIB7+6c4YzXuljXRlTaEZdt4=; b=xiACU+7989/0fGdMsxCFxPG+310aov/vqqgHwSfyrZKigcmIMUsWTAKB5b6PDaxanL 0l87Y93goqzskfPBVK3UKmr4mPZHL4wPQ129J9Qvb7noNrRtU66PUO3Gj1qLWiW2BJ17 bCc6HfDC0e+uL+GVwufytVzYulz1TpJecNsfQ677zQbZNYAiEiK3pvuEBfoRRg/fLv3A r+4HXnspbs5uhfIsR7lF2BtxKbxZnOtffbjLNsZR31iHstY7IMxJfST4me4HM11k7n0D PBnHx848xzqMvDRfgr4zh6saKgoeZtmkcmMA9+d2DmixDXku3LL7Wt9RrMBIqsO3l9fE QaOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=MUrbGKlNWrzI+uL5wbLbIB7+6c4YzXuljXRlTaEZdt4=; b=nDBJaR3Z0m/9dHy1Pjoo4VEzEWj+zAVZx3kRn2IwcqilpgQrnDfZHkNU7YNDml6Rq1 IYe4745eScATE4dwWKZ4nbD7VHdDKHpEY5XHBq6ZorpiOkaDysMkrNeMbXfooAUnhbXv szWe6yljmAwp4uJE/1ZnjTB1w+oIHStM8Z8bFTdUAOeVmTeYQl+slMzw92nP+y4YBe1E oqq9ao2A6EMnd0hn+VvOTgbdqZSqJlioozE0Ky13ZKkMadIUZRHJ0hJI1epXZA113bY+ 1D/1VubvgsmDAF0nKKvHr7Hbj1wsZPWVDdTSRj2RRgpuEtBw+nevJ8yW6yN0LA7PMD72 Nb8A== X-Gm-Message-State: ALyK8tL5tAlpkO8DpLKm8sv/ZfJQQlvLgHN848IeUCYkbWUCVkhtQEpCEzx1272TtDlhrg== X-Received: by 10.66.197.195 with SMTP id iw3mr69545060pac.82.1469101864637; Thu, 21 Jul 2016 04:51:04 -0700 (PDT) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id tm1sm11802247pab.31.2016.07.21.04.51.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 04:51:04 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_9834F8F3-D472-413D-BCBF-3BFE88EEE86C" From: Jong-Hyouk Lee In-Reply-To: <90a9812d-8f0a-c1f6-49c2-9283da1a1104@htt-consult.com> Date: Thu, 21 Jul 2016 20:50:59 +0900 Message-Id: References: <90a9812d-8f0a-c1f6-49c2-9283da1a1104@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3124) Archived-At: Cc: William Whyte , its@ietf.org Subject: Re: [its] V2P - potentially large use case for IPv6 within the DSRC infrastructure X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 11:51:07 -0000 --Apple-Mail=_9834F8F3-D472-413D-BCBF-3BFE88EEE86C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thx for arising a V2P scenario. If possible, can you give the pointer?=20= -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Jul 21, 2016, at 8:47 PM, Robert Moskowitz = wrote: >=20 > It was submitted to the CAMP pilot RFI. I wrote it with Robert Hopley = over at Verizon, remember him? >=20 >=20 > It was a very similar PKI, but turned a lot of pieces around to work = with phones as clients. The RFI said it was open to other proposals, = they responded to Verizon that they really did not want any other = approaches. >=20 > I do not have it. Contact Hopley at Verizon and perhaps he can get it = to you. >=20 > On 07/21/2016 01:42 PM, William Whyte wrote: >> Hi Bob, >>=20 >> Who did Verizon submit that "counter proposal" to and is it available = publicly? I don't remember seeing a specific proposal in the 1609 = working group, or, to be honest, anywhere. >>=20 >> Cheers, >>=20 >> William >>=20 >>=20 >> On Thu, Jul 21, 2016 at 7:26 AM, Robert Moskowitz = > wrote: >> I have seen a number of DSRC/WAVE demonstrations with cell phones = being part of the network for pedestrians and bicycles. Honda also = showed it for motorcycles, but future motorcycles can have an embedded = DSRC device connected to the bike's CANbus for better information. >>=20 >>=20 >> The concern here is that DSRC is already quite congested in many = areas where there are pedestrians and in places near mass-transit = access, and pdestrians walking all over the place, how could a car = listen to all the phones chirping away? >>=20 >>=20 >> Add to this the regulatory challenge of yet another radio on the = phones. Qualcomm has demonstrated a duo radio with standard WiFi and = DSRC, but many just change the radio, switch from the WiFi bands to the = 11p bands and switch back and that has serious performance concerns. >>=20 >>=20 >> So let's keep the phones on IP and route the WAVE messages over IP = to/from the phones. This would use Infrastructure components like = traffic lights as the relays. >>=20 >>=20 >> There is the security question in that is the 1609.2 certificate that = of the phone's or the infrastructure piece? In the former case, the PKI = proposal from CAMP would have major challenges scaling that large. Of = course the counter proposal Verizon submitted ;) could scale up to certs = for all the phones. If the signing is done by the infrastructure cert = which is not a anonymous cert (like in the vehicles), does this present = any privacy issues for the phone holder? Probably not. >>=20 >>=20 >> But a real potential use case. >>=20 >>=20 >> Bob Moskowitz >>=20 >>=20 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its = >>=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_9834F8F3-D472-413D-BCBF-3BFE88EEE86C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Thx for arising a V2P scenario. If possible, can you give the pointer? 
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Jul 21, 2016, at 8:47 PM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:

It was submitted to the CAMP pilot RFI.  I wrote it with Robert Hopley over at Verizon, remember him?


It was a very similar PKI, but turned a lot of pieces around to work with phones as clients.  The RFI said it was open to other proposals, they responded to Verizon that they really did not want any other approaches.


I do not have it.  Contact Hopley at Verizon and perhaps he can get it to you.


On 07/21/2016 01:42 PM, William Whyte wrote:
Hi Bob,

Who did Verizon submit that "counter proposal" to and is it available publicly? I don't remember seeing a specific proposal in the 1609 working group, or, to be honest, anywhere.

Cheers,

William


On Thu, Jul 21, 2016 at 7:26 AM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
I have seen a number of DSRC/WAVE demonstrations with cell phones being part of the network for pedestrians and bicycles.  Honda also showed it for motorcycles, but future motorcycles can have an embedded DSRC device connected to the bike's CANbus for better information.


The concern here is that DSRC is already quite congested in many areas where there are pedestrians and in places near mass-transit access, and pdestrians walking all over the place, how could a car listen to all the phones chirping away?


Add to this the regulatory challenge of yet another radio on the phones.  Qualcomm has demonstrated a duo radio with standard WiFi and DSRC, but many just change the radio, switch from the WiFi bands to the 11p bands and switch back and that has serious performance concerns.


So let's keep the phones on IP and route the WAVE messages over IP to/from the phones.  This would use Infrastructure components like traffic lights as the relays.


There is the security question in that is the 1609.2 certificate that of the phone's or the infrastructure piece?  In the former case, the PKI proposal from CAMP would have major challenges scaling that large.  Of course the counter proposal Verizon submitted ;) could scale up to certs for all the phones.   If the signing is done by the infrastructure cert which is not a anonymous cert (like in the vehicles), does this present any privacy issues for the phone holder?  Probably not.


But a real potential use case.


Bob Moskowitz


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


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

--Apple-Mail=_9834F8F3-D472-413D-BCBF-3BFE88EEE86C-- From nobody Thu Jul 21 04:56:25 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5722612D594 for ; Thu, 21 Jul 2016 04:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 f79-vVRbJ6j5 for ; Thu, 21 Jul 2016 04:56:21 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 8E2EA12D5CA for ; Thu, 21 Jul 2016 04:56:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id EF01E6214C; Thu, 21 Jul 2016 07:56:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gwpgXtzVAGEc; Thu, 21 Jul 2016 07:56:10 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-a369.meeting.ietf.org [31.133.163.105]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 3CEAB6214B; Thu, 21 Jul 2016 07:56:07 -0400 (EDT) To: Jong-Hyouk Lee References: <90a9812d-8f0a-c1f6-49c2-9283da1a1104@htt-consult.com> From: Robert Moskowitz Message-ID: <42bf1cfd-724b-878c-d366-ff00588336b1@htt-consult.com> Date: Thu, 21 Jul 2016 13:56:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------67B59E7C01E4DEF1CB2BBCF2" Archived-At: Cc: William Whyte , its@ietf.org Subject: Re: [its] V2P - potentially large use case for IPv6 within the DSRC infrastructure X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 11:56:23 -0000 This is a multi-part message in MIME format. --------------67B59E7C01E4DEF1CB2BBCF2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Much of it was at ITS World Congress back in 2014 in Detroit. I had a number of meetings with Honda on their prototypes. They were using a Nexus phone that Qualcomm had hacked the 11a radio to work for 11p. CAMP may have some internal documents. I can probably reach out to the Honda people after the 802 meeting if no one else here can point to any published work. On 07/21/2016 01:50 PM, Jong-Hyouk Lee wrote: > Thx for arising a V2P scenario. If possible, can you give the pointer? > -- > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > Protocol Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com > #webpage: https://sites.google.com/site/hurryon > >> On Jul 21, 2016, at 8:47 PM, Robert Moskowitz >> > wrote: >> >> It was submitted to the CAMP pilot RFI. I wrote it with Robert >> Hopley over at Verizon, remember him? >> >> >> It was a very similar PKI, but turned a lot of pieces around to work >> with phones as clients. The RFI said it was open to other proposals, >> they responded to Verizon that they really did not want any other >> approaches. >> >> >> I do not have it. Contact Hopley at Verizon and perhaps he can get >> it to you. >> >> >> On 07/21/2016 01:42 PM, William Whyte wrote: >>> Hi Bob, >>> >>> Who did Verizon submit that "counter proposal" to and is it >>> available publicly? I don't remember seeing a specific proposal in >>> the 1609 working group, or, to be honest, anywhere. >>> >>> Cheers, >>> >>> William >>> >>> >>> On Thu, Jul 21, 2016 at 7:26 AM, Robert Moskowitz >>> > wrote: >>> >>> I have seen a number of DSRC/WAVE demonstrations with cell >>> phones being part of the network for pedestrians and bicycles. >>> Honda also showed it for motorcycles, but future motorcycles can >>> have an embedded DSRC device connected to the bike's CANbus for >>> better information. >>> >>> >>> The concern here is that DSRC is already quite congested in many >>> areas where there are pedestrians and in places near >>> mass-transit access, and pdestrians walking all over the place, >>> how could a car listen to all the phones chirping away? >>> >>> >>> Add to this the regulatory challenge of yet another radio on the >>> phones. Qualcomm has demonstrated a duo radio with standard >>> WiFi and DSRC, but many just change the radio, switch from the >>> WiFi bands to the 11p bands and switch back and that has serious >>> performance concerns. >>> >>> >>> So let's keep the phones on IP and route the WAVE messages over >>> IP to/from the phones. This would use Infrastructure components >>> like traffic lights as the relays. >>> >>> >>> There is the security question in that is the 1609.2 certificate >>> that of the phone's or the infrastructure piece? In the former >>> case, the PKI proposal from CAMP would have major challenges >>> scaling that large. Of course the counter proposal Verizon >>> submitted ;) could scale up to certs for all the phones. If >>> the signing is done by the infrastructure cert which is not a >>> anonymous cert (like in the vehicles), does this present any >>> privacy issues for the phone holder? Probably not. >>> >>> >>> But a real potential use case. >>> >>> >>> Bob Moskowitz >>> >>> >>> _______________________________________________ >>> 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 --------------67B59E7C01E4DEF1CB2BBCF2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Much of it was at ITS World Congress back in 2014 in Detroit.  I had a number of meetings with Honda on their prototypes.   They were using a Nexus phone that Qualcomm had hacked the 11a radio to work for 11p.


CAMP may have some internal documents.  I can probably reach out to the Honda people after the 802 meeting if no one else here can point to any published work.


On 07/21/2016 01:50 PM, Jong-Hyouk Lee wrote:
Thx for arising a V2P scenario. If possible, can you give the pointer? 
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Jul 21, 2016, at 8:47 PM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:

It was submitted to the CAMP pilot RFI.  I wrote it with Robert Hopley over at Verizon, remember him?


It was a very similar PKI, but turned a lot of pieces around to work with phones as clients.  The RFI said it was open to other proposals, they responded to Verizon that they really did not want any other approaches.


I do not have it.  Contact Hopley at Verizon and perhaps he can get it to you.


On 07/21/2016 01:42 PM, William Whyte wrote:
Hi Bob,

Who did Verizon submit that "counter proposal" to and is it available publicly? I don't remember seeing a specific proposal in the 1609 working group, or, to be honest, anywhere.

Cheers,

William


On Thu, Jul 21, 2016 at 7:26 AM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
I have seen a number of DSRC/WAVE demonstrations with cell phones being part of the network for pedestrians and bicycles.  Honda also showed it for motorcycles, but future motorcycles can have an embedded DSRC device connected to the bike's CANbus for better information.


The concern here is that DSRC is already quite congested in many areas where there are pedestrians and in places near mass-transit access, and pdestrians walking all over the place, how could a car listen to all the phones chirping away?


Add to this the regulatory challenge of yet another radio on the phones.  Qualcomm has demonstrated a duo radio with standard WiFi and DSRC, but many just change the radio, switch from the WiFi bands to the 11p bands and switch back and that has serious performance concerns.


So let's keep the phones on IP and route the WAVE messages over IP to/from the phones.  This would use Infrastructure components like traffic lights as the relays.


There is the security question in that is the 1609.2 certificate that of the phone's or the infrastructure piece?  In the former case, the PKI proposal from CAMP would have major challenges scaling that large.  Of course the counter proposal Verizon submitted ;) could scale up to certs for all the phones.   If the signing is done by the infrastructure cert which is not a anonymous cert (like in the vehicles), does this present any privacy issues for the phone holder?  Probably not.


But a real potential use case.


Bob Moskowitz


_______________________________________________
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

--------------67B59E7C01E4DEF1CB2BBCF2-- From nobody Thu Jul 21 08:31: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 D78DA12D75B for ; Thu, 21 Jul 2016 08:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.007 X-Spam-Level: X-Spam-Status: No, score=-4.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJo7KDTbxGl2 for ; Thu, 21 Jul 2016 08:30:32 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4AB12D69A for ; Thu, 21 Jul 2016 08:30:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mWd7yLbSRyVDmCdd+iVWwuX+vFGU9AW/wfD0TvAwKpbKI/AtgMuq00he2y8vJICY; h=Received:To:Cc:From:Subject:Message-ID:Date:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.162.109] by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1bQFvb-0006ZF-Bt; Thu, 21 Jul 2016 11:30:23 -0400 To: Dino Farinacci From: Charlie Perkins Message-ID: <20b12908-0b5f-dac3-c728-8fc490f101cc@earthlink.net> Date: Thu, 21 Jul 2016 08:30:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7222379dd3622786dc8b0d4fe07b9df73350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.162.109 Archived-At: Cc: its@ietf.org Subject: [its] Comments about Mobile IP X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:30:34 -0000 X-List-Received-Date: Thu, 21 Jul 2016 15:30:34 -0000 Hello Dino and all, I wanted to mention that Fast Mobile IP does a pretty good job of not losing packets. Plus there has been a lot of work in SDOs that I am familiar with (3GPP, IEEE, IETF) for fast handovers. The technique of geocasting duplicates to neighboring road-side stations is related to quite many published approaches using bicasting and multicasting. This amounts to a tradeoff between contol signaling versus data duplication. Data duplication is probably more likely to increase interference during traffic jams or (worse) emergency situations. Treating roadway mobility management by "one-dimensional" routing protocols is also a cool idea that has received attention at various vehicular networking conferences. Multi-lane roadways and intersections have interesting implications on such related approaches. Also, I reckon we ought to consider multi-radio vehicles. Predictive approaches have been thoroughly explored and can be surprisingly effective. Surprisingly good, but not good enough to avoid frequent annoyance. I reckon they have a very good place as part of a hybrid approach -- but then we have more complicated signaling. But more signaling is good if it produces smoother handovers. I think it would be very interesting to explore a mutually constructive approach with Mobile IP and LISP, especially adapting the ideas of Fast Mobile IP as mentioned above. Some of the current approaches for distributed anchoring as discussed in [dmm] may also find beneficial application. Regards, Charlie P. From nobody Thu Jul 21 08:38:34 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B3D12D69C for ; Thu, 21 Jul 2016 08:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 Dwj7hpx-rdJk for ; Thu, 21 Jul 2016 08:38:30 -0700 (PDT) Received: from ndmsvnpf104.ndc.nasa.gov (NDMSVNPF104.ndc.nasa.gov [198.117.0.154]) by ietfa.amsl.com (Postfix) with ESMTP id 03CB112D520 for ; Thu, 21 Jul 2016 08:38:30 -0700 (PDT) Received: from ndjsppt103.ndc.nasa.gov (ndjsppt103.ndc.nasa.gov [198.117.1.197]) by ndmsvnpf104.ndc.nasa.gov (Postfix) with ESMTP id 406DB400532F; Thu, 21 Jul 2016 10:38:29 -0500 (CDT) Received: from NDJSCHT107.ndc.nasa.gov (ndjscht107-pub.ndc.nasa.gov [198.117.1.207]) by ndjsppt103.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id u6LFcSMt027076; Thu, 21 Jul 2016 10:38:28 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.200]) by NDJSCHT107.ndc.nasa.gov ([198.117.1.207]) with mapi id 14.03.0294.000; Thu, 21 Jul 2016 10:38:28 -0500 From: "Ivancic, William D. (GRC-LCA0)" To: Charlie Perkins , Dino Farinacci Thread-Topic: [its] Comments about Mobile IP Thread-Index: AQHR42TcqN+2iEq2R0CC9hv/oRj/m6AjFv+A Date: Thu, 21 Jul 2016 15:38:28 +0000 Message-ID: References: <20b12908-0b5f-dac3-c728-8fc490f101cc@earthlink.net> In-Reply-To: <20b12908-0b5f-dac3-c728-8fc490f101cc@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [139.88.111.195] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-21_07:, , signatures=0 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] Comments about Mobile IP X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:38:33 -0000 ICN techniques may eventually be a good fit due to sort of built-in multicast or local broadcast as well as multi-homed radio systems. Depending on the radio system, local broadcast is a natural. LTE, not so much. Will On 7/21/16, 11:30 AM, "its on behalf of Charlie Perkins" wrote: >Hello Dino and all, > >I wanted to mention that Fast Mobile IP does a pretty good job of not >losing packets. Plus there has been a lot of work in SDOs that I am >familiar with (3GPP, IEEE, IETF) for fast handovers. The technique of >geocasting duplicates to neighboring road-side stations is related to >quite many published approaches using bicasting and multicasting. This >amounts to a tradeoff between contol signaling versus data duplication. >Data duplication is probably more likely to increase interference during >traffic jams or (worse) emergency situations. > >Treating roadway mobility management by "one-dimensional" routing >protocols is also a cool idea that has received attention at various >vehicular networking conferences. Multi-lane roadways and intersections >have interesting implications on such related approaches. Also, I >reckon we ought to consider multi-radio vehicles. > >Predictive approaches have been thoroughly explored and can be >surprisingly effective. Surprisingly good, but not good enough to avoid >frequent annoyance. I reckon they have a very good place as part of a >hybrid approach -- but then we have more complicated signaling. But >more signaling is good if it produces smoother handovers. > >I think it would be very interesting to explore a mutually constructive >approach with Mobile IP and LISP, especially adapting the ideas of Fast >Mobile IP as mentioned above. Some of the current approaches for >distributed anchoring as discussed in [dmm] may also find beneficial >application. > >Regards, >Charlie P. > > > >_______________________________________________ >its mailing list >its@ietf.org >https://www.ietf.org/mailman/listinfo/its From nobody Thu Jul 21 15:51:56 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2E712DA2D for ; Thu, 21 Jul 2016 15:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1uFvQdBPv5P for ; Thu, 21 Jul 2016 15:51:53 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2059E12DA17 for ; Thu, 21 Jul 2016 15:51:53 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id p74so87417402qka.0 for ; Thu, 21 Jul 2016 15:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uFUnOgnTE0NM0W+YPIIU77zrCMGqigDSAZhubZEJV6U=; b=wK7KCBbwy/Znwa0hhd28kD8yD9g2MbfYHCn+BNuZFzLFX1XW+KZlUNiA1El47Uulnb dmQyWHIZ6s3Xo5hXjw6KSuIv86Fh1BWLJTSdfi+EMNxDKT5P5QIrGbsdVr4NBL006bNc 4Gyh6ll420VvApudk5HV1sO69WAnxxluwCR+4WTyD9C9LcM4wN3TDLbh4ZlwHoUeUwVu 0Vek1AQtLoTkPpST1NIJ2tKwqVcmFD8pC6YxAvYKj6ESPNplzloNtXt/cDidaadeKUP1 8saretFTfMaLYVSakPABUBQyfH+yCleqgnDZtU2H8y6ns5ifB5T8XAllBPSVmjvdWrsE hayw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uFUnOgnTE0NM0W+YPIIU77zrCMGqigDSAZhubZEJV6U=; b=fgoC6ra7x9F96b0qDg0KH8ECG+bSmE67cgu5PffzfucXzoVrQt4dfzp4Z8MbZ3UVnh i4TbqyiUlI7yLDSQBe5ILcj+HpJEw2/ViaeSaalTuuBvWO+ZmesOv/kHTLebR0cBV7km xID+GtFy9aBOXb6NA5uAD/b1XHPvBX4arBI9OlN84sW845MnnvjLxjkMPcBBT1bo0Fq0 Xh0BuAV8ROT7QnRjU/lV7hFxgscuzpF24eVWGoG2KZyXiZrwTO/QryOXNNapcVlKRmen VPpbaP4bQMdaUM5VssGo+AtX1McCOq6DHlgVFOi4D1GnBmD8ixJRjS17GU8aPtfBPY2/ VOkg== X-Gm-Message-State: AEkoouv/CxgO/YKnyW67GQCq4E9+q07yZhcyskjwc6nWtW+NhFjsvnXu6L73JAIedtcxHw== X-Received: by 10.55.135.194 with SMTP id j185mr925316qkd.105.1469141512235; Thu, 21 Jul 2016 15:51:52 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:249d:d110:d33:c2bc? ([2001:67c:370:136:249d:d110:d33:c2bc]) by smtp.gmail.com with ESMTPSA id l22sm5630193qtl.34.2016.07.21.15.51.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 15:51:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <20b12908-0b5f-dac3-c728-8fc490f101cc@earthlink.net> Date: Thu, 21 Jul 2016 15:51:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2A63DE4D-B149-4B5A-B01E-CBE582613C3C@gmail.com> References: <20b12908-0b5f-dac3-c728-8fc490f101cc@earthlink.net> To: Charlie Perkins X-Mailer: Apple Mail (2.3124) Archived-At: Cc: its@ietf.org Subject: Re: [its] Comments about Mobile IP X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 22:51:55 -0000 > I wanted to mention that Fast Mobile IP does a pretty good job of not = losing packets. Plus there has been a lot of work in SDOs that I am = familiar with (3GPP, IEEE, IETF) for fast handovers. The technique of = geocasting duplicates to neighboring road-side stations is related to = quite many published approaches using bicasting and multicasting. This = amounts to a tradeoff between contol signaling versus data duplication. = Data duplication is probably more likely to increase interference during = traffic jams or (worse) emergency situations. Thanks for the reference Charlie. Glad to know our approach is not new. Has these approaches optimized the routing system at the same as = providing multi-homing (not just multi-homing to the hand-sets but to = the RSUs)? > Treating roadway mobility management by "one-dimensional" routing = protocols is also a cool idea that has received attention at various = vehicular networking conferences. Multi-lane roadways and intersections = have interesting implications on such related approaches. Also, I = reckon we ought to consider multi-radio vehicles. Maybe, but that makes the problem more complicated. That is, if you = don=E2=80=99t want duplicates to go to the end-system. > Predictive approaches have been thoroughly explored and can be = surprisingly effective. Surprisingly good, but not good enough to avoid = frequent annoyance. I reckon they have a very good place as part of=20 What is the frequent annoyance? Can you explain in detail? > a hybrid approach -- but then we have more complicated signaling. But = more signaling is good if it produces smoother handovers. I think background signaling is fine, if needed, but as long as it is in = the background and doesn=E2=80=99t have a fast handoff time budget. > I think it would be very interesting to explore a mutually = constructive approach with Mobile IP and LISP, especially adapting the = ideas of Fast Mobile IP as mentioned above. Some of the current = approaches for distributed anchoring as discussed in [dmm] may also find = beneficial application. Sure, I think LISP can bring a scalable mapping database control plane = to the table and a core route reduction benefit with an overlay. How = would you complement this with Mobile-IP? > Regards, > Charlie P. Thanks for the email. Dino From nobody Thu Jul 21 16:32: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 E1AE412DA9C; Thu, 21 Jul 2016 16:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 91dz7TskCfAt; Thu, 21 Jul 2016 16:32:21 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 5D06212DA9E; Thu, 21 Jul 2016 16:32:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,401,1464645600"; d="xml'217?scan'217,208,217";a="185562424" Received: from mail-lf0-f46.google.com ([209.85.215.46]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 22 Jul 2016 01:32:16 +0200 Received: by mail-lf0-f46.google.com with SMTP id l69so73239175lfg.1; Thu, 21 Jul 2016 16:32:16 -0700 (PDT) X-Gm-Message-State: AEkoousbHOxyxYu9BgCO2VTBTmsFhA8RnPIkw6pfGuwS9Seh+uQOSCPH/gsNNShFZ9qsetzOdwlTX9MTpMKqeQ== X-Received: by 10.25.37.208 with SMTP id l199mr576711lfl.41.1469143935971; Thu, 21 Jul 2016 16:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.146.84 with HTTP; Thu, 21 Jul 2016 16:31:56 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Fri, 22 Jul 2016 01:31:56 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Suresh Krishnan Content-Type: multipart/mixed; boundary=001a11410ed46d946b05382dba70 Archived-At: Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [its] [IoT-DIR] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 23:32:25 -0000 --001a11410ed46d946b05382dba70 Content-Type: multipart/alternative; boundary=001a11410ed46d946505382dba6e --001a11410ed46d946505382dba6e Content-Type: text/plain; charset=UTF-8 Suresh, I strongly support the publication of this document. Since it defines a mechanism which can be used by several working groups, AD sponsoring seems perfect. I'm attaching the XML of the the -02 version of that draft in which I have corrected some typos. I'll let Tero and Pat decide what he wants to merge, if anything. These changes are for the authors' information only, they do NOT affect my support to publish this document. Thomas On Mon, Jul 18, 2016 at 2:39 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi all, > I am considering AD sponsoring the following draft > > https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 > > to request the allocation of an 802.15.4 information element from the IEEE > for use in the IETF protocols that may need it. If you have any concerns > either with the content of the draft or about requesting the IE at all > please > let me know before 2016/07/29. > > Thanks > Suresh > > NOTE: I have CCed: all the groups that I thought could be potentially > interested in this work. If you think I have missed out some WG(s) please > let > me know. > > _______________________________________________ > IoT-DIR mailing list > IoT-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/iot-dir > --001a11410ed46d946505382dba6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Suresh,

I strongly support the publicat= ion of this document. Since it defines a mechanism which can be used by sev= eral working groups, AD sponsoring seems perfect.

= I'm attaching the XML of the the -02 version of that draft in which I h= ave corrected some typos. I'll let Tero and Pat decide what he wants to= merge, if anything. These changes are for the authors' information onl= y, they do NOT affect my support to publish this document.

Thomas

On Mon, Jul 18, 2016 at 2:39 PM, Suresh Krishnan <= suresh.kr= ishnan@ericsson.com> wrote:
Hi all,
=C2=A0 =C2=A0I am considering AD sponsoring the following draft

https://tools.ietf.org/html/draft-kivinen-802-= 15-ie-02

to request the allocation of an 802.15.4 information element from the IEEE<= br> for use in the IETF protocols that may need it. If you have any concerns either with the content of the draft or about requesting the IE at all plea= se
let me know before 2016/07/29.

Thanks
Suresh

NOTE: I have CCed: all the groups that I thought could be potentially
interested in this work. If you think I have missed out some WG(s) please l= et
me know.

_______________________________________________
IoT-DIR mailing list
IoT-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/iot-dir

--001a11410ed46d946505382dba6e-- --001a11410ed46d946b05382dba70 Content-Type: text/xml; charset=US-ASCII; name="draft-kivinen-802-15-ie-02_tw.xml" Content-Disposition: attachment; filename="draft-kivinen-802-15-ie-02_tw.xml" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iqwy8jug0 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBFIHJmYyBTWVNU RU0gInJmYzI2MjkuZHRkIiBbCiAgICA8IUVOVElUWSByZmMyMTE5IFBVQkxJQyAnJyAKICAgICAg J2h0dHA6Ly94bWwycmZjLmlldGYub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMu MjExOS54bWwnPgpdPgoKPHJmYyBjYXRlZ29yeT0nc3RkJyBpcHI9J3RydXN0MjAwOTAyJwogICAg IGRvY05hbWU9J2RyYWZ0LWtpdmluZW4tODAyLTE1LWllLTAyLnR4dCc+Cgo8P3htbC1zdHlsZXNo ZWV0IHR5cGU9J3RleHQveHNsJyBocmVmPSdyZmMyNjI5LnhzbHQnID8+Cgo8P3JmYyB0b2M9J3ll cycgPz4KPD9yZmMgc3ltcmVmcz0neWVzJyA/Pgo8P3JmYyBzb3J0cmVmcz0neWVzJz8+Cjw/cmZj IGlwcm5vdGlmaWVkPSdubycgPz4KPD9yZmMgY29tcGFjdD0neWVzJyA/Pgo8P3JmYyBzdHJpY3Q9 J3llcycgPz4KCjxmcm9udD4KICA8dGl0bGU+SUVFRSA4MDIuMTUuNCBJbmZvcm1hdGlvbiBFbGVt ZW50IGZvciBJRVRGPC90aXRsZT4KICAgICAgICAKICA8YXV0aG9yIGluaXRpYWxzPSdULicgc3Vy bmFtZT0nS2l2aW5lbicgZnVsbG5hbWU9J1Rlcm8gS2l2aW5lbic+CiAgICA8b3JnYW5pemF0aW9u PklOU0lERSBTZWN1cmU8L29yZ2FuaXphdGlvbj4KICAgIDxhZGRyZXNzPgogICAgICA8cG9zdGFs PgogICAgICAgIDxzdHJlZXQ+RWVyaWtpbmthdHUgMjg8L3N0cmVldD4KICAgICAgICA8Y29kZT5G SS0wMDE4MDwvY29kZT4KICAgICAgICA8Y2l0eT5IRUxTSU5LSTwvY2l0eT4KICAgICAgICA8Y291 bnRyeT5GSTwvY291bnRyeT4KICAgICAgPC9wb3N0YWw+CiAgICAgIDxlbWFpbD5raXZpbmVuQGlr aS5maTwvZW1haWw+CiAgICA8L2FkZHJlc3M+CiAgPC9hdXRob3I+CiAgPGF1dGhvciBmdWxsbmFt ZT0iUGF0IEtpbm5leSIgaW5pdGlhbHM9IlAuIiBzdXJuYW1lPSJLaW5uZXkiPgogICAgPG9yZ2Fu aXphdGlvbj5LaW5uZXkgQ29uc3VsdGluZyBMTEM8L29yZ2FuaXphdGlvbj4KICAgIDxhZGRyZXNz PgogICAgICA8cG9zdGFsPgoJPHN0cmVldC8+Cgk8Y2l0eS8+Cgk8cmVnaW9uLz4KCTxjb2RlLz4K CTxjb3VudHJ5Lz4KICAgICAgPC9wb3N0YWw+CiAgICAgIDxlbWFpbD5wYXQua2lubmV5QGtpbm5l eWNvbnN1bHRpbmdsbGMuY29tPC9lbWFpbD4KICAgIDwvYWRkcmVzcz4KICA8L2F1dGhvcj4KICA8 ZGF0ZSB5ZWFyPScyMDE2JyAvPgogIDxhcmVhPkludGVybmV0PC9hcmVhPgogIDxhYnN0cmFjdD4K ICAgIDx0PklFRUUgU3RkIDgwMi4xNS40IGhhcyBJbmZvcm1hdGlvbiBFbGVtZW50cyAoSUUpIHRo YXQgY2FuIGJlCiAgICB1c2VkIHRvIGV4dGVuZCA4MDIuMTUuNCBpbiBhbiBpbnRlcm9wZXJhYmxl IG1hbm5lci4gVGhlIElFRUUgODAyLjE1CiAgICBBc3NpZ25lZCBOdW1iZXJzIEF1dGhvcml0eSAo QU5BKSBtYW5hZ2VzIHRoZSByZWdpc3RyeSBvZiB0aGUKICAgIEluZm9ybWF0aW9uIEVsZW1lbnRz LCBhbmQgdGhpcyBkb2N1bWVudCByZXF1ZXN0cyBBTkEgdG8gYWxsb2NhdGUgYQogICAgbnVtYmVy IGZvciB0aGUgSUVURiwgYW5kIHByb3ZpZGVzIGluZm9ybWF0aW9uIG9uIGhvdyB0aGUgSUUgaXMK ICAgIGZvcm1hdHRlZCB0byBwcm92aWRlIHN1YiB0eXBlcy48L3Q+CiAgPC9hYnN0cmFjdD4KPC9m cm9udD4KCjxtaWRkbGU+CiAgPHNlY3Rpb24gdGl0bGU9J0ludHJvZHVjdGlvbic+CiAgICA8dD5J RUVFIFN0ZC4gODAyLjE1LjQgPHhyZWYgdGFyZ2V0PSJJRUVFLTgwMi0xNS00IiAvPiBoYXMKICAg IEluZm9ybWF0aW9uIEVsZW1lbnRzIChJRSkgdGhhdCBjYW4gYmUgdXNlZCB0byBleHRlbmQgODAy LjE1LjQgaW4gYW4gaW50ZXJvcGVyYWJsZSBtYW5uZXIuCiAgICBUaGVyZSBhcmUgdHdvIGRpZmZl cmVudCBJRQogICAgdHlwZXMsIEhlYWRlciBJRSBhbmQgUGF5bG9hZCBJRS4gVGhlIEhlYWRlciBJ RXMgYXJlIHBhcnQgb2YgdGhlCiAgICBNZWRpdW0gQWNjZXNzIENvbnRyb2wgKE1BQykgaGVhZGVy LCBhbmQgYXJlIG5ldmVyIGVuY3J5cHRlZCwKICAgIGJ1dCB0aGV5IG1heSBiZSBhdXRoZW50aWNh dGVkLiBNb3N0IG9mIHRoZSBIZWFkZXIgSUUgcHJvY2Vzc2luZyBpcwogICAgZG9uZSBieSB0aGUg TUFDLCBhbmQgSUVURiBwcm90b2NvbHMgc2hvdWxkIG5vdCBuZWVkIHRvIGV4dGVuZAogICAgdGhl bS4gVGhlIFBheWxvYWQgSUVzIGFyZSBwYXJ0IG9mIHRoZSBNQUMgcGF5bG9hZCBhbmQgdGhleQog ICAgbWF5IGJlIGVuY3J5cHRlZCBhbmQgYXV0aGVudGljYXRlZC48L3Q+CgogICAgPHQ+SUVURiBw cm90b2NvbHMgd2lsbCBuZWVkIHRvIGluY2x1ZGUgaW5mb3JtYXRpb24gaW4gdGhlIDgwMi4xNS40 CiAgICBmcmFtZXM7IHRoZSBzdGFuZGFyZCA4MDIuMTUuNCB3YXkgb2YgZG9pbmcgdGhpcyBpcyB0 byBpbmNsdWRlCiAgICBvbmUgb2YgbW9yZSBwYXlsb2FkIElFcyBpbiB0aGUgZnJhbWUgdGhhdCB3 aWxsIGNvbnRhaW4gdGhlIGluZm9ybWF0aW9uLiBCZWNhdXNlCiAgICBvZiB0aGlzLCB0aGUgSUVU RiBuZWVkcyB0byBvYnRhaW4gYSBkZWRpY2F0ZWQgUGF5bG9hZCBJRSBmcm9tIHRoZSBJRUVFCiAg ICA4MDIuMTUgQXNzaWduZWQgTnVtYmVycyBBdXRob3JpdHkgKEFOQSkgPHhyZWYKICAgIHRhcmdl dD0nSUVFRS04MDItMTUtQU5BJyAvPi4gVGhlIHVwLXRvLWRhdGUgODAyLjE1IEFOQSBkYXRhYmFz ZQogICAgY2FuIGJlIGZvdW5kIGF0IDx4cmVmIHRhcmdldD0nSUVFRS04MDItMTUtQU5BLURCJyAv Pi48L3Q+CgogICAgPHQ+VGhlIDgwMi4xNS40IG9wZXJhdGlvbnMgbWFudWFsIDx4cmVmIHRhcmdl dD0nSUVFRS04MDItMTUtT1BTJwogICAgLz4gcHJvdmlkZXMgaW5mb3JtYXRpb24gb24gaG93IGEg c3RhbmRhcmRpemF0aW9uIG9yZ2FuaXphdGlvbiBtYXkKICAgIHJlcXVlc3QgYW4gYWxsb2NhdGlv biBvZiBhbiBJRS4gVG8gbWFrZSB0aGlzIHJlcXVlc3QsCiAgICB0aGUgc3RhbmRhcmRpemF0aW9u IG9yZ2FuaXphdGlvbiBuZWVkcyB0bzogcHJvdmlkZSB0aGUgcmVhc29uIGZvcgogICAgdGhlIHJl cXVlc3Q7IGEgZGVzY3JpcHRpb24gb2YgdGhlIHByb3RvY29sIGZvcm1hdCB0aGF0IHNob3dzIHRo ZXJlCiAgICBpcyBzdWZmaWNpZW50IHN1YnR5cGUgY2FwYWJpbGl0eTsgYSBzdGF0ZW1lbnQgdGhh dCB0aGUgZXh0ZXJuYWwKICAgIG9yZ2FuaXphdGlvbiB1bmRlcnN0YW5kcyB0aGF0IG9ubHkgb25l IElEIG51bWJlciB3aWxsIGJlCiAgICBpc3N1ZWQuPC90PgoKICAgIDx0PlRoaXMgZG9jdW1lbnQg cHJvdmlkZXMgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCBmb3IgdGhlCiAgICByZXF1ZXN0LjwvdD4K CiAgIDwvc2VjdGlvbj4KCiAgIDxzZWN0aW9uIGFuY2hvcj0idGVybWlub2xvZ3kiIHRpdGxlPSJU ZXJtaW5vbG9neSI+CgogICAgPHQ+VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJS RVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTAogICAgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9U IiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiCiAgICBpbiB0aGlzIGRvY3Vt ZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gPHhyZWYKICAgIHRhcmdl dD0nUkZDMjExOScvPi48L3Q+CiAgPC9zZWN0aW9uPgoKICA8c2VjdGlvbiB0aXRsZT0iVXNlcnMg b2YgdGhlIElFVEYgSUUiIGFuY2hvcj0idXNlcnMiPgogICAgPHQ+VGhlcmUgYXJlIHNldmVyYWwg SUVURiB3b3JraW5nIGdyb3VwcyBzdWNoIGFzIDZUaVNDSCwgNmxvLCBDb1JFCiAgICBldGMsIHdo aWNoIGNvdWxkIGJlbmVmaXQgZnJvbSB0aGUgSUVURiBJRS4gVGhlIDZUaVNDSCB3b3JraW5nCiAg ICBncm91cCBoYXMgYWxyZWFkeSBleHByZXNzZWQgdGhlIG5lZWQgZm9yIHRoZSBJRSwgYW5kIHRo aXMKICAgIGFsbG9jYXRpb24gc2hvdWxkIHByb3ZpZGUgdGhlbSBhIHdheSBmb3J3YXJkLjwvdD4K ICA8L3NlY3Rpb24+CgogIDxzZWN0aW9uIHRpdGxlPSdJRVRGIElFIFN1YnR5cGUgRm9ybWF0JyBh bmNob3I9J2lldGYtaWUnPgoKICAgIDx0PlRoZSBtYXhpbXVtIGxlbmd0aCBvZiB0aGUgUGF5bG9h ZCBJRSBjb250ZW50IGlzIDIwNDcgb2N0ZXRzLAogICAgYW5kIDgwMi4xNS40IGZyYW1lIGNvbnRh aW5zIGEgbGlzdCBvZiBwYXlsb2FkIElFcywgaS5lLiBhIHNpbmdsZQogICAgZnJhbWUgY2FuIGhh dmUgbXVsdGlwbGUgcGF5bG9hZCBJRXMsIHRlcm1pbmF0ZWQgd2l0aCB0aGUgcGF5bG9hZAogICAg SUUgdGVybWluYXRvciwgYW5kIG1heSBiZSBmb2xsb3dlZCBieSB0aGUgcGF5bG9hZC48L3Q+Cgog ICAgPHQ+QmVjYXVzZSB0aGUgZnJhbWUgY29udGFpbnMgYSBsaXN0IG9mIHBheWxvYWRzLCB0aGVy ZSBpcyBubwogICAgbmVlZCB0byBwcm92aWRlIGludGVybmFsIHN0cnVjdHVyZSBpbnNpZGUgdGhl IElFVEYgSUUuIFRoZSBQYXlsb2FkCiAgICBJRSBmb3JtYXQgb2YgdGhlIDgwMi4xNS40IGNvbnRh aW5zIHRoZSBMZW5ndGggZmllbGQsIHNvIHRoZQogICAgbGVuZ3RoIG9mIHRoZSBTdWItVHlwZSBD b250ZW50IGNhbiBiZSBjYWxjdWxhdGVkIGZyb20gdGhlIExlbmd0aAogICAgZmllbGQgb2YgdGhl IElFVEYgSUUuPC90PgoKICAgIDx0PlRoZSBmb3JtYXQgb2YgdGhlIElFVEYgSUUgaXMgYXMgZm9s bG93czo8L3Q+CiAgICAKICAgIDxmaWd1cmUgYW5jaG9yPSJpZXRmLWllLWZpZ3VyZSIgdGl0bGU9 IklFVEYgSUUgU3VidHlwZSBGb3JtYXQiID48YXJ0d29yaz48IVtDREFUQVsKICAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKIDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwp8IFN1Yi1UeXBlIElEICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAorLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAp+ICAgICAgICAgICAgICAgICAgICAgICBTdWIt VHlwZSBDb250ZW50ICAgICAgICAgICAgICAgICAgICAgICAgfgp8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAorLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwpd XT48L2FydHdvcms+PC9maWd1cmU+CgogICAgPHQ+PGxpc3Qgc3R5bGU9InN5bWJvbHMiPgogICAg ICA8dD5TdWItVHlwZSBJRCBpcyB0aGUgSUFOQSBhbGxvY2F0ZWQgbnVtYmVyIHNwZWNpZnlpbmcg dGhlCiAgICAgIHN1Yi10eXBlIG9mIHRoZSBJRVRGIElFLiBWYWx1ZSAwIGlzIHJlc2VydmVkIGZv ciBmdXR1cmUKICAgICAgZXh0ZW5zaWJpbGl0eSwgaS5lLiwgaW4gY2FzZSBhIGxvbmdlciBTdWIt VHlwZSBJRCBmaWVsZCBpcwogICAgICBuZWVkZWQuPC90PgoKICAgICAgPHQ+U3ViLVR5cGUgQ29u dGVudCBpcyB0aGUgYWN0dWFsIGNvbnRlbnQgb2YgdGhlIGluZm9ybWF0aW9uCiAgICAgIGVsZW1l bnQsIGFuZCBpdHMgbGVuZ3RoIGNhbiBiZSBjYWxjdWxhdGVkIGZyb20gdGhlIExlbmd0aCBmaWVs ZAogICAgICBvZiB0aGUgSUVURiBJRS4gPC90PgogICAgPC9saXN0PjwvdD4KCiAgICA8dD5PbmUg SUVFRSA4MDIuMTUuNCBmcmFtZSBjYW4gY29udGFpbiBtdWx0aXBsZSBJRVRGIElFcyB3aXRoIHRo ZSBzYW1lCiAgICBvciBkaWZmZXJlbnQgc3ViIHR5cGVzLjwvdD4KICAgIAogIDwvc2VjdGlvbj4K CiAgPHNlY3Rpb24gdGl0bGU9IlZlbmRvciBTcGVjaWZpYyBJRSI+CgogICAgPHQ+SUVFRSA4MDIu MTUuNCBoYXMgYWxyZWFkeSBzZXZlcmFsIG51bWJlcnMgZm9yIGRpZmZlcmVudCBWZW5kb3IKICAg IFNwZWNpZmljIElFIHR5cGVzLiBUaGVyZSBpcyBvbmUgZm9yIHRoZSBWZW5kb3IgU3BlY2lmaWMg SGVhZGVyIElFCiAgICBmb3IgSGVhZGVyIElFcy4gVGhlcmUgaXMgb25lIGluY29ycmVjdGx5IG5h bWVkIFZlbmRvciBTcGVjaWZpYwogICAgTmVzdGVkIElFIGZvciBQYXlsb2FkIElFcywgYW5kIHRo ZXJlIGlzIGFub3RoZXIgb25lIHdpdGgKICAgIGV4YWN0bHkgdGhlIHNhbWUgbmFtZSwgYnV0IHVu ZGVyIHRoZSBNTE1FIE5lc3RlZCBJRSBsb25nIGZvcm1hdC4gQWxsCiAgICBvZiB0aGUgVmVuZG9y IFNwZWNpZmljIElFcyBzdGFydCB3aXRoIGEgMy1vY3RldCB2ZW5kb3IgT1VJIHRvCiAgICBpZGVu dGlmeSB0aGUgb3JnYW5pemF0aW9uLjwvdD4KCiAgICA8dD5CZWNhdXNlIG9mIHRoaXMsIHRoZXJl IGlzIG5vIG5lZWQgdG8gcmVzZXJ2ZSB0aGUgc3BlY2lmaWMKICAgIFN1Yi1UeXBlIElEcyBmb3Ig dGhlIHZlbmRvci1zcGVjaWZpYyB1c2VzLCBhcyB0aG9zZSBvdGhlciBJRSB0eXBlcwogICAgY2Fu IGJlIHVzZWQgZm9yIHRoYXQuPC90PgoKICA8L3NlY3Rpb24+CgogIDxzZWN0aW9uIHRpdGxlPSJS ZXF1ZXN0IHRvIGFsbG9jYXRlIElFVEYgSUUiPgogICAgPHQ+SUVURiB3b3VsZCByZXF1ZXN0IHRo ZSA4MDIuMTUuNCBXb3JraW5nIEdyb3VwIHRvIGFsbG9jYXRlIGEKICAgIFBheWxvYWQgSUUgZm9y IElFVEYgdXNlLiBGdXJ0aGVybW9yZSBJRVRGIHVuZGVyc3RhbmRzIHRoYXQgb25seQogICAgb25l IElEIHdpbGwgYmUgaXNzdWVkIHRvIGl0LjwvdD4KICA8L3NlY3Rpb24+CgogIDxzZWN0aW9uIHRp dGxlPSdTZWN1cml0eSBDb25zaWRlcmF0aW9ucyc+CgogICAgPHQ+VGhpcyBkb2N1bWVudCBjcmVh dGVzIGFuIElBTkEgcmVnaXN0cnkgZm9yIElFVEYgSUUgU3ViLXR5cGUKICAgIElEcywgYW5kIHRo ZSBzZWN1cml0eSBvZiB0aGUgcHJvdG9jb2xzIHVzaW5nIHRoZSBJRXMgbmVlZHMgdG8gYmUKICAg IGRlc2NyaWJlZCBpbiB0aGUgYWN0dWFsIGRvY3VtZW50cyBhbGxvY2F0aW5nIHZhbHVlcyBmcm9t IHRoaXMKICAgIHJlZ2lzdHJ5LjwvdD4KCiAgICA8dD5UaGUgSUVFRSBTdGQgODAyLjE1LjQtMjAx NSA8eHJlZiB0YXJnZXQ9IklFRUUtODAyLTE1LTQiIC8+CiAgICBjb250YWlucyBtZXRob2RzIHdo ZXJlIHNlY3VyaXR5IG9mIHRoZSBJRSBjYW4gYmUgZW5mb3JjZWQgd2hlbiBhCiAgICBmcmFtZSBp cyByZWNlaXZlZCwgYnV0IHRoaXMgaXMgb25seSBwZXIgSUUgdHlwZSwgdGh1cyBhbGwgSUVURiBJ RXMKICAgIHdpbGwgaGF2ZSBzYW1lIHNlY3VyaXR5IGxldmVsIHJlcXVpcmVtZW50cyByZWdhcmRs ZXNzIG9mIHRoZQogICAgU3ViLVR5cGUgSUQgdXNlZC4gVGhpcyBjYW4gY2F1c2UgaXNzdWVzIGlm IGRpZmZlcmVudCBzZWN1cml0eQogICAgcHJvY2Vzc2luZyB3b3VsZCBiZSBuZWVkZWQgYW5kIGFu eSBvZiB0aG9zZSBJRXMgd291bGQgbmVlZCB0byBiZQogICAgcHJvY2Vzc2VkIGluIHRoZSBNQUMg bGV2ZWwuIEZvcnR1bmF0ZWx5LCBldmVyeXRoaW5nIElFVEYgZG9lcwogICAgc2hvdWxkIGJlIGlu IGEgaGlnaGVyIGxldmVsIHRoYW4gdGhlIE1BQyBsZXZlbCwgdGh1cyB0aGUgaGlnaGVyCiAgICBs YXllciBwcm9jZXNzaW5nIGZvciB0aGVzZSBJRXMgbmVlZHMgdG8gcGVyZm9ybSBzZXBhcmF0ZSBz ZWN1cml0eQogICAgcG9saWN5IGNoZWNraW5nIGJhc2VkIG9uIHRoZSBJRVRGIElFIFN1Yi1UeXBl IElEIGluIGFkZGl0aW9uIHRvCiAgICB0aGUgY2hlY2tzIGRvbmUgYnkgdGhlIE1BQy48L3Q+Cgog IDwvc2VjdGlvbj4KICAKICA8c2VjdGlvbiB0aXRsZT0nSUFOQSBDb25zaWRlcmF0aW9ucycgYW5j aG9yPSdpYW5hJz4KCiAgICA8dD5UaGlzIGRvY3VtZW50IGNyZWF0ZXMgYSBuZXcgcmVnaXN0cnkg Zm9yIElFVEYgSUUgU3ViLXR5cGUgSURzCiAgICByZWdpc3RyeTo8L3Q+CgogICAgPGZpZ3VyZT48 YXJ0d29yaz48IVtDREFUQVsKVmFsdWUgICAgIFN1Yi10eXBlIElECjAgICAgICAgICBSZXNlcnZl ZAoxLTIwMCAgICAgVW5hc3NpZ25lZAoyMDEtMjU1ICAgRXhwZXJpbWVudGFsIFVzZQpdXT48L2Fy dHdvcms+PC9maWd1cmU+CgogICAgPHQ+Q2hhbmdlcyBhbmQgYWRkaXRpb25zIHRvIHRoaXMgcmVn aXN0cnkgaXMgYnkgZXhwZXJ0IHJldmlldy48L3Q+CiAgICAgICAKICA8L3NlY3Rpb24+Cgo8L21p ZGRsZT4KPGJhY2s+CgogIDxyZWZlcmVuY2VzIHRpdGxlPSJOb3JtYXRpdmUgUmVmZXJlbmNlcyI+ CiAgICAmcmZjMjExOTsKICA8L3JlZmVyZW5jZXM+CgogIDxyZWZlcmVuY2VzIHRpdGxlPSdJbmZv cm1hdGl2ZSBSZWZlcmVuY2VzJz4KICAgIDxyZWZlcmVuY2UgYW5jaG9yPSdJRUVFLTgwMi0xNS00 Jz4KICAgICAgPGZyb250PgogICAgICAgIDx0aXRsZT5JRUVFIFN0YW5kYXJkIGZvciBMb3ctUmF0 ZSBXaXJlbGVzcyBQZXJzb25hbCBBcmVhCiAgICAgICAgTmV0d29ya3MgKFdQQU5zKTwvdGl0bGU+ Cgk8YXV0aG9yPjwvYXV0aG9yPgogICAgICAgIDxkYXRlIHllYXI9JzIwMTUnLz4KICAgICAgPC9m cm9udD4KICAgICAgPHNlcmllc0luZm8gbmFtZT0iSUVFRSIgdmFsdWU9IlN0YW5kYXJkIDgwMi4x NS40IiAvPgogICAgPC9yZWZlcmVuY2U+CgogICAgPHJlZmVyZW5jZSBhbmNob3I9J0lFRUUtODAy LTE1LUFOQScKCSAgICAgICB0YXJnZXQ9Imh0dHA6Ly93d3cuaWVlZTgwMi5vcmcvMTUvQU5BLmh0 bWwiPgogICAgICA8ZnJvbnQ+CiAgICAgICAgPHRpdGxlPklFRUUgODAyLjE1IEFzc2lnbmVkIE51 bWJlcnMgQXV0aG9yaXR5PC90aXRsZT4KCTxhdXRob3I+PC9hdXRob3I+CiAgICAgICAgPGRhdGUg Lz4KICAgICAgPC9mcm9udD4KICAgIDwvcmVmZXJlbmNlPgoKICAgIDxyZWZlcmVuY2UgYW5jaG9y PSdJRUVFLTgwMi0xNS1BTkEtREInCgkgICAgICAgdGFyZ2V0PSdodHRwczovL21lbnRvci5pZWVl Lm9yZy84MDIuMTUvZG9jdW1lbnRzP2lzX2Rjbj0yNTcmYW1wO2lzX2dyb3VwPTAwMDAnPgogICAg ICA8ZnJvbnQ+CiAgICAgICAgPHRpdGxlPklFRUUgODAyLjE1IEFOQSBkYXRhYmFzZTwvdGl0bGU+ Cgk8YXV0aG9yPjwvYXV0aG9yPgogICAgICAgIDxkYXRlIC8+CiAgICAgIDwvZnJvbnQ+CiAgICA8 L3JlZmVyZW5jZT4KCiAgICA8cmVmZXJlbmNlIGFuY2hvcj0nSUVFRS04MDItMTUtT1BTJwoJICAg ICAgIHRhcmdldD0naHR0cHM6Ly9tZW50b3IuaWVlZS5vcmcvODAyLjE1L2RvY3VtZW50cz9pc19k Y249MjM1JmFtcDtpc19ncm91cD0wMDAwJz4KICAgICAgPGZyb250PgogICAgICAgIDx0aXRsZT5J RUVFIDgwMi4xNSBPcGVyYXRpb25zIE1hbnVhbDwvdGl0bGU+Cgk8YXV0aG9yPjwvYXV0aG9yPgog ICAgICAgIDxkYXRlIC8+CiAgICAgIDwvZnJvbnQ+CiAgICA8L3JlZmVyZW5jZT4KCiAgPC9yZWZl cmVuY2VzPgo8L2JhY2s+Cgo8L3JmYz4K --001a11410ed46d946b05382dba70-- From nobody Thu Jul 21 16:45:18 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A283412D1E4; Thu, 21 Jul 2016 16:45:09 -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 n9leZ6JS4IN0; Thu, 21 Jul 2016 16:45:07 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F3B12D74E; Thu, 21 Jul 2016 16:45:07 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id p74so88258870qka.0; Thu, 21 Jul 2016 16:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=Ehcii1hf2lKhGdgwu2igm6uToYpA6zsvT1M7SjEK2Wg=; b=oUZ9E3Wt2h9rs6qRtvwb5SNAoeNQCIWNEk/KfY2VJXvFciivrbUhBfdo2B2l84/l53 ysRJi4Ypae/wMtx2ky/tL3yJW8UXYf6y9z7LKZsmOYhWxon9hMILccrTWbxt2F4AyVuv dOJ5AMexwSLq2AigY2lKQXD7iTbKH5vqHseEFENKPZAyN0X091k8lUzgUu6C3F5BHzU3 l+43Eale5yjQUIMSuwXLe31Jpou6m5HY1WCv+JerfuS/EMncf6Dbv/8/dB9WhRQtE/Uy knEBdQGkaG5YgPDDvOEOgDDIPB+DkWH2PHF9LbY779I9scFfQEzmOhnWHufw9lSH2KIs /BuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=Ehcii1hf2lKhGdgwu2igm6uToYpA6zsvT1M7SjEK2Wg=; b=d2B31SvMMGuGZjFP5DmrnZLb4p/nWIRpZwKLfCL2+OeKuDg3ygdJbaK9KBhY/tPAKn OYlreVImpvdFER8O03O2lspbFFbQOLVo1nJAFEXEZs3WI1/GOfD3GYr2nkwOjwHRPiYp v7+dCsjs6d+DrgcBTYGaFFNDvyCr15vUAUBRJK0cj0dvOyXkSDtn97kmEaTCaAWv0VQx xsS2Mql//8ag+iQTnYT+O4/6re/Gnz06kW/hZNaUuabz3n4eCg/jlPkQp9Z6RMUfCTRH 3LZu4zQx9B+enUTJJVw1pVNmkRPm/Q3cloPf09TlzAgMg5g/iXMdQlX7QJUyReldIhyz GIzA== X-Gm-Message-State: AEkooutPaZG0dmixy+Pxzf8y8JokN0C5vMRIfJXtwupfH5inVibS/uY6Xv29m6d4/BBPAw== X-Received: by 10.55.201.136 with SMTP id m8mr1237723qkl.166.1469144706328; Thu, 21 Jul 2016 16:45:06 -0700 (PDT) Received: from rtp-vpn1-1829.cisco.com ([173.38.117.78]) by smtp.gmail.com with ESMTPSA id e33sm5724375qta.47.2016.07.21.16.45.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 16:45:05 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6A727992-9D2B-4037-AD8D-6016FB149223"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Ralph Droms In-Reply-To: Date: Fri, 22 Jul 2016 01:45:02 +0200 Message-Id: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> References: To: Suresh Krishnan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [its] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 23:45:09 -0000 --Apple-Mail=_6A727992-9D2B-4037-AD8D-6016FB149223 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Seems to me this document could easily be a working group document. Why = have you decided to publish it as AD sponsored document? - Ralph > On Jul 18, 2016, at 2:39 PM 7/18/16, Suresh Krishnan = wrote: >=20 > Hi all, > I am considering AD sponsoring the following draft >=20 > https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 >=20 > to request the allocation of an 802.15.4 information element from the = IEEE > for use in the IETF protocols that may need it. If you have any = concerns > either with the content of the draft or about requesting the IE at all = please > let me know before 2016/07/29. >=20 > Thanks > Suresh >=20 > NOTE: I have CCed: all the groups that I thought could be potentially > interested in this work. If you think I have missed out some WG(s) = please let > me know. >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch --Apple-Mail=_6A727992-9D2B-4037-AD8D-6016FB149223 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 iQIcBAEBCAAGBQJXkV5+AAoJEINeeBNmFjV5NxYQAIjOdTko0MiOjEAbroyju3FG RiYcOCYrJ7iwbrNJhF86Wf15MPuY9JXHZX2B752yit3PnSuCZQMy1WkJa6YO3YtO 03AzOGhmTX/bX7qkxsrpHv3YbJaxjxQ27crqLZUzLcn2OX5QNETg/nfQkQI/eLN1 lhSZWyrHFhpY5Gr0xAO3nuQY5o9E5dx/LjeHi9aXGCDYBeGBhXhhFmlB3haxCz3+ hkFPx6c54wMMuX+/E+7SDExw2MichBsOO+HMU7jJiQEJGbNm39xBcbm59kP02ezC BpjRHO1QE+xUoyes4+byTGSA2dtzYb8p7EZMzN3+YVWY/FnVaZV8lMAoUdgus6+I VG9UyGjyMa9l8LV88q6ppBWan+8aTLLnIxOXrtzyT5ua2pWH7px3SczgsY18ygbN cRCmtQLT/uiwvfcawdRq1ufp1zsk3uC9/XQR65ml5ebIWSI+z03tryXmY59pAq1s rN3S58xRpjQk/kD408U9rLsSfnl9ojL4JT0Hs0Qfuag/A345dzZia5NNZVFBNGk3 Z7WK5Dwv4ILgpTdWzP6NGPTKseGADzX+ZnS7g/duZhwwjTdOZpj9+/genAK5VLby cypzeAL28SMz86SZmzRcSex/dPtso1MN7D/v2Euo6Jrzz1tceCHiOdI5r9vEU6Un TwQ7/wupFzDXRFhFHJkD =ASZI -----END PGP SIGNATURE----- --Apple-Mail=_6A727992-9D2B-4037-AD8D-6016FB149223-- From nobody Fri Jul 22 01:29:49 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2CA12DA35; Fri, 22 Jul 2016 01:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbKfsv38oIW2; Fri, 22 Jul 2016 01:29:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 8DAFD12D1A4; Fri, 22 Jul 2016 01:29:28 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u6M8TOvm016279 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Jul 2016 11:29:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6M8TNep008324; Fri, 22 Jul 2016 11:29:23 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22417.55651.808400.872940@fireball.acr.fi> Date: Fri, 22 Jul 2016 11:29:23 +0300 From: Tero Kivinen To: Thomas Watteyne In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 1 min Archived-At: Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , Suresh Krishnan , "iot-dir@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [its] [6tisch] [IoT-DIR] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:29:30 -0000 Thomas Watteyne writes: > I'm attaching the XML of the the -02 version of that draft in which I have > corrected some typos. I'll let Tero and Pat decide what he wants to merge, if > anything. These changes are for the authors' information only, they do NOT > affect my support to publish this document. Thanks, I have taken your most of your changes to my xml version, and I will publish new version soon, with those fixes. -- kivinen@iki.fi From nobody Fri Jul 22 05:44: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 B44FE12D1F0; Fri, 22 Jul 2016 05:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 5OyDcoL8Y0pf; Fri, 22 Jul 2016 05:44:21 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 69B9812D62A; Fri, 22 Jul 2016 05:44:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,404,1464645600"; d="scan'208,217";a="227601884" Received: from mail-lf0-f41.google.com ([209.85.215.41]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 22 Jul 2016 14:44:18 +0200 Received: by mail-lf0-f41.google.com with SMTP id b199so84876429lfe.0; Fri, 22 Jul 2016 05:44:18 -0700 (PDT) X-Gm-Message-State: AEkooutVTV+wXjqVl5gni5zY2MkpPmjgG+/EfJQVVWhFV5fj6I/EnyrIQ0CJSK4uT58/QynUpuwPKISFqlsWuw== X-Received: by 10.25.89.65 with SMTP id n62mr2608729lfb.89.1469191457615; Fri, 22 Jul 2016 05:44:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.146.84 with HTTP; Fri, 22 Jul 2016 05:43:57 -0700 (PDT) In-Reply-To: <22417.55651.808400.872940@fireball.acr.fi> References: <22417.55651.808400.872940@fireball.acr.fi> From: Thomas Watteyne Date: Fri, 22 Jul 2016 14:43:57 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a11411eb8f045cd053838ca21 Archived-At: Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , Suresh Krishnan , "iot-dir@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [its] [6tisch] [IoT-DIR] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 12:44:24 -0000 --001a11411eb8f045cd053838ca21 Content-Type: text/plain; charset=UTF-8 Awesome, thanks On Fri, Jul 22, 2016 at 10:29 AM, Tero Kivinen wrote: > Thomas Watteyne writes: > > I'm attaching the XML of the the -02 version of that draft in which I > have > > corrected some typos. I'll let Tero and Pat decide what he wants to > merge, if > > anything. These changes are for the authors' information only, they do > NOT > > affect my support to publish this document. > > Thanks, I have taken your most of your changes to my xml version, and > I will publish new version soon, with those fixes. > -- > kivinen@iki.fi > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a11411eb8f045cd053838ca21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Awesome, thanks

On Fri, Jul 22, 2016 at 10:29 AM, Tero Kivinen <kivinen@= iki.fi> wrote:
Thomas Watte= yne writes:
> I'm attaching the XML of the the -02 version of that draft in whic= h I have
> corrected some typos. I'll let Tero and Pat decide what he wants t= o merge, if
> anything. These changes are for the authors' information only, the= y do NOT
> affect my support to publish this document.

Thanks, I have taken your most of your changes to my xml version, and
I will publish new version soon, with those fixes.
--
kivinen@iki.fi



--
_______________________________________

<= /font>
Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
= Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkele= y OpenWSN
Co-chair, IETF 6TiSCH

__________= _____________________________
--001a11411eb8f045cd053838ca21-- From nobody Fri Jul 22 09:35: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 2CE1212DA7E; Fri, 22 Jul 2016 01:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mqmeRzUQhiA; Fri, 22 Jul 2016 01:12:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 BD0D912DAAC; Fri, 22 Jul 2016 01:12:24 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u6M8CJkL019028 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Jul 2016 11:12:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6M8CJ8i015184; Fri, 22 Jul 2016 11:12:19 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22417.54627.526844.924720@fireball.acr.fi> Date: Fri, 22 Jul 2016 11:12:19 +0300 From: Tero Kivinen To: Ralph Droms In-Reply-To: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> References: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: X-Mailman-Approved-At: Fri, 22 Jul 2016 09:35:24 -0700 Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , Suresh Krishnan , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [its] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:12:38 -0000 Ralph Droms writes: > Seems to me this document could easily be a working group document. > Why have you decided to publish it as AD sponsored document? As this will allocate number for the IETF, not for just one WG, the authors though it would be better to get as wide coverage for it, meaning having longer last call time, and advertising it in several different working groups (who might use it in the future), instead of having it for one WG draft in some WG. Also it was not clear which WG it should be in. I think 6tisch is the one who might need it first, but 6lo is most likely also going to using it etc. -- kivinen@iki.fi From nobody Sat Jul 23 03:06:40 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FFE12D587 for ; Sat, 23 Jul 2016 03:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.394 X-Spam-Level: X-Spam-Status: No, score=-100.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SUBJ_ALL_CAPS=1.506, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9w_BQhyznGe7 for ; Sat, 23 Jul 2016 03:06:38 -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 639B912B043 for ; Sat, 23 Jul 2016 03:06:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4A932300567 for ; Sat, 23 Jul 2016 06:06:36 -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 10026) with ESMTP id dzClFxQt8CSm for ; Sat, 23 Jul 2016 06:06:35 -0400 (EDT) Received: from [10.53.150.60] (unknown [88.128.80.151]) by mail.smeinc.net (Postfix) with ESMTPSA id 054643002BA for ; Sat, 23 Jul 2016 06:06:34 -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: <-4479571328460427389@unknownmsgid> Date: Sat, 23 Jul 2016 06:06:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <147FC99B-4412-4877-B8FB-86D938945B96@vigilsec.com> References: <-4479571328460427389@unknownmsgid> To: its@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [its] US NHTSA V2V PKI X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 10:06:40 -0000 Some people on this list may be interested in reviewing these documents. = I understand that comments are welcome. Russ =20 > I am happy to report that the V2V PKI documentation is now available = for public comment. Please, please share far and wide. >=20 > https://www.regulations.gov/document?D=3DNHTSA-2015-0060-0004 From nobody Sun Jul 24 11:43:39 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAA712DA57; Sat, 23 Jul 2016 04:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 IugFUxgXJ9DV; Sat, 23 Jul 2016 04:30:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F38912D110; Sat, 23 Jul 2016 04:30:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BD3B2203AD; Sat, 23 Jul 2016 07:39:59 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B0170638BE; Sat, 23 Jul 2016 07:30:18 -0400 (EDT) From: Michael Richardson To: Tero Kivinen In-Reply-To: <22417.54627.526844.924720@fireball.acr.fi> References: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> <22417.54627.526844.924720@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-Mailman-Approved-At: Sun, 24 Jul 2016 11:43:37 -0700 Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , Suresh Krishnan , "iot-dir@ietf.org" , "lpwan@ietf.org" , Ralph Droms , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [its] [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 11:30:22 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > meaning having longer last call time, and advertising it in several > different working groups (who might use it in the future), instead of > having it for one WG draft in some WG. > Also it was not clear which WG it should be in. I think 6tisch is the > one who might need it first, but 6lo is most likely also going to > using it etc. This makes me ask a question about 802.15.9: would a new KMP created by the IETF for 15.9 (such as OSCOAP or DTLS) need to use an IE under this subtype? Or does 15.9 have it's own registry, and if so would we need different liason request for that? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5NVR4CLcPvd0N1lAQIR7gf+PqzBdKtG9KHlsMZ+8Qadn0/717on1htM jmmFgtDNZGQZbqJEGhMcCHsOEgi7y6pwcrTiWgs8gQtV2y5NLEH5bmUL1W67TCa+ 7ggnoZuRNqU6404TmI/1XrLvjcPTamjMbeKv1JFhbUSUBhLUj7gOUisGNtIJW52u b3Sgxt9X69hcJ+Q17KTIZxdyMlqnMp8FmdrHYYMMP9vniYySzRZm6dL7eCrOQpFd iP952rBehCygTEpzHlSPRw5A9cBPCM/an/QGZzFuOhz920MlqPHlNp6XN7EqlzG8 07SB7UhuZ2jtH4fT59abialUpncY+aSnVLBFSvzqfPDJcswjKMwTyA== =jcGn -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 24 11:43: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 186A912D77B for ; Sat, 23 Jul 2016 12:26:37 -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, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.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 2JlIeBkV0qiz for ; Sat, 23 Jul 2016 12:26:35 -0700 (PDT) Received: from nm47-vm5.bullet.mail.ne1.yahoo.com (nm47-vm5.bullet.mail.ne1.yahoo.com [98.138.121.101]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17BF312D789 for ; Sat, 23 Jul 2016 12:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1469301991; bh=N7v2GMKFE2NmnZumKgBTMmJH2KBK14YVaxesBSz2jNU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=SSWeqUOBfYj9aN6MbKkVgFmgYgzHcmEkR/TF9m1kJnjlQbFQac4TN4Ci2+H++SY8mZlUmYm14EVWvfzelsmo4kOcq0Hzt4C4RP6955OA1EkkMEcFpGFuaZzXWlRmbfCF22HIafA3kdtws7bTYDZ7pfDMQvWCqVW9/8jzmHwbMeQ= Received: from [127.0.0.1] by nm47.bullet.mail.ne1.yahoo.com with NNFMP; 23 Jul 2016 19:26:31 -0000 Received: from [98.138.226.177] by nm47.bullet.mail.ne1.yahoo.com with NNFMP; 23 Jul 2016 19:23:42 -0000 Received: from [98.138.226.58] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 23 Jul 2016 19:20:54 -0000 Received: from [127.0.0.1] by smtp209.mail.ne1.yahoo.com with NNFMP; 23 Jul 2016 19:20:54 -0000 X-Yahoo-Newman-Id: 54038.44352.bm@smtp209.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-4 X-YMail-OSG: qRHBZqQVM1lXX.5le6Fw0oW3FhlNwv2H0MiGDH4ZPOyqkLQ CHo0a8ggOR3wDfmkvqw1_vPGn8lMEDgkDzhFQ_zKh3opf8oSEwQb2nsJJLu_ ciUjT8ZctkEhBAU4bZ9SNgyhD_0qc5hP08vC9M9AChKUX1fx6lXCjwQhjiNO NQoKsqapWlcxz3CQdzaCCHF5nOWMIxvs6IKEPAIJn35t6v5Rv4PpQiWb4C_R DNztc8Q4sa1tEBvVyJ.NFkx0eQZmLju04yWILHeAnk07VFzoaqYB_.D5x9Oi 9zsMhxrY0I4NpgS_U_j_3YCobD1NCpat0CgDU8ttzZwPQKCMBT8GhCiS.vOq rnCcAJhiUBQJE3e_G5VEy.Ee2uiA7nKZvQjGDKjwKSuAe9f24vWicKTBslaZ v9JX4sdjCZdnup8aODXT3dbLpQuWUDsXJqVPB1XOQ7DIO_mw4MM.XTXZnd1v VcGPS4us.bWyZLFB95wDfu16FBHfqK8wNm.8lllGX6sZbpIPnqK5zkT_h454 E08I8a5FBevX5_7QniBoiayP0_8brUoX1SwzjxJEvfRH0uQZTRgmc3FM2JlD qIAEF1klzxnD4vOSkNJULRg-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Don Sturek X-Mailer: iPad Mail (13F69) In-Reply-To: <31079.1469273418@obiwan.sandelman.ca> Date: Sat, 23 Jul 2016 12:20:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> <22417.54627.526844.924720@fireball.acr.fi> <31079.1469273418@obiwan.sandelman.ca> To: Michael Richardson Archived-At: X-Mailman-Approved-At: Sun, 24 Jul 2016 11:43:37 -0700 Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , Suresh Krishnan , "iot-dir@ietf.org" , "lpwan@ietf.org" , Tero Kivinen , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org>, Ralph Droms Subject: Re: [its] [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 19:26:37 -0000 Hi Michael IEEE 802.15.9 defines a multiplex ID covered by the IEEE 802.15 ANA. To def= ine a new KMP would only require a new annex that describes how the KMP work= s and an allocation of a new Multiplex ID. There is also a vendor specific multiplex ID that could be used now without a= ny written description in IEEE 802.15 Don Sent from my iPad > On Jul 23, 2016, at 4:30 AM, Michael Richardson wr= ote: >=20 >=20 > Tero Kivinen wrote: >> meaning having longer last call time, and advertising it in several >> different working groups (who might use it in the future), instead of >> having it for one WG draft in some WG. >=20 >> Also it was not clear which WG it should be in. I think 6tisch is the >> one who might need it first, but 6lo is most likely also going to >> using it etc. >=20 > This makes me ask a question about 802.15.9: would a new KMP created by t= he > IETF for 15.9 (such as OSCOAP or DTLS) need to use an IE under this subtyp= e? > Or does 15.9 have it's own registry, and if so would we need different lia= son > request for that? >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo From nobody Mon Jul 25 07:35: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 D21FD12D8E4 for ; Mon, 25 Jul 2016 07:35:15 -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 U7SWiPLyOmVm for ; Mon, 25 Jul 2016 07:35:14 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 0263A12D8E3 for ; Mon, 25 Jul 2016 07:35:14 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id l72so254680838oig.2 for ; Mon, 25 Jul 2016 07:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:reply-to:from:to:cc:references:in-reply-to:subject:date :mime-version:importance; bh=up1MUd4o2kw2q1KIZ0BwSRgz72TR0CWCIig+FLFCQr8=; b=ARa7c5X5XUDqhuwjRWYhVEroupl4qiwzsLllxZdHWu57P2wziZ6DApaPoAuCc9Bx9u FwUsr15MRED/7d316QEyaSx1t1rM0B1ZINXWoeAG1AOsaHcq7qdsprZjoMO7HUB2XvN5 fHeZthDaKp4vC0RgCsk+5vvR6p/oPk8mirxetHqo93vzT+TuDkMkMnvzCyFLrvKFpsui WFxtIAOKT2NZmSbhYnqHdT8hnqTHe8lFnNgYPUAIBpkvgcL1mtH9eoXs1yX1Rrk+44y7 h/3hi4lltGWJVmX9cGTsWHCMMMbs1VR0MbO2icqXIF3KM2yRHGMkuqUDtaQkqit9vdxq XvZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:reply-to:from:to:cc:references :in-reply-to:subject:date:mime-version:importance; bh=up1MUd4o2kw2q1KIZ0BwSRgz72TR0CWCIig+FLFCQr8=; b=Fvvr3ga/rUFwH4kEe2Cg+2dnh1xK/fgziCiQq4OtLhz4kSOKwT3YqNCjoqgvy5B6MR 5LBkjA8S/0D1iZAv2FpQwbT9nAfpTzM/Y1A/5nKZjlR53bZFutTqyfw/ZlDTwabo/Ak1 zkaBT/PL9bwFQcz8YW6Rx1FqZYmJDbTDxBpps9zi3SWyEz/nEm9/TTkj8KO/tFgKmWmC Eop0kMriSFiRjDO16i6mWD8Dh3f93AbSpAEwwYg4+EwrL90Y+S87H+U+37PS75hVuTmy 6NwXK2FzyNwaSC352Ser01S0VqZXZq7kkeGDcrOEZWsmauZnfL+lZSKqYbREYZFfPfna YRUA== X-Gm-Message-State: AEkoousAljpdzHN1Biwoc/0PHvYTfNuaBJssWr/xiwhyX9D3cSMNDBidfX2X++qyU8NJ3g== X-Received: by 10.157.37.181 with SMTP id q50mr10372295ota.79.1469457313171; Mon, 25 Jul 2016 07:35:13 -0700 (PDT) Received: from C73782TX3 ([50.58.7.243]) by smtp.gmail.com with ESMTPSA id 3sm11373349otx.3.2016.07.25.07.35.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jul 2016 07:35:11 -0700 (PDT) Message-ID: <7234D8CC1B664F878FAA845C4061AD7C@china.huawei.com> From: "H Anthony Chan" To: "Russ Housley" References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> <7e2d1572-9333-7d74-30ad-c47cd0d8512f@htt-consult.com> In-Reply-To: <7e2d1572-9333-7d74-30ad-c47cd0d8512f@htt-consult.com> Date: Mon, 25 Jul 2016 09:35:10 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01D1E657.D69DBCE0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Archived-At: Cc: its@ietf.org Subject: Re: [its] Charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: H Anthony Chan List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 14:35:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0044_01D1E657.D69DBCE0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The following is an example of deployment : http://www.rcrwireless.com/20160712/connected-cars-2/dt-huawei-audi-toyot= a-carry-lte-v-trials-germany DT, Huawei, Audi and Toyota carry out LTE-V trials in Germany=20 German telco said LTE-V is a potential enabler for road safety and = traffic efficiency apps German telecom operator Deutsche Telekom, Chinese vendor Huawei and car = makers including Audi and Toyota are currently testing LTE-Vehicular in = Germany. The German telco said that technical tests are underway on this = connected vehicles technology, which is seen as a potential enabler for = road safety and traffic efficiency applications. The partners are = conducting these trials on a section of the =93digital A9 motorway test = bed=94 near Ingolstadt, Germany. LTE-V is a variant of 4G LTE technology. It is being specified within = the European 3GPP project that develops telecommunications standards as = part of its Release 14. This variant is specifically designed to meet = automotive requirements for both vehicle-to-vehicle and = vehicle-to-infrastructure communication. LTE-V can address multiple = application types ranging from connected vehicle safety applications =96 = collision warning, pedestrian warning, etc. =96 to connected vehicle = smart mobility applications for increased efficiency. Deutsche Telekom infrastructure has been specially equipped with LTE-V = hardware from Huawei to support the trial scenarios. Audi, Toyota and = other car manufacturers have equipped research cars with the LTE-V = hardware developed by Huawei. Based on the trial results, the partners = will provide input to the standards specifications for LTE-V. H Anthony Chan ------=_NextPart_000_0044_01D1E657.D69DBCE0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The following is an example of deployment :
 

http://www.rcrwireless.com/20160712/connected-cars-2/dt-h= uawei-audi-toyota-carry-lte-v-trials-germany

=

 

DT, Huawei, Audi and Toyota carry out = LTE-V trials=20 in Germany

German telco said LTE-V is a potential = enabler for=20 road safety and traffic efficiency apps

German telecom operator Deutsche Telekom, Chinese vendor = Huawei=20 and car makers including Audi and Toyota are currently testing = LTE-Vehicular in=20 Germany.

The German telco said that technical tests are underway = on this=20 connected vehicles technology, which is seen as a potential enabler for = road=20 safety and traffic efficiency applications. The partners are conducting = these=20 trials on a section of the =93digital A9 motorway test bed=94 near = Ingolstadt,=20 Germany.

LTE-V is a variant of 4G LTE technology. It is being = specified=20 within the European 3GPP project that develops telecommunications = standards as=20 part of its Release 14. This variant is specifically designed to meet = automotive=20 requirements for both vehicle-to-vehicle and vehicle-to-infrastructure=20 communication. LTE-V can address multiple application types ranging from = connected vehicle safety applications =96 collision warning, pedestrian = warning,=20 etc. =96 to connected vehicle smart mobility applications for increased=20 efficiency.

Deutsche Telekom infrastructure has been specially = equipped with=20 LTE-V hardware from Huawei to support the trial scenarios. Audi, Toyota = and=20 other car manufacturers have equipped research cars with the LTE-V = hardware=20 developed by Huawei. Based on the trial results, the partners will = provide input=20 to the standards specifications for LTE-V.

H=20 Anthony Chan

------=_NextPart_000_0044_01D1E657.D69DBCE0-- From nobody Mon Jul 25 07:57: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 6649E12D158 for ; Mon, 25 Jul 2016 07:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 XpCknNsbOhfY for ; Mon, 25 Jul 2016 07:57:33 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (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 2A19112D142 for ; Mon, 25 Jul 2016 07:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1469458650; l=11154; s=domk; d=fischer-tech.eu; h=Content-Type:In-Reply-To:MIME-Version:Date:From:Cc:References:To: Subject; bh=DnWGvtVRSe68geP5Yiyw4BiGhxTjU8OZRazPutTzOs0=; b=D1K1q5zDtwlDSO0M3GyeaS7f6ECADukfCBbqGsGgFy8WB5O717q3Jc+mH79kvDclKm4 oxqSVIkZjYj2HPKl2rDH4oEQErLZdLk5L52+rPufb96s1zdJ8m7jwzswFI6K5hmSv0pX6 G53fEiErswaWoxwcza6V1aYoiyxF5gq1Cfw= X-RZG-AUTH: :JGYCfFOrc/o0m7eTcArWz0wjmOawaLakL8gsnQV23mJctoKb1FltCfvwAqRXXtvj0soFZls= X-RZG-CLASS-ID: mo00 Received: from [192.168.222.100] (p549C9C01.dip0.t-ipconnect.de [84.156.156.1]) by smtp.strato.de (RZmta 38.13 DYNA|AUTH) with ESMTPSA id D0b7c5s6PEvRMtK (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); Mon, 25 Jul 2016 16:57:27 +0200 (CEST) To: H Anthony Chan , Russ Housley References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> <7e2d1572-9333-7d74-30ad-c47cd0d8512f@htt-consult.com> <7234D8CC1B664F878FAA845C4061AD7C@china.huawei.com> From: "Dr. Hans-Joachim Fischer" Organization: ESF GmbH Message-ID: <4d95a92d-6dad-2ee5-5a41-70c8b9d11397@fischer-tech.eu> Date: Mon, 25 Jul 2016 16:57:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7234D8CC1B664F878FAA845C4061AD7C@china.huawei.com> Content-Type: multipart/alternative; boundary="------------C2A469842246231E553A6F21" Archived-At: Cc: its@ietf.org Subject: Re: [its] Charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 14:57:36 -0000 This is a multi-part message in MIME format. --------------C2A469842246231E553A6F21 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sorry! Deployment? I read "trial". It cannot be more. Hans-Joachim Am 25.07.2016 um 16:35 schrieb H Anthony Chan: > The following is an example of deployment : > > http://www.rcrwireless.com/20160712/connected-cars-2/dt-huawei-audi-toyota-carry-lte-v-trials-germany > > DT, Huawei, Audi and Toyota carry out LTE-V trials in Germany > > > German telco said LTE-V is a potential enabler for road safety and > traffic efficiency apps > > German telecom operator Deutsche Telekom, Chinese vendor Huawei and > car makers including Audi and Toyota are currently testing > LTE-Vehicular in Germany. > > The German telco said that technical tests are underway on this > connected vehicles technology, which is seen as a potential enabler > for road safety and traffic efficiency applications. The partners are > conducting these trials on a section of the “digital A9 motorway test > bed” near Ingolstadt, Germany. > > LTE-V is a variant of 4G LTE technology. It is being specified within > the European 3GPP project that develops telecommunications standards > as part of its Release 14. This variant is specifically designed to > meet automotive requirements for both vehicle-to-vehicle and > vehicle-to-infrastructure communication. LTE-V can address multiple > application types ranging from connected vehicle safety applications – > collision warning, pedestrian warning, etc. – to connected vehicle > smart mobility applications for increased efficiency. > > Deutsche Telekom infrastructure has been specially equipped with LTE-V > hardware from Huawei to support the trial scenarios. Audi, Toyota and > other car manufacturers have equipped research cars with the LTE-V > hardware developed by Huawei. Based on the trial results, the partners > will provide input to the standards specifications for LTE-V. > > H Anthony Chan > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its -- Dr. Hans-Joachim Fischer Managing Director ------------------------------------------------------------------------------- Seminars on Cooperative Intelligent Transport Systems http://fischer-tech.eu/Feeds/CITSseminars.html ------------------------------------------------------------------------------- + + + 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 ------------------------------------------------------------------------------- --------------C2A469842246231E553A6F21 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit


Sorry!

Deployment? I read "trial". It cannot be more.


Hans-Joachim


Am 25.07.2016 um 16:35 schrieb H Anthony Chan:
The following is an example of deployment :
 

http://www.rcrwireless.com/20160712/connected-cars-2/dt-huawei-audi-toyota-carry-lte-v-trials-germany

 

DT, Huawei, Audi and Toyota carry out LTE-V trials in Germany

German telco said LTE-V is a potential enabler for road safety and traffic efficiency apps

German telecom operator Deutsche Telekom, Chinese vendor Huawei and car makers including Audi and Toyota are currently testing LTE-Vehicular in Germany.

The German telco said that technical tests are underway on this connected vehicles technology, which is seen as a potential enabler for road safety and traffic efficiency applications. The partners are conducting these trials on a section of the “digital A9 motorway test bed” near Ingolstadt, Germany.

LTE-V is a variant of 4G LTE technology. It is being specified within the European 3GPP project that develops telecommunications standards as part of its Release 14. This variant is specifically designed to meet automotive requirements for both vehicle-to-vehicle and vehicle-to-infrastructure communication. LTE-V can address multiple application types ranging from connected vehicle safety applications – collision warning, pedestrian warning, etc. – to connected vehicle smart mobility applications for increased efficiency.

Deutsche Telekom infrastructure has been specially equipped with LTE-V hardware from Huawei to support the trial scenarios. Audi, Toyota and other car manufacturers have equipped research cars with the LTE-V hardware developed by Huawei. Based on the trial results, the partners will provide input to the standards specifications for LTE-V.

H Anthony Chan



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


-- 
Dr. Hans-Joachim Fischer
Managing Director


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

         Seminars on Cooperative Intelligent Transport Systems
             http://fischer-tech.eu/Feeds/CITSseminars.html

------------------------------------------------------------------------------- 
+ + + 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
-------------------------------------------------------------------------------
--------------C2A469842246231E553A6F21-- From nobody Mon Jul 25 08:23: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 CDBAE12D7C9; Mon, 25 Jul 2016 04:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.207 X-Spam-Level: X-Spam-Status: No, score=-8.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 CtDlaLKNn14V; Mon, 25 Jul 2016 04:32:46 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 9A48312D7C0; Mon, 25 Jul 2016 04:32:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2H9AQDQ95VX/xUHmMZeGgEBAQGCdC2BU?= =?us-ascii?q?gaNJas4gXyGHQKBODgUAQEBAQEBAQNaJ4RcAQEBAQMSKD8MBAIBCA0EBAEBCxQ?= =?us-ascii?q?JBzIUCQgCBAENBQgaiA4BmxKXfgEBAQEBAQEBAQEBAQEBAQEBAQEBARyGK4RMh?= =?us-ascii?q?EKDKoIvBZkoAZhZhVSQIR42g3NuiA4BfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2H9AQDQ95VX/xUHmMZeGgEBAQGCdC2BUgaNJas4gXyGHQK?= =?us-ascii?q?BODgUAQEBAQEBAQNaJ4RcAQEBAQMSKD8MBAIBCA0EBAEBCxQJBzIUCQgCBAENB?= =?us-ascii?q?QgaiA4BmxKXfgEBAQEBAQEBAQEBAQEBAQEBAQEBARyGK4RMhEKDKoIvBZkoAZh?= =?us-ascii?q?ZhVSQIR42g3NuiA4BfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,419,1464667200"; d="scan'208";a="163382577" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jul 2016 07:32:40 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 25 Jul 2016 07:32:39 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0294.000; Mon, 25 Jul 2016 07:32:35 -0400 From: "Romascanu, Dan (Dan)" To: Tero Kivinen , Ralph Droms Thread-Topic: [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 Thread-Index: AQHR46nuMI5CehytXkWhPvcB61QhZqAj+K2AgAUPRgA= Date: Mon, 25 Jul 2016 11:32:35 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7524F552@AZ-FFEXMB04.global.avaya.com> References: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> <22417.54627.526844.924720@fireball.acr.fi> In-Reply-To: <22417.54627.526844.924720@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 25 Jul 2016 08:23:32 -0700 Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , Suresh Krishnan , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [its] [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 11:32:48 -0000 > -----Original Message----- > From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Tero Kivinen > Sent: Friday, July 22, 2016 11:12 AM > To: Ralph Droms > Cc: Internet Area; its@ietf.org; roll@ietf.org; Suresh Krishnan; iot- > dir@ietf.org; lpwan@ietf.org; core@ietf.org; 6lo; 6tisch > Subject: Re: [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 >=20 > Ralph Droms writes: > > Seems to me this document could easily be a working group document. > > Why have you decided to publish it as AD sponsored document? >=20 > As this will allocate number for the IETF, not for just one WG, the autho= rs > though it would be better to get as wide coverage for it, meaning having > longer last call time, and advertising it in several different working gr= oups > (who might use it in the future), instead of having it for one WG draft i= n > some WG. >=20 > Also it was not clear which WG it should be in. I think 6tisch is the one= who > might need it first, but 6lo is most likely also going to using it etc. > -- > kivinen@iki.fi >=20 The last argument is relatively easy to overcome. As both 6tisch and 6lo be= long in the INT area, this could be a good candidate for a intarea WG docum= ent. I also have a slight preference for this path, as a WG document has ty= pically a better level of scrutiny and review.=20 Regards, Dan From nobody Mon Jul 25 11:34:39 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A63C12D513 for ; Mon, 25 Jul 2016 11:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 CsVmpRutKtIV for ; Mon, 25 Jul 2016 11:34:35 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 0D37512D0B1 for ; Mon, 25 Jul 2016 11:34:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2DEFF621C9; Mon, 25 Jul 2016 14:34:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id P0lqrtqH30Ao; Mon, 25 Jul 2016 14:34:25 -0400 (EDT) Received: from lx120e.htt-consult.com (66.238.57.130.ptr.us.xo.net [66.238.57.130]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id EBED9621C5; Mon, 25 Jul 2016 14:34:23 -0400 (EDT) To: "Dr. Hans-Joachim Fischer" , H Anthony Chan , Russ Housley References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> <7e2d1572-9333-7d74-30ad-c47cd0d8512f@htt-consult.com> <7234D8CC1B664F878FAA845C4061AD7C@china.huawei.com> <4d95a92d-6dad-2ee5-5a41-70c8b9d11397@fischer-tech.eu> From: Robert Moskowitz Message-ID: <5c4c4684-a3bf-f208-b6ed-1bd9bbf052b2@htt-consult.com> Date: Mon, 25 Jul 2016 11:34:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <4d95a92d-6dad-2ee5-5a41-70c8b9d11397@fischer-tech.eu> Content-Type: multipart/alternative; boundary="------------4562C7D67C3404BE1922B4D2" Archived-At: Cc: its@ietf.org Subject: Re: [its] Charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 18:34:38 -0000 This is a multi-part message in MIME format. --------------4562C7D67C3404BE1922B4D2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit One can argue that it is an example of what a deployment would be like. Just like the various DSRC testbeds with some thousands of enabled vehicles. :) On 07/25/2016 07:57 AM, Dr. Hans-Joachim Fischer wrote: > > > Sorry! > > Deployment? I read "trial". It cannot be more. > > > Hans-Joachim > > > Am 25.07.2016 um 16:35 schrieb H Anthony Chan: >> The following is an example of deployment : >> >> http://www.rcrwireless.com/20160712/connected-cars-2/dt-huawei-audi-toyota-carry-lte-v-trials-germany >> >> DT, Huawei, Audi and Toyota carry out LTE-V trials in Germany >> >> >> German telco said LTE-V is a potential enabler for road safety >> and traffic efficiency apps >> >> German telecom operator Deutsche Telekom, Chinese vendor Huawei and >> car makers including Audi and Toyota are currently testing >> LTE-Vehicular in Germany. >> >> The German telco said that technical tests are underway on this >> connected vehicles technology, which is seen as a potential enabler >> for road safety and traffic efficiency applications. The partners are >> conducting these trials on a section of the “digital A9 motorway test >> bed” near Ingolstadt, Germany. >> >> LTE-V is a variant of 4G LTE technology. It is being specified within >> the European 3GPP project that develops telecommunications standards >> as part of its Release 14. This variant is specifically designed to >> meet automotive requirements for both vehicle-to-vehicle and >> vehicle-to-infrastructure communication. LTE-V can address multiple >> application types ranging from connected vehicle safety applications >> – collision warning, pedestrian warning, etc. – to connected vehicle >> smart mobility applications for increased efficiency. >> >> Deutsche Telekom infrastructure has been specially equipped with >> LTE-V hardware from Huawei to support the trial scenarios. Audi, >> Toyota and other car manufacturers have equipped research cars with >> the LTE-V hardware developed by Huawei. Based on the trial results, >> the partners will provide input to the standards specifications for >> LTE-V. >> >> H Anthony Chan >> >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > -- > Dr. Hans-Joachim Fischer > Managing Director > > > ------------------------------------------------------------------------------- > > Seminars on Cooperative Intelligent Transport Systems > http://fischer-tech.eu/Feeds/CITSseminars.html > > ------------------------------------------------------------------------------- > + + + 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 > ------------------------------------------------------------------------------- > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --------------4562C7D67C3404BE1922B4D2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

One can argue that it is an example of what a deployment would be like.  Just like the various DSRC testbeds with some thousands of enabled vehicles.


:)


On 07/25/2016 07:57 AM, Dr. Hans-Joachim Fischer wrote:


Sorry!

Deployment? I read "trial". It cannot be more.


Hans-Joachim


Am 25.07.2016 um 16:35 schrieb H Anthony Chan:
The following is an example of deployment :
 

http://www.rcrwireless.com/20160712/connected-cars-2/dt-huawei-audi-toyota-carry-lte-v-trials-germany

 

DT, Huawei, Audi and Toyota carry out LTE-V trials in Germany

German telco said LTE-V is a potential enabler for road safety and traffic efficiency apps

German telecom operator Deutsche Telekom, Chinese vendor Huawei and car makers including Audi and Toyota are currently testing LTE-Vehicular in Germany.

The German telco said that technical tests are underway on this connected vehicles technology, which is seen as a potential enabler for road safety and traffic efficiency applications. The partners are conducting these trials on a section of the “digital A9 motorway test bed” near Ingolstadt, Germany.

LTE-V is a variant of 4G LTE technology. It is being specified within the European 3GPP project that develops telecommunications standards as part of its Release 14. This variant is specifically designed to meet automotive requirements for both vehicle-to-vehicle and vehicle-to-infrastructure communication. LTE-V can address multiple application types ranging from connected vehicle safety applications – collision warning, pedestrian warning, etc. – to connected vehicle smart mobility applications for increased efficiency.

Deutsche Telekom infrastructure has been specially equipped with LTE-V hardware from Huawei to support the trial scenarios. Audi, Toyota and other car manufacturers have equipped research cars with the LTE-V hardware developed by Huawei. Based on the trial results, the partners will provide input to the standards specifications for LTE-V.

H Anthony Chan



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


-- 
Dr. Hans-Joachim Fischer
Managing Director


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

         Seminars on Cooperative Intelligent Transport Systems
             http://fischer-tech.eu/Feeds/CITSseminars.html

------------------------------------------------------------------------------- 
+ + + 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
-------------------------------------------------------------------------------



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

--------------4562C7D67C3404BE1922B4D2-- From nobody Tue Jul 26 05:56: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 CE99712D802 for ; Tue, 26 Jul 2016 05:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 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, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yogoko.fr 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 gHkENK4xYoKR for ; Tue, 26 Jul 2016 05:56:34 -0700 (PDT) Received: from mx2.yogoko.fr (mx2.yogoko.fr [212.129.44.112]) by ietfa.amsl.com (Postfix) with ESMTP id 5B11B12D99A for ; Tue, 26 Jul 2016 05:56:29 -0700 (PDT) Received: from mail.yogoko.fr (mail.yogoko.fr [IPv6:2a02:a80:0:5057::25]) by mx2.yogoko.fr (Postfix) with ESMTP id 27CA260096; Tue, 26 Jul 2016 14:55:20 +0200 (CEST) Received: from mail.yogoko.fr (localhost [127.0.0.1]) by mail.yogoko.fr (Postfix) with ESMTP id C9093C68A2; Tue, 26 Jul 2016 14:56:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=yogoko.fr; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=dkim; bh=Ou70m+E78sJUVZtfRoBA2hXWfS hmdwMoxil2CrLLzQU=; b=RQzdWv+nHIfSvGnQfDEybJTwW0poqe0Irv+4bsI3uH ++bFk47vFJZKEiEwezb+QRHVHKftuuc1aIy9dtZaVa2jKxY5IgrUJEQcWzDQKEp9 ayHQk5kX1a5v70xNOp9ugNx6pbGYdZJ4IJelMAp9iT0zpMUovzC9gW7jYtFAm1F7 w= Received: from [IPv6:2a01:e35:2f7d:ee00:5db2:74cf:ad11:9df8] (unknown [IPv6:2a01:e35:2f7d:ee00:5db2:74cf:ad11:9df8]) (Authenticated sender: ernstty@yogoko.fr) by mail.yogoko.fr (Postfix) with ESMTPSA id 3CF5EC6802; Tue, 26 Jul 2016 14:56:24 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0640E473-5779-45AA-A17B-3BE251EEAB87" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Thierry Ernst - Bis In-Reply-To: <42bf1cfd-724b-878c-d366-ff00588336b1@htt-consult.com> Date: Tue, 26 Jul 2016 14:56:22 +0200 Message-Id: References: <90a9812d-8f0a-c1f6-49c2-9283da1a1104@htt-consult.com> <42bf1cfd-724b-878c-d366-ff00588336b1@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3124) Archived-At: Cc: William Whyte , Jong-Hyouk Lee , its@ietf.org Subject: Re: [its] V2P - potentially large use case for IPv6 within the DSRC infrastructure X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 12:56:37 -0000 --Apple-Mail=_0640E473-5779-45AA-A17B-3BE251EEAB87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear all, There is a number of standards well advanced at ISO TC204 within WG17 = (nomadic devices) addressing the situation where a nomadic device = (presumably a smart phone) could access to the vehicle information via a = in-vehicle router (gateway between the outside world and the in-vehicle = network).=20 For safety related messages, IP and non-IP can be used alternatively = depending on the type of messages, the transmission range (direct = communication vs via the cloud, broadcast vs pt-to-pt, 1 hop vs = multi-hop, =85), the available radio access technologies and = capabilities of the ITS station. There are indeed much more situations = where IPv6 will be used rather than vehicular WIFI *, although what is = being tested in safety pilots in Europe and US is mostly (exclusively?) = non-IP. For the time being (and this is why a standard defining the use = of IPv6 for vehicular WIFI is needed).=20 The connectivity provided by the nomadic device would probably not be = used for V2X safety messages unless: - the vehicle is not equipped with an in-vehicle router - the in-vehicle router is unable or is not equipped with access = technologies other than 11p (safety channel) In any case, the ITS station architecture (ISO 21217) allows both = possibilities. However, transmission of safety related messages by the = nomadic device would require the nomadic device to be trusted (the = nomadic device must be part of the trusted vehicle domain). * vehicular WIFI =3D IEEE 802.11p variants =3D> ITS-G5 in Europe or = WAVE/DSRC for US - but be aware that for European DSRC has another = meaning =3D> CEN DSRC is 5.8 GHz and used mainly for road tolling).=20 Regards, Thierry Ernst. > Le 21 juil. 2016 =E0 13:56, Robert Moskowitz = a =E9crit : >=20 > Much of it was at ITS World Congress back in 2014 in Detroit. I had a = number of meetings with Honda on their prototypes. They were using a = Nexus phone that Qualcomm had hacked the 11a radio to work for 11p. >=20 >=20 > CAMP may have some internal documents. I can probably reach out to = the Honda people after the 802 meeting if no one else here can = point to any published work. >=20 > On 07/21/2016 01:50 PM, Jong-Hyouk Lee wrote: >> Thx for arising a V2P scenario. If possible, can you give the = pointer?=20 >> -- >> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >> Protocol Engineering Lab., Sangmyung University >>=20 >> #email: jonghyouk@gmail.com >> #webpage: https://sites.google.com/site/hurryon = >>> On Jul 21, 2016, at 8:47 PM, Robert Moskowitz = > wrote: >>>=20 >>> It was submitted to the CAMP pilot RFI. I wrote it with Robert = Hopley over at Verizon, remember him? >>>=20 >>>=20 >>> It was a very similar PKI, but turned a lot of pieces around to work = with phones as clients. The RFI said it was open to other proposals, = they responded to Verizon that they really did not want any other = approaches. >>>=20 >>> I do not have it. Contact Hopley at Verizon and perhaps he can get = it to you. >>>=20 >>> On 07/21/2016 01:42 PM, William Whyte wrote: >>>> Hi Bob, >>>>=20 >>>> Who did Verizon submit that "counter proposal" to and is it = available publicly? I don't remember seeing a specific proposal in the = 1609 working group, or, to be honest, anywhere. >>>>=20 >>>> Cheers, >>>>=20 >>>> William >>>>=20 >>>>=20 >>>> On Thu, Jul 21, 2016 at 7:26 AM, Robert Moskowitz < = rgm-ietf@htt-consult.com = > wrote: >>>> I have seen a number of DSRC/WAVE demonstrations with cell phones = being part of the network for pedestrians and bicycles. Honda also = showed it for motorcycles, but future motorcycles can have an embedded = DSRC device connected to the bike's CANbus for better information. >>>>=20 >>>>=20 >>>> The concern here is that DSRC is already quite congested in many = areas where there are pedestrians and in places near mass-transit = access, and pdestrians walking all over the place, how could a car = listen to all the phones chirping away? >>>>=20 >>>>=20 >>>> Add to this the regulatory challenge of yet another radio on the = phones. Qualcomm has demonstrated a duo radio with standard WiFi and = DSRC, but many just change the radio, switch from the WiFi bands to the = 11p bands and switch back and that has serious performance concerns. >>>>=20 >>>>=20 >>>> So let's keep the phones on IP and route the WAVE messages over IP = to/from the phones. This would use Infrastructure components like = traffic lights as the relays. >>>>=20 >>>>=20 >>>> There is the security question in that is the 1609.2 certificate = that of the phone's or the infrastructure piece? In the former case, = the PKI proposal from CAMP would have major challenges scaling that = large. Of course the counter proposal Verizon submitted ;) could scale = up to certs for all the phones. If the signing is done by the = infrastructure cert which is not a anonymous cert (like in the = vehicles), does this present any privacy issues for the phone holder? = Probably not. >>>>=20 >>>>=20 >>>> But a real potential use case. >>>>=20 >>>>=20 >>>> Bob Moskowitz >>>>=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 = >>=20 >>=20 >>=20 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its = >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_0640E473-5779-45AA-A17B-3BE251EEAB87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Dear all,

There is a number of = standards well advanced at ISO TC204 within WG17 (nomadic devices) = addressing the situation where a nomadic device (presumably a smart = phone) could access to the vehicle information via a in-vehicle router = (gateway between the outside world and the in-vehicle = network). 

For safety related messages, IP and non-IP can be used = alternatively depending on the type of messages, the transmission range = (direct communication vs via the cloud, broadcast vs pt-to-pt, 1 hop vs = multi-hop, =85), the available radio access technologies and = capabilities of the ITS station. There are indeed much more situations = where IPv6 will be used rather than vehicular WIFI *, although what is = being tested in safety pilots in Europe and US is mostly (exclusively?) = non-IP. For the time being (and this is why a standard defining the use = of IPv6 for vehicular WIFI is needed). 

The connectivity provided by the = nomadic device would probably not be used for V2X safety messages = unless:
- the vehicle is not equipped with an = in-vehicle router
- the in-vehicle router is unable = or is not equipped with access technologies other than 11p (safety = channel)

In = any case, the ITS station architecture (ISO 21217) allows both = possibilities. However, transmission of safety related messages by the = nomadic device would require the nomadic device to be trusted (the = nomadic device must be part of the trusted vehicle domain).

* vehicular WIFI =3D = IEEE 802.11p variants =3D>  ITS-G5 in Europe or WAVE/DSRC for US = - but be aware that for European DSRC has another meaning =3D> CEN = DSRC is 5.8 GHz and used mainly for road tolling). 

Regards,
Thierry Ernst.


Le 21 juil. 2016 =E0 13:56, = Robert Moskowitz <rgm-ietf@htt-consult.com> a =E9crit :

=20 =20

Much = of it was at ITS World Congress back in 2014 in Detroit.  I had a number of meetings with Honda on their = prototypes.   They were using a Nexus phone that Qualcomm had hacked the 11a radio to work for 11p.


CAMP may have some internal documents.  I can = probably reach out to the Honda people after the 802 meeting if no one else here can point to any published work.


On 07/21/2016 01:50 PM, Jong-Hyouk = Lee wrote:
Thx for arising a V2P scenario. If possible, can you give the pointer? 
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Jul 21, 2016, at 8:47 PM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:

It was submitted to the CAMP pilot RFI.  I wrote it with Robert Hopley over at Verizon, remember him?


It was a very similar PKI, but turned a = lot of pieces around to work with phones as clients.  The = RFI said it was open to other proposals, they responded to Verizon that they really did not want any other approaches.


I do not have it.  Contact Hopley = at Verizon and perhaps he can get it to you.


On 07/21/2016 01:42 PM, William Whyte wrote:
Hi Bob,

Who did Verizon submit that "counter proposal" to and is it available publicly? I don't remember seeing a specific proposal in the 1609 working group, or, to be honest, anywhere.

Cheers,

William


On Thu, Jul 21, 2016 at = 7:26 AM, Robert Moskowitz <rgm-ietf@htt-consult.com><= /span> wrote:
I have seen a number of DSRC/WAVE demonstrations with cell phones being part of the network for pedestrians and bicycles.  Honda also showed = it for motorcycles, but future motorcycles can have an embedded DSRC device connected to the bike's CANbus for better information.


The concern here is that DSRC is already quite congested in many areas where there are pedestrians and in places near mass-transit access, and pdestrians walking all over the place, how could a car listen to all the phones chirping away?


Add to this the regulatory challenge of yet another radio on the phones.  Qualcomm has demonstrated a duo radio with standard WiFi and DSRC, but many just change the radio, switch from the WiFi bands to the 11p bands and switch back and that has serious performance concerns.


So let's keep the phones on IP and route the WAVE messages over IP to/from the phones.  This = would use Infrastructure components like traffic lights as the relays.


There is the security question in that is the 1609.2 certificate that of the phone's or the infrastructure piece?  In the former case, = the PKI proposal from CAMP would have major challenges scaling that large.  Of course the counter proposal Verizon submitted ;) could scale up to certs for all the phones.   If the = signing is done by the infrastructure cert which is not a anonymous cert (like in the vehicles), does this present any privacy issues for the phone = holder?  Probably not.


But a real potential use case.


Bob Moskowitz


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


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



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

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

= --Apple-Mail=_0640E473-5779-45AA-A17B-3BE251EEAB87-- From nobody Tue Jul 26 08:31:48 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8921912D10B for ; Tue, 26 Jul 2016 08:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.333 X-Spam-Level: X-Spam-Status: No, score=-4.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD0MX4d87n05 for ; Tue, 26 Jul 2016 08:31:42 -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 B182E12D846 for ; Tue, 26 Jul 2016 07:57:44 -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 u6QEvg5v015745 for ; Tue, 26 Jul 2016 16:57:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4647620A07C for ; Tue, 26 Jul 2016 16:57:42 +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 3C26A20A0DA for ; Tue, 26 Jul 2016 16:57:42 +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 u6QEvf6D004551 for ; Tue, 26 Jul 2016 16:57:42 +0200 To: its@ietf.org References: <90a9812d-8f0a-c1f6-49c2-9283da1a1104@htt-consult.com> <42bf1cfd-724b-878c-d366-ff00588336b1@htt-consult.com> From: Alexandre Petrescu Message-ID: <67a2ea0a-0636-6a00-7252-7fa65c0c0cad@gmail.com> Date: Tue, 26 Jul 2016 16:57:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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] V2P - potentially large use case for IPv6 within the DSRC infrastructure X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 15:31:46 -0000 Hi Thierry, Thank you for the message. Le 26/07/2016 à 14:56, Thierry Ernst - Bis a écrit : > > Dear all, > > There is a number of standards well advanced at ISO TC204 within > WG17 (nomadic devices) addressing the situation where a nomadic > device (presumably a smart phone) could access to the vehicle > information via a in-vehicle router (gateway between the outside > world and the in-vehicle network). > > For safety related messages, IP and non-IP can be used alternatively > depending on the type of messages, the transmission range (direct > communication vs via the cloud, broadcast vs pt-to-pt, 1 hop vs > multi-hop, …), the available radio access technologies and > capabilities of the ITS station. There are indeed much more > situations where IPv6 will be used rather than vehicular WIFI *, > although what is being tested in safety pilots in Europe and US is > mostly (exclusively?) non-IP. I would like to answer this question mark. "Pilots" - the current EU "pilot" project opportunities in H2020 IoT are Large Scale Pilots like LSP1, 2 ...5. There are also these "corridors". I am not sure about "safety pilots" though. I will search. These "pilots", as well as earlier EU projects, do indeed represent a majority of what is being publicly demonstrated in vehicular communications, with very much visibility. But there may be a few other EU projects which do exhibit the use of IPv6 on vehicles and with IPv6 RSUs on LTE along roads, directly on 802.11-OCB which may be constructed as we speak, or which may have been demonstrated in less publicized settings. > For the time being (and this is why a standard defining the use of > IPv6 for vehicular WIFI is needed). I agree. > The connectivity provided by the nomadic device would probably not > be used for V2X safety messages unless: - the vehicle is not equipped > with an in-vehicle router - the in-vehicle router is unable or is > not equipped with access technologies other than 11p (safety > channel) And there are also these devices which are installed in the car as after-market. In France it's 'coyote' and in S. Korea it's 'black box'. These devices too can get equipped with other-than-LTE wireless interfaces. Coyote already sends safety warnings as IP messages over GPRS. From there, it's just a small step from sending these warnings over 802.11-OCB or over LTE-V. > In any case, the ITS station architecture (ISO 21217) allows both > possibilities. However, transmission of safety related messages by > the nomadic device would require the nomadic device to be trusted > (the nomadic device must be part of the trusted vehicle domain). I agree. > * vehicular WIFI = IEEE 802.11p variants => ITS-G5 in Europe or > WAVE/DSRC for US - but be aware that for European DSRC has another > meaning => CEN DSRC is 5.8 GHz and used mainly for road tolling). Right, the DSRC term is highly overloaded: 'DSRC' means PHY and MAC layer when defined by ASTM E2213 - 03(2010). 'DSRC' means application layer when defined by SAE J2735_201603. 'DSRC' means other particular PHY/MAC/app-layer by CEN/TC278. 'DSRC' is _not_ defined by IEEE. The 5.8GHz you mention is near the 5.875-5.925GHz of ITS? The "road tolling" is what CEN document? "Road tolling" in France can be assimilated with "portiques" to count truck passage in some areas, which has seen social debate and waits now for a renewed goal. "Road tolling" can also be assimilated with these "péage" - a place to pay when entering or exit a highway; in France it's 30km/h max speed, but in Japan it's 50km/h or more. I am not sure which of these two "road tolling" you mean. Finally, in some countries the same "road tolling" devices used to enter the highway have been deployed to enter parking spaces; this has had some success, but nowadays the fashion comes from smartphones doing this "road tolling" in parkings, with new apps everyone can write on TCP/IP. This is a replacement of dedicated tolling devices with more generic devices like smartphones equipped with NFC. Alex > > Regards, Thierry Ernst. > > >> Le 21 juil. 2016 à 13:56, Robert Moskowitz >> > a >> écrit : >> >> Much of it was at ITS World Congress back in 2014 in Detroit. I >> had a number of meetings with Honda on their prototypes. They >> were using a Nexus phone that Qualcomm had hacked the 11a radio to >> work for 11p. >> >> >> CAMP may have some internal documents. I can probably reach out >> to the Honda people after the 802 meeting if no one else here can >> point to any published work. >> >> >> On 07/21/2016 01:50 PM, Jong-Hyouk Lee wrote: >>> Thx for arising a V2P scenario. If possible, can you give the >>> pointer? -- Jong-Hyouk Lee, living somewhere between /dev/null >>> and /dev/random Protocol Engineering Lab., Sangmyung University >>> >>> #email: jonghyouk@gmail.com >>> #webpage: https://sites.google.com/site/hurryon >>> >>>> On Jul 21, 2016, at 8:47 PM, Robert Moskowitz >>>> > >>>> wrote: >>>> >>>> It was submitted to the CAMP pilot RFI. I wrote it with >>>> Robert Hopley over at Verizon, remember him? >>>> >>>> >>>> It was a very similar PKI, but turned a lot of pieces around to >>>> work with phones as clients. The RFI said it was open to other >>>> proposals, they responded to Verizon that they really did not >>>> want any other approaches. >>>> >>>> >>>> I do not have it. Contact Hopley at Verizon and perhaps he can >>>> get it to you. >>>> >>>> >>>> On 07/21/2016 01:42 PM, William Whyte wrote: >>>>> Hi Bob, >>>>> >>>>> Who did Verizon submit that "counter proposal" to and is it >>>>> available publicly? I don't remember seeing a specific >>>>> proposal in the 1609 working group, or, to be honest, >>>>> anywhere. >>>>> >>>>> Cheers, >>>>> >>>>> William >>>>> >>>>> >>>>> On Thu, Jul 21, 2016 at 7:26 AM, Robert Moskowitz >>>>> <rgm-ietf@htt-consult.com> >>>>> wrote: >>>>> >>>>> I have seen a number of DSRC/WAVE demonstrations with cell >>>>> phones being part of the network for pedestrians and >>>>> bicycles. Honda also showed it for motorcycles, but future >>>>> motorcycles can have an embedded DSRC device connected to the >>>>> bike's CANbus for better information. >>>>> >>>>> >>>>> The concern here is that DSRC is already quite congested in >>>>> many areas where there are pedestrians and in places near >>>>> mass-transit access, and pdestrians walking all over the >>>>> place, how could a car listen to all the phones chirping >>>>> away? >>>>> >>>>> >>>>> Add to this the regulatory challenge of yet another radio on >>>>> the phones. Qualcomm has demonstrated a duo radio with >>>>> standard WiFi and DSRC, but many just change the radio, >>>>> switch from the WiFi bands to the 11p bands and switch back >>>>> and that has serious performance concerns. >>>>> >>>>> >>>>> So let's keep the phones on IP and route the WAVE messages >>>>> over IP to/from the phones. This would use Infrastructure >>>>> components like traffic lights as the relays. >>>>> >>>>> >>>>> There is the security question in that is the 1609.2 >>>>> certificate that of the phone's or the infrastructure piece? >>>>> In the former case, the PKI proposal from CAMP would have >>>>> major challenges scaling that large. Of course the counter >>>>> proposal Verizon submitted ;) could scale up to certs for all >>>>> the phones. If the signing is done by the infrastructure >>>>> cert which is not a anonymous cert (like in the vehicles), >>>>> does this present any privacy issues for the phone holder? >>>>> Probably not. >>>>> >>>>> >>>>> But a real potential use case. >>>>> >>>>> >>>>> Bob Moskowitz >>>>> >>>>> >>>>> _______________________________________________ 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 > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Tue Jul 26 08:46:08 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E515212DCC2 for ; Tue, 26 Jul 2016 08:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 4nFDMvsFO-r7 for ; Tue, 26 Jul 2016 08:46:02 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 583CF12DD43 for ; Tue, 26 Jul 2016 08:16:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D659762218; Tue, 26 Jul 2016 11:16:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31Ef7AuCkitX; Tue, 26 Jul 2016 11:16:06 -0400 (EDT) Received: from lx120e.htt-consult.com (66.238.57.130.ptr.us.xo.net [66.238.57.130]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id C37BA62216; Tue, 26 Jul 2016 11:16:04 -0400 (EDT) To: Thierry Ernst - Bis References: <90a9812d-8f0a-c1f6-49c2-9283da1a1104@htt-consult.com> <42bf1cfd-724b-878c-d366-ff00588336b1@htt-consult.com> From: Robert Moskowitz Message-ID: Date: Tue, 26 Jul 2016 08:16:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D6A7B1D5A6839F485AEB0507" Archived-At: Cc: William Whyte , Jong-Hyouk Lee , its@ietf.org Subject: Re: [its] V2P - potentially large use case for IPv6 within the DSRC infrastructure X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 15:46:07 -0000 This is a multi-part message in MIME format. --------------D6A7B1D5A6839F485AEB0507 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Whereas I am talking about true pedestrian situations. Well cyclists as well. When I was at Verizon, there was a smallish group looking into how pedestrians would participate. One approach was a WAVE app with a 1609.2 identity/certificate to trust the phone app. This was the simple part, the harder part was the communication path. You could work out how a phone would communicate to infrastructure that would forward messages. The open item was the other direction: how does the phone get vehicle generated messages. On 07/26/2016 05:56 AM, Thierry Ernst - Bis wrote: > > Dear all, > > There is a number of standards well advanced at ISO TC204 within WG17 > (nomadic devices) addressing the situation where a nomadic device > (presumably a smart phone) could access to the vehicle information via > a in-vehicle router (gateway between the outside world and the > in-vehicle network). > > For safety related messages, IP and non-IP can be used alternatively > depending on the type of messages, the transmission range (direct > communication vs via the cloud, broadcast vs pt-to-pt, 1 hop vs > multi-hop, …), the available radio access technologies and > capabilities of the ITS station. There are indeed much more situations > where IPv6 will be used rather than vehicular WIFI *, although what is > being tested in safety pilots in Europe and US is mostly > (exclusively?) non-IP. For the time being (and this is why a standard > defining the use of IPv6 for vehicular WIFI is needed). > > The connectivity provided by the nomadic device would probably not be > used for V2X safety messages unless: > - the vehicle is not equipped with an in-vehicle router > - the in-vehicle router is unable or is not equipped with access > technologies other than 11p (safety channel) > > In any case, the ITS station architecture (ISO 21217) allows both > possibilities. However, transmission of safety related messages by the > nomadic device would require the nomadic device to be trusted (the > nomadic device must be part of the trusted vehicle domain). > > * vehicular WIFI = IEEE 802.11p variants => ITS-G5 in Europe or > WAVE/DSRC for US - but be aware that for European DSRC has another > meaning => CEN DSRC is 5.8 GHz and used mainly for road tolling). > > Regards, > Thierry Ernst. > > >> Le 21 juil. 2016 à 13:56, Robert Moskowitz > > a écrit : >> >> Much of it was at ITS World Congress back in 2014 in Detroit. I had >> a number of meetings with Honda on their prototypes. They were >> using a Nexus phone that Qualcomm had hacked the 11a radio to work >> for 11p. >> >> >> CAMP may have some internal documents. I can probably reach out to >> the Honda people after the 802 meeting if no one else here can point >> to any published work. >> >> >> On 07/21/2016 01:50 PM, Jong-Hyouk Lee wrote: >>> Thx for arising a V2P scenario. If possible, can you give the pointer? >>> -- >>> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >>> Protocol Engineering Lab., Sangmyung University >>> >>> #email: jonghyouk@gmail.com >>> #webpage: https://sites.google.com/site/hurryon >>> >>>> On Jul 21, 2016, at 8:47 PM, Robert Moskowitz >>>> > wrote: >>>> >>>> It was submitted to the CAMP pilot RFI. I wrote it with Robert >>>> Hopley over at Verizon, remember him? >>>> >>>> >>>> It was a very similar PKI, but turned a lot of pieces around to >>>> work with phones as clients. The RFI said it was open to other >>>> proposals, they responded to Verizon that they really did not want >>>> any other approaches. >>>> >>>> >>>> I do not have it. Contact Hopley at Verizon and perhaps he can get >>>> it to you. >>>> >>>> >>>> On 07/21/2016 01:42 PM, William Whyte wrote: >>>>> Hi Bob, >>>>> >>>>> Who did Verizon submit that "counter proposal" to and is it >>>>> available publicly? I don't remember seeing a specific proposal in >>>>> the 1609 working group, or, to be honest, anywhere. >>>>> >>>>> Cheers, >>>>> >>>>> William >>>>> >>>>> >>>>> On Thu, Jul 21, 2016 at 7:26 AM, Robert Moskowitz >>>>> wrote: >>>>> >>>>> I have seen a number of DSRC/WAVE demonstrations with cell >>>>> phones being part of the network for pedestrians and bicycles. >>>>> Honda also showed it for motorcycles, but future motorcycles >>>>> can have an embedded DSRC device connected to the bike's >>>>> CANbus for better information. >>>>> >>>>> >>>>> The concern here is that DSRC is already quite congested in >>>>> many areas where there are pedestrians and in places near >>>>> mass-transit access, and pdestrians walking all over the >>>>> place, how could a car listen to all the phones chirping away? >>>>> >>>>> >>>>> Add to this the regulatory challenge of yet another radio on >>>>> the phones. Qualcomm has demonstrated a duo radio with >>>>> standard WiFi and DSRC, but many just change the radio, switch >>>>> from the WiFi bands to the 11p bands and switch back and that >>>>> has serious performance concerns. >>>>> >>>>> >>>>> So let's keep the phones on IP and route the WAVE messages >>>>> over IP to/from the phones. This would use Infrastructure >>>>> components like traffic lights as the relays. >>>>> >>>>> >>>>> There is the security question in that is the 1609.2 >>>>> certificate that of the phone's or the infrastructure piece? >>>>> In the former case, the PKI proposal from CAMP would have >>>>> major challenges scaling that large. Of course the counter >>>>> proposal Verizon submitted ;) could scale up to certs for all >>>>> the phones. If the signing is done by the infrastructure >>>>> cert which is not a anonymous cert (like in the vehicles), >>>>> does this present any privacy issues for the phone holder? >>>>> Probably not. >>>>> >>>>> >>>>> But a real potential use case. >>>>> >>>>> >>>>> Bob Moskowitz >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > --------------D6A7B1D5A6839F485AEB0507 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Whereas I am talking about true pedestrian situations.  Well cyclists as well.


When I was at Verizon, there was a smallish group looking into how pedestrians would participate.  One approach was a WAVE app with a 1609.2 identity/certificate to trust the phone app.  This was the simple part, the harder part was the communication path.  You could work out how a phone would communicate to infrastructure that would forward messages.  The open item was the other direction:  how does the phone get vehicle generated messages.


On 07/26/2016 05:56 AM, Thierry Ernst - Bis wrote:

Dear all,

There is a number of standards well advanced at ISO TC204 within WG17 (nomadic devices) addressing the situation where a nomadic device (presumably a smart phone) could access to the vehicle information via a in-vehicle router (gateway between the outside world and the in-vehicle network). 

For safety related messages, IP and non-IP can be used alternatively depending on the type of messages, the transmission range (direct communication vs via the cloud, broadcast vs pt-to-pt, 1 hop vs multi-hop, …), the available radio access technologies and capabilities of the ITS station. There are indeed much more situations where IPv6 will be used rather than vehicular WIFI *, although what is being tested in safety pilots in Europe and US is mostly (exclusively?) non-IP. For the time being (and this is why a standard defining the use of IPv6 for vehicular WIFI is needed). 

The connectivity provided by the nomadic device would probably not be used for V2X safety messages unless:
- the vehicle is not equipped with an in-vehicle router
- the in-vehicle router is unable or is not equipped with access technologies other than 11p (safety channel)

In any case, the ITS station architecture (ISO 21217) allows both possibilities. However, transmission of safety related messages by the nomadic device would require the nomadic device to be trusted (the nomadic device must be part of the trusted vehicle domain).

* vehicular WIFI = IEEE 802.11p variants =>  ITS-G5 in Europe or WAVE/DSRC for US - but be aware that for European DSRC has another meaning => CEN DSRC is 5.8 GHz and used mainly for road tolling). 

Regards,
Thierry Ernst.


Le 21 juil. 2016 à 13:56, Robert Moskowitz <rgm-ietf@htt-consult.com> a écrit :

Much of it was at ITS World Congress back in 2014 in Detroit.  I had a number of meetings with Honda on their prototypes.   They were using a Nexus phone that Qualcomm had hacked the 11a radio to work for 11p.


CAMP may have some internal documents.  I can probably reach out to the Honda people after the 802 meeting if no one else here can point to any published work.


On 07/21/2016 01:50 PM, Jong-Hyouk Lee wrote:
Thx for arising a V2P scenario. If possible, can you give the pointer? 
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Jul 21, 2016, at 8:47 PM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:

It was submitted to the CAMP pilot RFI.  I wrote it with Robert Hopley over at Verizon, remember him?


It was a very similar PKI, but turned a lot of pieces around to work with phones as clients.  The RFI said it was open to other proposals, they responded to Verizon that they really did not want any other approaches.


I do not have it.  Contact Hopley at Verizon and perhaps he can get it to you.


On 07/21/2016 01:42 PM, William Whyte wrote:
Hi Bob,

Who did Verizon submit that "counter proposal" to and is it available publicly? I don't remember seeing a specific proposal in the 1609 working group, or, to be honest, anywhere.

Cheers,

William


On Thu, Jul 21, 2016 at 7:26 AM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
I have seen a number of DSRC/WAVE demonstrations with cell phones being part of the network for pedestrians and bicycles.  Honda also showed it for motorcycles, but future motorcycles can have an embedded DSRC device connected to the bike's CANbus for better information.


The concern here is that DSRC is already quite congested in many areas where there are pedestrians and in places near mass-transit access, and pdestrians walking all over the place, how could a car listen to all the phones chirping away?


Add to this the regulatory challenge of yet another radio on the phones.  Qualcomm has demonstrated a duo radio with standard WiFi and DSRC, but many just change the radio, switch from the WiFi bands to the 11p bands and switch back and that has serious performance concerns.


So let's keep the phones on IP and route the WAVE messages over IP to/from the phones.  This would use Infrastructure components like traffic lights as the relays.


There is the security question in that is the 1609.2 certificate that of the phone's or the infrastructure piece?  In the former case, the PKI proposal from CAMP would have major challenges scaling that large.  Of course the counter proposal Verizon submitted ;) could scale up to certs for all the phones.   If the signing is done by the infrastructure cert which is not a anonymous cert (like in the vehicles), does this present any privacy issues for the phone holder?  Probably not.


But a real potential use case.


Bob Moskowitz


_______________________________________________
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


--------------D6A7B1D5A6839F485AEB0507-- From nobody Tue Jul 26 09:11: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 8FC0412D8A2 for ; Tue, 26 Jul 2016 09:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 MB4tA0hho_cr for ; Tue, 26 Jul 2016 09:11:06 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 6A51512DC45 for ; Tue, 26 Jul 2016 09:00:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id ECB0862239; Tue, 26 Jul 2016 12:00:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OABt52uwBgeY; Tue, 26 Jul 2016 12:00:33 -0400 (EDT) Received: from lx120e.htt-consult.com (66.238.57.130.ptr.us.xo.net [66.238.57.130]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 7646162238; Tue, 26 Jul 2016 12:00:32 -0400 (EDT) To: Alexandre Petrescu , its@ietf.org References: <90a9812d-8f0a-c1f6-49c2-9283da1a1104@htt-consult.com> <42bf1cfd-724b-878c-d366-ff00588336b1@htt-consult.com> <67a2ea0a-0636-6a00-7252-7fa65c0c0cad@gmail.com> From: Robert Moskowitz Message-ID: Date: Tue, 26 Jul 2016 09:00:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <67a2ea0a-0636-6a00-7252-7fa65c0c0cad@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] V2P - potentially large use case for IPv6 within the DSRC infrastructure X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 16:11:08 -0000 On 07/26/2016 07:57 AM, Alexandre Petrescu wrote: > Hi Thierry, > > Thank you for the message. > > Le 26/07/2016 à 14:56, Thierry Ernst - Bis a écrit : >> >> Dear all, >> >> There is a number of standards well advanced at ISO TC204 within >> WG17 (nomadic devices) addressing the situation where a nomadic >> device (presumably a smart phone) could access to the vehicle >> information via a in-vehicle router (gateway between the outside >> world and the in-vehicle network). >> >> For safety related messages, IP and non-IP can be used alternatively >> depending on the type of messages, the transmission range (direct >> communication vs via the cloud, broadcast vs pt-to-pt, 1 hop vs >> multi-hop, …), the available radio access technologies and >> capabilities of the ITS station. There are indeed much more >> situations where IPv6 will be used rather than vehicular WIFI *, >> although what is being tested in safety pilots in Europe and US is >> mostly (exclusively?) non-IP. > > I would like to answer this question mark. > > "Pilots" - the current EU "pilot" project opportunities in H2020 IoT are > Large Scale Pilots like LSP1, 2 ...5. There are also these "corridors". > I am not sure about "safety pilots" though. I will search. > > These "pilots", as well as earlier EU projects, do indeed represent a > majority of what is being publicly demonstrated in vehicular > communications, with very much visibility. > > But there may be a few other EU projects which do exhibit the use of > IPv6 on vehicles and with IPv6 RSUs on LTE along roads, directly on > 802.11-OCB which may be constructed as we speak, or which may have been > demonstrated in less publicized settings. > >> For the time being (and this is why a standard defining the use of >> IPv6 for vehicular WIFI is needed). > > I agree. > >> The connectivity provided by the nomadic device would probably not >> be used for V2X safety messages unless: - the vehicle is not equipped >> with an in-vehicle router - the in-vehicle router is unable or is >> not equipped with access technologies other than 11p (safety >> channel) > > And there are also these devices which are installed in the car as > after-market. In France it's 'coyote' and in S. Korea it's 'black box'. > These devices too can get equipped with other-than-LTE wireless > interfaces. > > Coyote already sends safety warnings as IP messages over GPRS. From > there, it's just a small step from sending these warnings over > 802.11-OCB or over LTE-V. > >> In any case, the ITS station architecture (ISO 21217) allows both >> possibilities. However, transmission of safety related messages by >> the nomadic device would require the nomadic device to be trusted >> (the nomadic device must be part of the trusted vehicle domain). > > I agree. > >> * vehicular WIFI = IEEE 802.11p variants => ITS-G5 in Europe or >> WAVE/DSRC for US - but be aware that for European DSRC has another >> meaning => CEN DSRC is 5.8 GHz and used mainly for road tolling). > > Right, the DSRC term is highly overloaded: > > 'DSRC' means PHY and MAC layer when defined by ASTM E2213 - 03(2010). > 'DSRC' means application layer when defined by SAE J2735_201603. > 'DSRC' means other particular PHY/MAC/app-layer by CEN/TC278. > 'DSRC' is _not_ defined by IEEE. > > The 5.8GHz you mention is near the 5.875-5.925GHz of ITS? > The "road tolling" is what CEN document? > > "Road tolling" in France can be assimilated with "portiques" to count > truck passage in some areas, which has seen social debate and waits now > for a renewed goal. > > "Road tolling" can also be assimilated with these "péage" - a place to > pay when entering or exit a highway; in France it's 30km/h max speed, > but in Japan it's 50km/h or more. 1609.11-2010 is: IEEE Standard for Wireless Access in Vehicular Environments (WAVE)— Over-the-Air Electronic Payment Data Exchange Protocol for Intelligent Transportation Systems (ITS) In otherwords: Road tolling. > > I am not sure which of these two "road tolling" you mean. > > Finally, in some countries the same "road tolling" devices used to enter > the highway have been deployed to enter parking spaces; this has had > some success, but nowadays the fashion comes from smartphones doing this > "road tolling" in parkings, with new apps everyone can write on TCP/IP. > This is a replacement of dedicated tolling devices with more generic > devices like smartphones equipped with NFC. > > Alex > > >> >> Regards, Thierry Ernst. >> >> >>> Le 21 juil. 2016 à 13:56, Robert Moskowitz >>> > a >>> écrit : >>> >>> Much of it was at ITS World Congress back in 2014 in Detroit. I >>> had a number of meetings with Honda on their prototypes. They >>> were using a Nexus phone that Qualcomm had hacked the 11a radio to >>> work for 11p. >>> >>> >>> CAMP may have some internal documents. I can probably reach out >>> to the Honda people after the 802 meeting if no one else here can >>> point to any published work. >>> >>> >>> On 07/21/2016 01:50 PM, Jong-Hyouk Lee wrote: >>>> Thx for arising a V2P scenario. If possible, can you give the >>>> pointer? -- Jong-Hyouk Lee, living somewhere between /dev/null >>>> and /dev/random Protocol Engineering Lab., Sangmyung University >>>> >>>> #email: jonghyouk@gmail.com >>>> #webpage: https://sites.google.com/site/hurryon >>>> >>>>> On Jul 21, 2016, at 8:47 PM, Robert Moskowitz >>>>> > >>>>> wrote: >>>>> >>>>> It was submitted to the CAMP pilot RFI. I wrote it with >>>>> Robert Hopley over at Verizon, remember him? >>>>> >>>>> >>>>> It was a very similar PKI, but turned a lot of pieces around to >>>>> work with phones as clients. The RFI said it was open to other >>>>> proposals, they responded to Verizon that they really did not >>>>> want any other approaches. >>>>> >>>>> >>>>> I do not have it. Contact Hopley at Verizon and perhaps he can >>>>> get it to you. >>>>> >>>>> >>>>> On 07/21/2016 01:42 PM, William Whyte wrote: >>>>>> Hi Bob, >>>>>> >>>>>> Who did Verizon submit that "counter proposal" to and is it >>>>>> available publicly? I don't remember seeing a specific >>>>>> proposal in the 1609 working group, or, to be honest, >>>>>> anywhere. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> William >>>>>> >>>>>> >>>>>> On Thu, Jul 21, 2016 at 7:26 AM, Robert Moskowitz >>>>>> <rgm-ietf@htt-consult.com> >>>>>> wrote: >>>>>> >>>>>> I have seen a number of DSRC/WAVE demonstrations with cell >>>>>> phones being part of the network for pedestrians and >>>>>> bicycles. Honda also showed it for motorcycles, but future >>>>>> motorcycles can have an embedded DSRC device connected to the >>>>>> bike's CANbus for better information. >>>>>> >>>>>> >>>>>> The concern here is that DSRC is already quite congested in >>>>>> many areas where there are pedestrians and in places near >>>>>> mass-transit access, and pdestrians walking all over the >>>>>> place, how could a car listen to all the phones chirping >>>>>> away? >>>>>> >>>>>> >>>>>> Add to this the regulatory challenge of yet another radio on >>>>>> the phones. Qualcomm has demonstrated a duo radio with >>>>>> standard WiFi and DSRC, but many just change the radio, >>>>>> switch from the WiFi bands to the 11p bands and switch back >>>>>> and that has serious performance concerns. >>>>>> >>>>>> >>>>>> So let's keep the phones on IP and route the WAVE messages >>>>>> over IP to/from the phones. This would use Infrastructure >>>>>> components like traffic lights as the relays. >>>>>> >>>>>> >>>>>> There is the security question in that is the 1609.2 >>>>>> certificate that of the phone's or the infrastructure piece? >>>>>> In the former case, the PKI proposal from CAMP would have >>>>>> major challenges scaling that large. Of course the counter >>>>>> proposal Verizon submitted ;) could scale up to certs for all >>>>>> the phones. If the signing is done by the infrastructure >>>>>> cert which is not a anonymous cert (like in the vehicles), >>>>>> does this present any privacy issues for the phone holder? >>>>>> Probably not. >>>>>> >>>>>> >>>>>> But a real potential use case. >>>>>> >>>>>> >>>>>> Bob Moskowitz >>>>>> >>>>>> >>>>>> _______________________________________________ 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 >> >> >> >> _______________________________________________ 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 Jul 26 11:31:28 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5959F12D8D3 for ; Tue, 26 Jul 2016 11:31:27 -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 sUZC3g5dXd8V for ; Tue, 26 Jul 2016 11:31:13 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001: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 4006112D8D4 for ; Tue, 26 Jul 2016 11:31:13 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id m101so35249581ioi.2 for ; Tue, 26 Jul 2016 11:31:13 -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:from:date:message-id:subject:to :cc; bh=ZFqLnxXf1kfWzEQPQm23jlIf6Vfp18pFQGe5OxjltEc=; b=o6zrVGpA+Jf9y2TSF/LVXYvaIN2FjTfHOpwTrMcWtiX9teOjKS2HOpBwDkRXhlU8O0 MfdyLOvPKeyAwDqPuCpzDonf/4Ec6hMVlRXEr1mgZLNvKGDyhV4f/pPR9CZzggRsslUV wZP+WqFbYRJ0ct8nsPZpbI1uMAJko5EY2+zhUqHMx9+ZFjfp8IEXYs2W2I7Sdovq8jYN JeEXA6Hs79y5h/a4FzY9F9YuaQyGqqpTzIF869Jp2XmY7wOUuXge6kAHmo7PyKHCN/W/ mib6mLmtSQOiqqqErsmQ8UP3TJT7YHgdlWRTPMskQxieWxTwAiO6YjdYlAoYDkRbbFOt qBtg== 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=ZFqLnxXf1kfWzEQPQm23jlIf6Vfp18pFQGe5OxjltEc=; b=E6KiCLZ1HAi4ifGhxC/a3gpq2qtxx1VntDdhXo/pJPzC8dNlbyEPiy5ZoudN//xGWT oHNy0v2UzBsVHQMIjyNWLDvDwDBhFId1S/6U4YcIF9UEcW6Qo4SoYQRn5+Pl5naXqHNZ rYmncyHDZZZHpq6evx59b9SBtAxfmMJJJOORn8G3194Bev8eyp9uVR0631ymF4UeKYR8 08O5b4LSBNk9T3av3j/GuW0Ix544t0Hqazgl8GuzYOzAFmbc8QoxqjaD+tzxD021qObZ L3ONpczHF3meRx1ILua+p2Sbi0qG85bt3hR3l70NpJoglDyQO5TaMcPJBLD/QmfHxLTC 5o9A== X-Gm-Message-State: AEkoousbdY4WkHKgn1pdWOrvfE1COJfAYdzRTa9JHECFL+2FPRuMITUYKvZaieB8xTGMveQCvio7QAEhomV2JHmc X-Received: by 10.202.204.16 with SMTP id c16mr12387490oig.138.1469557871523; Tue, 26 Jul 2016 11:31:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.33.26 with HTTP; Tue, 26 Jul 2016 11:31:10 -0700 (PDT) In-Reply-To: <5c4c4684-a3bf-f208-b6ed-1bd9bbf052b2@htt-consult.com> References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> <7e2d1572-9333-7d74-30ad-c47cd0d8512f@htt-consult.com> <7234D8CC1B664F878FAA845C4061AD7C@china.huawei.com> <4d95a92d-6dad-2ee5-5a41-70c8b9d11397@fischer-tech.eu> <5c4c4684-a3bf-f208-b6ed-1bd9bbf052b2@htt-consult.com> From: John Kenney Date: Tue, 26 Jul 2016 11:31:10 -0700 Message-ID: To: Robert Moskowitz Content-Type: multipart/alternative; boundary=001a1134fde8e8f6da05388e1ac9 Archived-At: Cc: "Dr. Hans-Joachim Fischer" , H Anthony Chan , Russ Housley , "its@ietf.org" Subject: Re: [its] Charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 18:31:27 -0000 --001a1134fde8e8f6da05388e1ac9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Given that the standards are not yet developed and the stated goal of the exercise is to provide "input to the standards specification," I think "experiment" might be more accurate than "trial". Definitely not deployment, and definitely not a trial with thousands of vehicles. John --=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 On Mon, Jul 25, 2016 at 2:34 PM, Robert Moskowitz wrote: > One can argue that it is an example of what a deployment would be like. > Just like the various DSRC testbeds with some thousands of enabled vehicl= es. > > :) > > > > On 07/25/2016 07:57 AM, Dr. Hans-Joachim Fischer wrote: > > > Sorry! > > Deployment? I read "trial". It cannot be more. > > > Hans-Joachim > > Am 25.07.2016 um 16:35 schrieb H Anthony Chan: > > The following is an example of deployment : > > > > http://www.rcrwireless.com/20160712/connected-cars-2/dt-huawei-audi-toyot= a-carry-lte-v-trials-germany > > > > DT, Huawei, Audi and Toyota carry out LTE-V trials in Germany > German telco said LTE-V is a potential enabler for road safety and traffi= c > efficiency apps > > German telecom operator Deutsche Telekom, Chinese vendor Huawei and car > makers including Audi and Toyota are currently testing LTE-Vehicular in > Germany. > > The German telco said that technical tests are underway on this connected > vehicles technology, which is seen as a potential enabler for road safety > and traffic efficiency applications. The partners are conducting these > trials on a section of the =E2=80=9Cdigital A9 motorway test bed=E2=80=9D= near Ingolstadt, > Germany. > > LTE-V is a variant of 4G LTE technology. It is being specified within the > European 3GPP project that develops telecommunications standards as part = of > its Release 14. This variant is specifically designed to meet automotive > requirements for both vehicle-to-vehicle and vehicle-to-infrastructure > communication. LTE-V can address multiple application types ranging from > connected vehicle safety applications =E2=80=93 collision warning, pedest= rian > warning, etc. =E2=80=93 to connected vehicle smart mobility applications = for > increased efficiency. > > Deutsche Telekom infrastructure has been specially equipped with LTE-V > hardware from Huawei to support the trial scenarios. Audi, Toyota and oth= er > car manufacturers have equipped research cars with the LTE-V hardware > developed by Huawei. Based on the trial results, the partners will provid= e > input to the standards specifications for LTE-V. > > H Anthony Chan > > > _______________________________________________ > its mailing listits@ietf.orghttps://www.ietf.org/mailman/listinfo/its > > > -- > Dr. Hans-Joachim Fischer > Managing Director > > > -------------------------------------------------------------------------= ------ > > Seminars on Cooperative Intelligent Transport Systems > http://fischer-tech.eu/Feeds/CITSseminars.html > > -------------------------------------------------------------------------= ------ > + + + Instaurare omnia in Christo + + + > -------------------------------------------------------------------------= ------ > The information contained in this message is confidential and may be lega= lly > privileged. This email is intended for the addressee(s). Addressees may b= e > 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 attachement= s is > strictly prohibited and may be unlawful. If you are not an addressee, ple= ase > contact the sender by return e-mail and destroy all copies of the origina= l > 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 Gmb= Hhttp://its-standards.eu : News on cooperative ITS standardizationhttp://it= s-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 > -------------------------------------------------------------------------= ------ > > > > _______________________________________________ > its mailing listits@ietf.orghttps://www.ietf.org/mailman/listinfo/its > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --001a1134fde8e8f6da05388e1ac9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Given that the standards are not yet developed and the sta= ted goal of the exercise is to provide "input to the standards specifi= cation," I think "experiment" might be more accurate than &q= uot;trial". Definitely not deployment, and definitely not a trial with= thousands of vehicles.

John

--=C2=A0
John Kenney
Dire= ctor and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Te= l: 650-694-4160. Mobile: 650-224-6644


On Mon, Jul 25, 2016 at 2:34 PM, Rober= t Moskowitz <rgm-ietf@htt-consult.com> wrote:
=20 =20 =20

One can argue that it is an example of what a deployment would be like.=C2=A0 Just like the various DSRC testbeds with some thousands o= f enabled vehicles.


:)



On 07/25/2016 07:57 AM, Dr. Hans-Joachim Fischer wrote:
=20


Sorry!

Deployment? I read "trial". It cannot be more.


Hans-Joachim


Am 25.07.2016 um 16:35 schrieb H Anthony Chan:
=20
The following is an example of deployment :
=C2=A0

http://= www.rcrwireless.com/20160712/connected-cars-2/dt-huawei-audi-toyota-carry-l= te-v-trials-germany

=C2=A0

= DT, Huawei, Audi and Toyota carry out LTE-V trials in Germany

German telco said LTE-V is a potential enabler for road safety and traffic efficiency apps

German telecom operator Deutsche Telekom, Chinese vendor Huawei and car makers including Audi and Toyota are currently testing LTE-Vehicular in Germany.

The German telco said that technical tests are underway on this connected vehicles technology, which is seen as a potential enabler for road safety and traffic efficiency applications. The partners are conducting these trials on a section of the =E2=80=9Cdigital A9 motorway test bed=E2=80=9D near Ingolstadt, Germany.

LTE-V is a variant of 4G LTE technology. It is being specified within the European 3GPP project that develops telecommunications standards as part of its Release 14. This variant is specifically designed to meet automotive requirements for both vehicle-to-vehicle and vehicle-to-infrastructure communication. LTE-V can address multiple application types ranging from connected vehicle safety applications =E2=80=93 collision warning, pedest= rian warning, etc. =E2=80=93 to connected vehicle smart mobi= lity applications for increased efficiency.

Deutsche Telekom infrastructure has been specially equipped with LTE-V hardware from Huawei to support the trial scenarios. Audi, Toyota and other car manufacturers have equipped research cars with the LTE-V hardware developed by Huawei. Based on the trial results, the partners will provide input to the standards specifications for LTE-V.

H Anthony Chan



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


--=20
Dr. Hans-Joachim Fischer
Managing Director


---------------------------------------------------------------------------=
----=20

         Seminars on Cooperative Intelligent Transport Systems
             http://fischer-tech.eu/Feeds/CITSseminars.html

---------------------------------------------------------------------------=
----=20
+ + + Instaurare omnia in Christo + + +
---------------------------------------------------------------------------=
----=20
The information contained in this message is confidential and may be legall=
y=20
privileged. This email is intended for the addressee(s). Addressees may be=
=20
individual persons or members of mailing list.=20
If you are not an addressee, you are hereby notified that any use,=20
dissemination, or reproduction of this email and its optional attachements =
is=20
strictly prohibited and may be unlawful. If you are not an addressee, pleas=
e=20
contact the sender by return e-mail and destroy all copies of the original=
=20
message.=20
---------------------------------------------------------------------------=
----=20
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
---------------------------------------------------------------------------=
----=20

---------------------------------------------------------------------------=
----=20
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
---------------------------------------------------------------------------=
----



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


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



--001a1134fde8e8f6da05388e1ac9-- From nobody Tue Jul 26 12:09:56 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F196512D130 for ; Tue, 26 Jul 2016 12:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 luSQ3xUfWJ9X for ; Tue, 26 Jul 2016 12:09:52 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 DD2F712B075 for ; Tue, 26 Jul 2016 12:09:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4E4326224B; Tue, 26 Jul 2016 15:09:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bo4JGa5MKsI2; Tue, 26 Jul 2016 15:09:40 -0400 (EDT) Received: from lx120e.htt-consult.com (66.238.57.130.ptr.us.xo.net [66.238.57.130]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id D8C2862239; Tue, 26 Jul 2016 15:09:38 -0400 (EDT) To: John Kenney References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> <7e2d1572-9333-7d74-30ad-c47cd0d8512f@htt-consult.com> <7234D8CC1B664F878FAA845C4061AD7C@china.huawei.com> <4d95a92d-6dad-2ee5-5a41-70c8b9d11397@fischer-tech.eu> <5c4c4684-a3bf-f208-b6ed-1bd9bbf052b2@htt-consult.com> From: Robert Moskowitz Message-ID: <3ab766e1-1c5c-4910-f2fb-7f14f3071f77@htt-consult.com> Date: Tue, 26 Jul 2016 12:09:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1857E5BB05F86C37FF2592F0" Archived-At: Cc: "Dr. Hans-Joachim Fischer" , H Anthony Chan , Russ Housley , "its@ietf.org" Subject: Re: [its] Charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 19:09:55 -0000 This is a multi-part message in MIME format. --------------1857E5BB05F86C37FF2592F0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I was going by 'press' statements. I should have checked with you first about the reality... On 07/26/2016 11:31 AM, John Kenney wrote: > Given that the standards are not yet developed and the stated goal of > the exercise is to provide "input to the standards specification," I > think "experiment" might be more accurate than "trial". Definitely not > deployment, and definitely not a trial with thousands of vehicles. > > John > > -- > 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 > > > On Mon, Jul 25, 2016 at 2:34 PM, Robert Moskowitz > > wrote: > > One can argue that it is an example of what a deployment would be > like. Just like the various DSRC testbeds with some thousands of > enabled vehicles. > > > :) > > > > On 07/25/2016 07:57 AM, Dr. Hans-Joachim Fischer wrote: >> >> >> Sorry! >> >> Deployment? I read "trial". It cannot be more. >> >> >> Hans-Joachim >> >> >> Am 25.07.2016 um 16:35 schrieb H Anthony Chan: >>> The following is an example of deployment : >>> >>> http://www.rcrwireless.com/20160712/connected-cars-2/dt-huawei-audi-toyota-carry-lte-v-trials-germany >>> >>> DT, Huawei, Audi and Toyota carry out LTE-V trials in Germany >>> >>> >>> German telco said LTE-V is a potential enabler for road >>> safety and traffic efficiency apps >>> >>> German telecom operator Deutsche Telekom, Chinese vendor Huawei >>> and car makers including Audi and Toyota are currently testing >>> LTE-Vehicular in Germany. >>> >>> The German telco said that technical tests are underway on this >>> connected vehicles technology, which is seen as a potential >>> enabler for road safety and traffic efficiency applications. The >>> partners are conducting these trials on a section of the >>> “digital A9 motorway test bed” near Ingolstadt, Germany. >>> >>> LTE-V is a variant of 4G LTE technology. It is being specified >>> within the European 3GPP project that develops >>> telecommunications standards as part of its Release 14. This >>> variant is specifically designed to meet automotive requirements >>> for both vehicle-to-vehicle and vehicle-to-infrastructure >>> communication. LTE-V can address multiple application types >>> ranging from connected vehicle safety applications – collision >>> warning, pedestrian warning, etc. – to connected vehicle smart >>> mobility applications for increased efficiency. >>> >>> Deutsche Telekom infrastructure has been specially equipped with >>> LTE-V hardware from Huawei to support the trial scenarios. Audi, >>> Toyota and other car manufacturers have equipped research cars >>> with the LTE-V hardware developed by Huawei. Based on the trial >>> results, the partners will provide input to the standards >>> specifications for LTE-V. >>> >>> H Anthony Chan >>> >>> >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >> >> -- >> Dr. Hans-Joachim Fischer >> Managing Director >> >> >> ------------------------------------------------------------------------------- >> >> Seminars on Cooperative Intelligent Transport Systems >> http://fischer-tech.eu/Feeds/CITSseminars.html >> >> ------------------------------------------------------------------------------- >> + + + 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 >> ------------------------------------------------------------------------------- >> >> >> _______________________________________________ >> 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 > > > --------------1857E5BB05F86C37FF2592F0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I was going by 'press' statements.  I should have checked with you first about the reality...


On 07/26/2016 11:31 AM, John Kenney wrote:
Given that the standards are not yet developed and the stated goal of the exercise is to provide "input to the standards specification," I think "experiment" might be more accurate than "trial". Definitely not deployment, and definitely not a trial with thousands of vehicles.

John

-- 
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


On Mon, Jul 25, 2016 at 2:34 PM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:

One can argue that it is an example of what a deployment would be like.  Just like the various DSRC testbeds with some thousands of enabled vehicles.


:)



On 07/25/2016 07:57 AM, Dr. Hans-Joachim Fischer wrote:


Sorry!

Deployment? I read "trial". It cannot be more.


Hans-Joachim


Am 25.07.2016 um 16:35 schrieb H Anthony Chan:
The following is an example of deployment :
 

http://www.rcrwireless.com/20160712/connected-cars-2/dt-huawei-audi-toyota-carry-lte-v-trials-germany

 

DT, Huawei, Audi and Toyota carry out LTE-V trials in Germany

German telco said LTE-V is a potential enabler for road safety and traffic efficiency apps

German telecom operator Deutsche Telekom, Chinese vendor Huawei and car makers including Audi and Toyota are currently testing LTE-Vehicular in Germany.

The German telco said that technical tests are underway on this connected vehicles technology, which is seen as a potential enabler for road safety and traffic efficiency applications. The partners are conducting these trials on a section of the “digital A9 motorway test bed” near Ingolstadt, Germany.

LTE-V is a variant of 4G LTE technology. It is being specified within the European 3GPP project that develops telecommunications standards as part of its Release 14. This variant is specifically designed to meet automotive requirements for both vehicle-to-vehicle and vehicle-to-infrastructure communication. LTE-V can address multiple application types ranging from connected vehicle safety applications – collision warning, pedestrian warning, etc. – to connected vehicle smart mobility applications for increased efficiency.

Deutsche Telekom infrastructure has been specially equipped with LTE-V hardware from Huawei to support the trial scenarios. Audi, Toyota and other car manufacturers have equipped research cars with the LTE-V hardware developed by Huawei. Based on the trial results, the partners will provide input to the standards specifications for LTE-V.

H Anthony Chan



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


-- 
Dr. Hans-Joachim Fischer
Managing Director


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

         Seminars on Cooperative Intelligent Transport Systems
             http://fischer-tech.eu/Feeds/CITSseminars.html

------------------------------------------------------------------------------- 
+ + + 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
-------------------------------------------------------------------------------



_______________________________________________
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




--------------1857E5BB05F86C37FF2592F0-- From nobody Wed Jul 27 02:19: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 56A1012D675 for ; Wed, 27 Jul 2016 02:19:05 -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 FMfN8zcQJFtj for ; Wed, 27 Jul 2016 02:19:04 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431CA12D606 for ; Wed, 27 Jul 2016 02:19:04 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id j185so9173614oih.0 for ; Wed, 27 Jul 2016 02:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=qeaKgcBCAQbyURXqQa/rbfUQEHVxhPQ+HTgas7MkwqQ=; b=c+PQiq2unchpx+gBk2oTnEJMc4Rz9ijhxGnfTZUHRkGS1sS0y6LXoxjveG1YzI3XQz gOsWFqzhI0xzpKsLC14BL/cChTr7p+izxAEzjXOZMKD5Ukom3P2Fp/fgUq10KKtxrEqf gNpBfuyF/1oTPp7tTynvn15C8nkSogCUmzD3WQ5jDigpKzQGLNg30ylOHmTcLZpblpbE p+SI6tfQ0e3GS6Cve1Gl89gi5OZEexkWSvhOD7bJpLzlEsyAxjukhvR02quoCmZ1/J/1 GdjHkGHRwWWZlOq+3Nue/KJrbuydbYLqyE3J94+jcIkNjV+CvWLB4J2HDYgPZl9v/45J Bg9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qeaKgcBCAQbyURXqQa/rbfUQEHVxhPQ+HTgas7MkwqQ=; b=czoIoWQJjlvkVCkmb6+m34vV/6in7+Znc30ZlLmoGWPHSQC3SzjwLLc9yzsn82K7fB RYrDXEm7QOxAmuCG8Zxpv/6CmFZeR+NbBAXL4BpI8MkqWnYHjeRxpvJGWxoXrdkVV3+9 cbnEfHeZg/6SjSnX1pezjqSgJVIGsD88vx1c8XfRVMq/ykIqGHHaaUBt8bpCN79kVP5e jHTfz+rZPQovTiasaHH4f41b6n0ZuNfe3atQI5+qg37zlo0cLola/HYN46J9eWyXEnjW OAZAhJSdjai3pH+j7tHLvp5OtnQHDScv0B2USE3FYPnTCRGltD/8u9lcwWfq7vJY8TZg ScIQ== X-Gm-Message-State: AEkoouuIqKkPpkEBPS85wzWlJ5STorT62yfu5X3m+a0CQ9/90sO+XMdPmcezvyK9Z/5qGHD8nR/5mAiSf44/6g== X-Received: by 10.202.56.130 with SMTP id f124mr11855983oia.82.1469611143483; Wed, 27 Jul 2016 02:19:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.88.3 with HTTP; Wed, 27 Jul 2016 02:19:03 -0700 (PDT) From: Michelle Wetterwald Date: Wed, 27 Jul 2016 11:19:03 +0200 Message-ID: To: its@ietf.org Content-Type: multipart/alternative; boundary=001a113cdb762a566005389a8295 Archived-At: Subject: [its] Size of a typical CAM / DENM X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 09:19:05 -0000 --001a113cdb762a566005389a8295 Content-Type: text/plain; charset=UTF-8 Hello, In parallel to the meeting last week, I asked some experts close to implementers. As mentioned during the meeting, the answer is not straightforward as it has to take into account the specifics of the ITS station, and several experts had to be consulted on this question. Indeed, the message size can be highly variable. After some investigation, the experts came to the conclusion that the CAMs without security are 100 to 600 Bytes long and the DENMs without security are typically between 300 and 800 Bytes long. Hence, even with security, CAM and DENM will stay below 1500 Bytes length. Furthermore, the experts confirm the opinion that fragmentation is no good idea. Other solutions, maybe at higher layers, have to be defined. Thanks to Dieter Smely for his help finding the answer. Best regards, Michelle Wetterwald ---- Senior expert in networking and telecommunications --001a113cdb762a566005389a8295 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

In parallel to the meeting last week, I as= ked some experts close to implementers. As mentioned during the meeting, th= e answer is not straightforward as it has to take into account the specific= s of the ITS station, and several experts had to be consulted on this quest= ion.
Indeed, the message size can be highly variable. After some invest= igation, the experts came to the conclusion that the CAMs without security = are 100 to 600 Bytes long and the DENMs without security are typically betw= een 300 and 800 Bytes long.

Hence, even with security, CAM and DENM w= ill stay below 1500 Bytes length.

Furthermore, the experts confirm th= e opinion that fragmentation is no good idea. Other solutions, maybe at hig= her layers, have to be defined.

Thanks to Dieter Smely for his help f= inding the answer.

Best regards,
Michelle Wetterwald
----
Se= nior expert in networking and telecommunications

--001a113cdb762a566005389a8295-- From nobody Wed Jul 27 03:23:36 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DE012DED1 for ; Wed, 27 Jul 2016 03:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287] 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 oodAHnsCkzE0 for ; Wed, 27 Jul 2016 03:23:32 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id D56AD12DE87 for ; Wed, 27 Jul 2016 03:23:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,429,1464645600"; d="scan'208,217";a="4409624" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 27 Jul 2016 12:23:30 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 70220592 for ; Wed, 27 Jul 2016 12:23:30 +0200 (CEST) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: Date: Wed, 27 Jul 2016 12:23:30 +0200 Organization: EURECOM Message-ID: <002f01d1e7f0$ebcca640$c365f2c0$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01D1E801.AF557640" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdHn6w7oyvg7OBqyTISf5Zc29OdJwQ== Content-Language: en-us Archived-At: Subject: [its] MTU and size of a typical CAM / DENM / ITS messages X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 10:23:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0030_01D1E801.AF557640 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, =20 Thanks Michelle for this details. I would like also to further add some = details on the MTU discussion we had last week.=20 =20 The very existence of a MTU is not only to make or break the upper = layers, but to guarantee reliable communication on the wireless PHY = layer. One aspect that restricts the MTU is the wireless channel = coherence time, say =E2=80=9Cthe time-scale at which fading = occurs=E2=80=9D, (i.e. the time during which the channel will not change = =E2=80=98much=E2=80=99). This might be less important for wired = Ethernet, but critical for wireless Ethernet-style of networks, as it = creates time-selective channels. =20 When a WiFi device receives a packet, it will use the OFDM pilot symbols = (4 out of 52) to estimate the channel. This is done at the PHY preamble = of packet only and never during the packet/payload reception (well, we = can discuss the pertinence of this choice, but it is the case for = 802.11a). If the channel does not change (residual phase error) much = during the packet transmission from what has been = =E2=80=98estimated=E2=80=99 during the preamble, then everything is = fine. But if it does (narrowband fast fading), there is a high chance = that the packet will be lost.. =20 This justifies the fact that a packet should not take more = =E2=80=98time=E2=80=99 than the channel coherence time during its = transmission (to avoid time selectivity). The question is: what is the = channel coherence time? Well, it differs a lot depending on the = environment, but for WiFi in a quasi-static environment (~90% of WiFi = traffic), it is usually quite long (order of multiple of ms).=20 =20 But on ITS-G5/DSRC/820.11p/=E2=80=A6, studies indicated that it is = approximatively 1ms (source: Measurement and Analysis of Wireless = Channel Impairments in DSRC Vehicular Communications, Laberteaux et al, = 2008).=20 =20 Said it simple: any ITS-G5/=E2=80=A6 packet being transmitted on the = vehicular wireless channel that would take more than 1ms has a high(er) = chance of being lost. ITS-G5/DCC/ITS applications will play with = modulations (BPSK,=E2=80=A6/64QAM) to enhance the modulation order and = accordingly reduce the transmission time on channel (with as consequence = an increased required SINR at the receiver, and thus a shorter distance = (at least)).. =20 So, the ITS-G5/802.11p/DSRC MTU can be big or small..it all depends on = what I called at the IETF meeting the =E2=80=98equivalent transmit time = on channel=E2=80=99. So, whatever would be the MTU from a PHY = perspective, it should not take more than 1ms to be transmitted on the = channel. =20 The control channel (ch 178 US, ch. 180 EU) fixed a compulsory = modulation of 6Mbps (QPSK =C2=BD). This limits the MTU to 750 bytes (if = my computations are correct..)..of course, you may always try to send a = larger packet, but again, the channel might change = =E2=80=98during=E2=80=99 the transmission of your packet and you might = lose it. According to Michelle=E2=80=99s e-mail, such MTU is fine for = CAM/DENM=E2=80=A6 =20 Now, if you want to send IPv6 traffic, and assuming the channel = coherence time is 1ms, then you have to adapt the modulation to get = bigger MTUs=E2=80=A6So, I would support the conclusion of the discussion = we had is that for IPv6 packets to be transmitted on = ITS-G5/DSRC/802.11p/.., we should indicate a minimum MTU as required by = IPv6 that should be delivered by ITS-G5/../=E2=80=A6.and ITS-G5 will try = to get it by playing with modulation..If ITS-G5 cannot provide it for = =E2=80=98any=E2=80=99 reason, then it just means the channel is not good = enough for IPv6 at the moment, and it should delay its transmission. If = IPv6 requires a bigger MTU, then it is the role of the ITS-G5 to notify = IPv6 of the MTU-modulation-range(SINR) combinations, so that IPv6 can = adjust the most appropriate MTU. =20 As Michelle mentioned (and supporting also Dieter), I would avoid = fragmenting at the access technology layer..802.11a is not good at = efficient fragmentation (but 802.11ac is J). =20 Best Regards, =20 J=C3=A9r=C3=B4me =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Michelle Wetterwald Sent: Wednesday 27 July 2016 11:19 To: its@ietf.org Subject: [its] Size of a typical CAM / DENM =20 Hello, In parallel to the meeting last week, I asked some experts close to = implementers. As mentioned during the meeting, the answer is not = straightforward as it has to take into account the specifics of the ITS = station, and several experts had to be consulted on this question.=20 Indeed, the message size can be highly variable. After some = investigation, the experts came to the conclusion that the CAMs without = security are 100 to 600 Bytes long and the DENMs without security are = typically between 300 and 800 Bytes long. Hence, even with security, CAM and DENM will stay below 1500 Bytes = length. Furthermore, the experts confirm the opinion that fragmentation is no = good idea. Other solutions, maybe at higher layers, have to be defined. Thanks to Dieter Smely for his help finding the answer. Best regards, Michelle Wetterwald ---- Senior expert in networking and telecommunications ------=_NextPart_000_0030_01D1E801.AF557640 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear All,

 

Thanks Michelle for this details. I would like also to further add = some details on the MTU discussion we had last week. =

 

The very existence of a MTU is not only to make or break the upper = layers, but to guarantee reliable communication on the wireless PHY = layer. One aspect that restricts the MTU is the wireless channel = coherence time, say =E2=80=9Cthe time-scale at which fading = occurs=E2=80=9D, (i.e. the time during which the channel will not change = =E2=80=98much=E2=80=99). This might be less important for wired = Ethernet, but critical for wireless Ethernet-style of networks, as it = creates time-selective channels.

 

When a WiFi device receives a packet, it will use the OFDM pilot = symbols (4 out of 52) to estimate the channel. This is done at the PHY = preamble of packet only and never during the packet/payload = reception (well, we can discuss the pertinence of this choice, but it is = the case for 802.11a). If the channel does not change (residual phase = error) much during the packet transmission from what has been = =E2=80=98estimated=E2=80=99 during the preamble, then everything is = fine. But if it does (narrowband fast fading), there is a high chance = that the packet will be lost..

 

This justifies the fact that a packet should not take more = =E2=80=98time=E2=80=99 than the channel coherence time during its = transmission (to avoid time selectivity). The question is: what is the = channel coherence time? Well, it differs a lot depending on the = environment, but for WiFi in a quasi-static environment (~90% of WiFi = traffic), it is usually quite long (order of multiple of ms). =

 

But on ITS-G5/DSRC/820.11p/=E2=80=A6, studies indicated that it is = approximatively 1ms (source: Measurement and Analysis of = Wireless Channel Impairments in DSRC Vehicular Communications, = Laberteaux et al, 2008).

 

Said it simple: any ITS-G5/=E2=80=A6 packet being transmitted on the = vehicular wireless channel that would take more than 1ms has a high(er) = chance of being lost. ITS-G5/DCC/ITS applications will play with = modulations (BPSK,=E2=80=A6/64QAM) to enhance the modulation order and = accordingly reduce the transmission time on channel (with as consequence = an increased required SINR at the receiver, and thus a shorter distance = (at least))..

 

So, the ITS-G5/802.11p/DSRC MTU can be big or small..it all depends = on what I called at the IETF meeting the =E2=80=98equivalent transmit = time on channel=E2=80=99. So, whatever would be the MTU from a PHY = perspective, it should not take more than 1ms to be transmitted on = the channel.

 

The control channel (ch 178 US, ch. 180 EU) fixed a compulsory = modulation of 6Mbps (QPSK =C2=BD). This limits the MTU to =C2=A0750 = bytes (if my computations are correct..)..of course, you may always = try to send a larger packet, but again, the channel might change = =E2=80=98during=E2=80=99 the transmission of your packet and you might = lose it. According to Michelle=E2=80=99s e-mail, such MTU is fine for = CAM/DENM=E2=80=A6

 

Now, if you want to send IPv6 traffic, and assuming the channel = coherence time is 1ms, then you have to adapt the modulation to get = bigger MTUs=E2=80=A6So, I would support the conclusion of the discussion = we had is that for IPv6 packets to be transmitted on = ITS-G5/DSRC/802.11p/.., we should indicate a minimum MTU as = required by IPv6 that should be delivered by ITS-G5/../=E2=80=A6.and = ITS-G5 will try to get it by playing with modulation..If ITS-G5 = cannot provide it for =E2=80=98any=E2=80=99 reason, then it just means = the channel is not good enough for IPv6 at the moment, and it should = delay its transmission. If IPv6 requires a bigger MTU, then it is the = role of the ITS-G5 to notify IPv6 of the MTU-modulation-range(SINR) = combinations, so that IPv6 can adjust the most appropriate = MTU.

 

As Michelle mentioned (and supporting also Dieter), I would avoid = fragmenting at the access technology layer..802.11a is not good at = efficient fragmentation (but 802.11ac is J).

 

Best Regards,

 

J=C3=A9r=C3=B4me

 

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of Michelle = Wetterwald
Sent: Wednesday 27 July 2016 11:19
To: = its@ietf.org
Subject: [its] Size of a typical CAM / = DENM

 

Hello,

In= parallel to the meeting last week, I asked some experts close to = implementers. As mentioned during the meeting, the answer is not = straightforward as it has to take into account the specifics of the ITS = station, and several experts had to be consulted on this question. =
Indeed, the message size can be highly variable. After some = investigation, the experts came to the conclusion that the CAMs without = security are 100 to 600 Bytes long and the DENMs without security are = typically between 300 and 800 Bytes long.

Hence, even = with security, CAM and DENM will stay below 1500 Bytes = length.

Furthermore, the experts confirm the opinion = that fragmentation is no good idea. Other solutions, maybe at higher = layers, have to be defined.

Thanks to Dieter Smely for = his help finding the answer.

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

------=_NextPart_000_0030_01D1E801.AF557640-- From nobody Wed Jul 27 03:43: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 385D212D645 for ; Wed, 27 Jul 2016 03:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287] 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 MGXNSQtsNZfu for ; Wed, 27 Jul 2016 03:43:23 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id E6A3812DF25 for ; Wed, 27 Jul 2016 03:36:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,429,1464645600"; d="scan'208,217";a="4409659" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 27 Jul 2016 12:36:28 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 1F7AF60A for ; Wed, 27 Jul 2016 12:36:28 +0200 (CEST) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: References: <002f01d1e7f0$ebcca640$c365f2c0$@eurecom.fr> In-Reply-To: <002f01d1e7f0$ebcca640$c365f2c0$@eurecom.fr> Date: Wed, 27 Jul 2016 12:36:27 +0200 Organization: EURECOM Message-ID: <004501d1e7f2$bb513ba0$31f3b2e0$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01D1E803.7EDA0BA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG3GRqfoI2sN9mPXhDgUZ2f+ULdGKBhsiYg Content-Language: en-us Archived-At: Subject: Re: [its] MTU and size of a typical CAM / DENM / ITS messages X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 10:43:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0046_01D1E803.7EDA0BA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, =20 Additional corrected information related to the channel estimation: I = was referring to the short and long training sequences of the PHY = preamble, and not to the pilot OFDM in this case=E2=80=A6sorry for the = confusion. Conclusions/impacts remain the same. =20 Best Regards, J=C3=A9r=C3=B4me =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me = H=C3=A4rri Sent: Wednesday 27 July 2016 12:24 To: its@ietf.org Subject: [its] MTU and size of a typical CAM / DENM / ITS messages =20 Dear All, =20 Thanks Michelle for this details. I would like also to further add some = details on the MTU discussion we had last week.=20 =20 The very existence of a MTU is not only to make or break the upper = layers, but to guarantee reliable communication on the wireless PHY = layer. One aspect that restricts the MTU is the wireless channel = coherence time, say =E2=80=9Cthe time-scale at which fading = occurs=E2=80=9D, (i.e. the time during which the channel will not change = =E2=80=98much=E2=80=99). This might be less important for wired = Ethernet, but critical for wireless Ethernet-style of networks, as it = creates time-selective channels. =20 When a WiFi device receives a packet, it will use the OFDM pilot symbols = (4 out of 52) to estimate the channel. This is done at the PHY preamble = of packet only and never during the packet/payload reception (well, we = can discuss the pertinence of this choice, but it is the case for = 802.11a). If the channel does not change (residual phase error) much = during the packet transmission from what has been = =E2=80=98estimated=E2=80=99 during the preamble, then everything is = fine. But if it does (narrowband fast fading), there is a high chance = that the packet will be lost.. =20 This justifies the fact that a packet should not take more = =E2=80=98time=E2=80=99 than the channel coherence time during its = transmission (to avoid time selectivity). The question is: what is the = channel coherence time? Well, it differs a lot depending on the = environment, but for WiFi in a quasi-static environment (~90% of WiFi = traffic), it is usually quite long (order of multiple of ms).=20 =20 But on ITS-G5/DSRC/820.11p/=E2=80=A6, studies indicated that it is = approximatively 1ms (source: Measurement and Analysis of Wireless = Channel Impairments in DSRC Vehicular Communications, Laberteaux et al, = 2008).=20 =20 Said it simple: any ITS-G5/=E2=80=A6 packet being transmitted on the = vehicular wireless channel that would take more than 1ms has a high(er) = chance of being lost. ITS-G5/DCC/ITS applications will play with = modulations (BPSK,=E2=80=A6/64QAM) to enhance the modulation order and = accordingly reduce the transmission time on channel (with as consequence = an increased required SINR at the receiver, and thus a shorter distance = (at least)).. =20 So, the ITS-G5/802.11p/DSRC MTU can be big or small..it all depends on = what I called at the IETF meeting the =E2=80=98equivalent transmit time = on channel=E2=80=99. So, whatever would be the MTU from a PHY = perspective, it should not take more than 1ms to be transmitted on the = channel. =20 The control channel (ch 178 US, ch. 180 EU) fixed a compulsory = modulation of 6Mbps (QPSK =C2=BD). This limits the MTU to 750 bytes (if = my computations are correct..)..of course, you may always try to send a = larger packet, but again, the channel might change = =E2=80=98during=E2=80=99 the transmission of your packet and you might = lose it. According to Michelle=E2=80=99s e-mail, such MTU is fine for = CAM/DENM=E2=80=A6 =20 Now, if you want to send IPv6 traffic, and assuming the channel = coherence time is 1ms, then you have to adapt the modulation to get = bigger MTUs=E2=80=A6So, I would support the conclusion of the discussion = we had is that for IPv6 packets to be transmitted on = ITS-G5/DSRC/802.11p/.., we should indicate a minimum MTU as required by = IPv6 that should be delivered by ITS-G5/../=E2=80=A6.and ITS-G5 will try = to get it by playing with modulation..If ITS-G5 cannot provide it for = =E2=80=98any=E2=80=99 reason, then it just means the channel is not good = enough for IPv6 at the moment, and it should delay its transmission. If = IPv6 requires a bigger MTU, then it is the role of the ITS-G5 to notify = IPv6 of the MTU-modulation-range(SINR) combinations, so that IPv6 can = adjust the most appropriate MTU. =20 As Michelle mentioned (and supporting also Dieter), I would avoid = fragmenting at the access technology layer..802.11a is not good at = efficient fragmentation (but 802.11ac is J). =20 Best Regards, =20 J=C3=A9r=C3=B4me =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Michelle Wetterwald Sent: Wednesday 27 July 2016 11:19 To: its@ietf.org Subject: [its] Size of a typical CAM / DENM =20 Hello, In parallel to the meeting last week, I asked some experts close to = implementers. As mentioned during the meeting, the answer is not = straightforward as it has to take into account the specifics of the ITS = station, and several experts had to be consulted on this question.=20 Indeed, the message size can be highly variable. After some = investigation, the experts came to the conclusion that the CAMs without = security are 100 to 600 Bytes long and the DENMs without security are = typically between 300 and 800 Bytes long. Hence, even with security, CAM and DENM will stay below 1500 Bytes = length. Furthermore, the experts confirm the opinion that fragmentation is no = good idea. Other solutions, maybe at higher layers, have to be defined. Thanks to Dieter Smely for his help finding the answer. Best regards, Michelle Wetterwald ---- Senior expert in networking and telecommunications ------=_NextPart_000_0046_01D1E803.7EDA0BA0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear All,

 

Additional corrected information related to the channel estimation: I = was referring to the short and long training sequences of the PHY = preamble, and not to the pilot OFDM in this case=E2=80=A6sorry for the = confusion. Conclusions/impacts remain the same.

 

Best Regards,


J=C3=A9r=C3=B4me

 

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me = H=C3=A4rri
Sent: Wednesday 27 July 2016 12:24
To: = its@ietf.org
Subject: [its] MTU and size of a typical CAM / = DENM / ITS messages

 

Dear All,

 

Thanks Michelle for this details. I would like also to further add = some details on the MTU discussion we had last week. =

 

The very existence of a MTU is not only to make or break the upper = layers, but to guarantee reliable communication on the wireless PHY = layer. One aspect that restricts the MTU is the wireless channel = coherence time, say =E2=80=9Cthe time-scale at which fading = occurs=E2=80=9D, (i.e. the time during which the channel will not change = =E2=80=98much=E2=80=99). This might be less important for wired = Ethernet, but critical for wireless Ethernet-style of networks, as it = creates time-selective channels.

 

When a WiFi device receives a packet, it will use the OFDM pilot = symbols (4 out of 52) to estimate the channel. This is done at the PHY = preamble of packet only and never during the packet/payload = reception (well, we can discuss the pertinence of this choice, but it is = the case for 802.11a). If the channel does not change (residual phase = error) much during the packet transmission from what has been = =E2=80=98estimated=E2=80=99 during the preamble, then everything is = fine. But if it does (narrowband fast fading), there is a high chance = that the packet will be lost..

 

This justifies the fact that a packet should not take more = =E2=80=98time=E2=80=99 than the channel coherence time during its = transmission (to avoid time selectivity). The question is: what is the = channel coherence time? Well, it differs a lot depending on the = environment, but for WiFi in a quasi-static environment (~90% of WiFi = traffic), it is usually quite long (order of multiple of ms). =

 

But on ITS-G5/DSRC/820.11p/=E2=80=A6, studies indicated that it is = approximatively 1ms (source: Measurement and Analysis of = Wireless Channel Impairments in DSRC Vehicular Communications, = Laberteaux et al, 2008).

 

Said it simple: any ITS-G5/=E2=80=A6 packet being transmitted on the = vehicular wireless channel that would take more than 1ms has a high(er) = chance of being lost. ITS-G5/DCC/ITS applications will play with = modulations (BPSK,=E2=80=A6/64QAM) to enhance the modulation order and = accordingly reduce the transmission time on channel (with as consequence = an increased required SINR at the receiver, and thus a shorter distance = (at least))..

 

So, the ITS-G5/802.11p/DSRC MTU can be big or small..it all depends = on what I called at the IETF meeting the =E2=80=98equivalent transmit = time on channel=E2=80=99. So, whatever would be the MTU from a PHY = perspective, it should not take more than 1ms to be transmitted on = the channel.

 

The control channel (ch 178 US, ch. 180 EU) fixed a compulsory = modulation of 6Mbps (QPSK =C2=BD). This limits the MTU to  750 = bytes (if my computations are correct..)..of course, you may always = try to send a larger packet, but again, the channel might change = =E2=80=98during=E2=80=99 the transmission of your packet and you might = lose it. According to Michelle=E2=80=99s e-mail, such MTU is fine for = CAM/DENM=E2=80=A6

 

Now, if you want to send IPv6 traffic, and assuming the channel = coherence time is 1ms, then you have to adapt the modulation to get = bigger MTUs=E2=80=A6So, I would support the conclusion of the discussion = we had is that for IPv6 packets to be transmitted on = ITS-G5/DSRC/802.11p/.., we should indicate a minimum MTU as = required by IPv6 that should be delivered by ITS-G5/../=E2=80=A6.and = ITS-G5 will try to get it by playing with modulation..If ITS-G5 = cannot provide it for =E2=80=98any=E2=80=99 reason, then it just means = the channel is not good enough for IPv6 at the moment, and it should = delay its transmission. If IPv6 requires a bigger MTU, then it is the = role of the ITS-G5 to notify IPv6 of the MTU-modulation-range(SINR) = combinations, so that IPv6 can adjust the most appropriate = MTU.

 

As Michelle mentioned (and supporting also Dieter), I would avoid = fragmenting at the access technology layer..802.11a is not good at = efficient fragmentation (but 802.11ac is J).

 

Best Regards,

 

J=C3=A9r=C3=B4me

 

From:= = its [mailto:its-bounces@ietf.org] = On Behalf Of Michelle Wetterwald
Sent: Wednesday 27 = July 2016 11:19
To: its@ietf.org
Subject: [its] = Size of a typical CAM / DENM

 

Hello,

In= parallel to the meeting last week, I asked some experts close to = implementers. As mentioned during the meeting, the answer is not = straightforward as it has to take into account the specifics of the ITS = station, and several experts had to be consulted on this question. =
Indeed, the message size can be highly variable. After some = investigation, the experts came to the conclusion that the CAMs without = security are 100 to 600 Bytes long and the DENMs without security are = typically between 300 and 800 Bytes long.

Hence, even = with security, CAM and DENM will stay below 1500 Bytes = length.

Furthermore, the experts confirm the opinion = that fragmentation is no good idea. Other solutions, maybe at higher = layers, have to be defined.

Thanks to Dieter Smely for = his help finding the answer.

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

------=_NextPart_000_0046_01D1E803.7EDA0BA0-- From nobody Wed Jul 27 07:05: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 B123512D8F4 for ; Wed, 27 Jul 2016 07:05: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 OJ5bLDVQJPOb for ; Wed, 27 Jul 2016 07:05:13 -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 3B2DC12D92B for ; Wed, 27 Jul 2016 07:05:11 -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 u6RE58NC020364 for ; Wed, 27 Jul 2016 16:05:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A82F220A5AF for ; Wed, 27 Jul 2016 16:05:08 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9DAE220A571 for ; Wed, 27 Jul 2016 16:05:08 +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 u6RE579M014203 for ; Wed, 27 Jul 2016 16:05:08 +0200 To: its@ietf.org References: <002f01d1e7f0$ebcca640$c365f2c0$@eurecom.fr> <004501d1e7f2$bb513ba0$31f3b2e0$@eurecom.fr> From: Alexandre Petrescu Message-ID: <28599ddd-5f3a-0994-3d47-c0168499c474@gmail.com> Date: Wed, 27 Jul 2016 16:05:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <004501d1e7f2$bb513ba0$31f3b2e0$@eurecom.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] MTU and size of a typical CAM / DENM / ITS messages X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 14:05:14 -0000 Hi Jérôme, Thanks for the message. Le 27/07/2016 à 12:36, Jérôme Härri a écrit : [...] > So, the ITS-G5/802.11p/DSRC MTU can be big or small..it all depends > on what I called at the IETF meeting the ‘equivalent transmit time > on channel’. So, whatever would be the MTU _from a PHY perspective_, > it should not take more than 1ms to be transmitted on the channel. Out of that 1ms can we calculate the packet size that can be transmitted during it? > The control channel (ch 178 US, ch. 180 EU) fixed a compulsory > modulation of 6Mbps (QPSK ½). This limits the _MTU to 750 bytes_ (if > my computations are correct..) Is the QPSK 1/2 modulation accepted in EU too? > ..of course, you may always try to send a larger packet, but again, > the channel might change ‘during’ the transmission of your packet and > you might lose it. > > According to Michelle’s e-mail, such MTU is fine for CAM/DENM… Well, one of the upper limits in Michelle's email is 800bytes (DENM without security) and that is exceeding the 750bytes you mention above. > Now, if you want to send IPv6 traffic, and assuming the channel > coherence time is 1ms, then you have to adapt the modulation to get > bigger MTUs…So, I would support the conclusion of the discussion we > had is that for IPv6 packets to be transmitted on > ITS-G5/DSRC/802.11p/.., we should indicate a _minimum MTU *as* > required by IPv6_ that should be delivered by ITS-G5/../…. I agree. The minimum MTU size that is required in order to support IPv6 is 1280bytes. We will definitely write that down. (for the term "minimum MTU" remark the abbreviation expands into "minimum maximum transmission unit size", which led to some confusion sometimes; but let's go with it for now). > and _ITS-G5 will try to get it by playing with modulation_..If > ITS-G5 cannot provide it for ‘any’ reason, then it just means the > channel is not good enough for IPv6 at the moment, and it should > delay its transmission. This logic sounds more dynamic than I thought of. You seem to be saying there is a variable MTU size, and buffering (rather than fragmentation) can be employed to adapt to the IPv6 MTU size in time. I wonder whether that can be noticed in practice in the command line on linux? > If IPv6 requires a bigger MTU, then it is the role of the ITS-G5 to > notify IPv6 of the MTU-modulation-range(SINR) combinations, so that > IPv6 can adjust the most appropriate MTU. Is there a means by which ITS-G5 (aka 802.11-OCB) notifies the IP networking layer about something? An API? A field in a header? > As Michelle mentioned (and supporting also Dieter), I would avoid > fragmenting at the access technology layer.. Do you mean MAC layer? > 802.11a is not good at efficient fragmentation (but 802.11ac is J). Err... the 802.11 Data Headers do feature a 'More Fragments' bit in the Flags byte of the Frame Control Field. When that bit is '0' the text says 'This is the last fragment'. It makes think fragmentation is 802.11, and not a matter of 802.11a or 802.11ac. You seem to say there is a difference? Alex > > > > Best Regards, > > > > Jérôme > > > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Michelle > Wetterwald *Sent:* Wednesday 27 July 2016 11:19 *To:* its@ietf.org > *Subject:* [its] Size of a typical CAM / DENM > > > > Hello, > > In parallel to the meeting last week, I asked some experts close to > implementers. As mentioned during the meeting, the answer is not > straightforward as it has to take into account the specifics of the > ITS station, and several experts had to be consulted on this > question. Indeed, the message size can be highly variable. After > some investigation, the experts came to the conclusion that the CAMs > without security are 100 to 600 Bytes long and the DENMs without > security are typically between 300 and 800 Bytes long. > > Hence, even with security, CAM and DENM will stay below 1500 Bytes > length. > > Furthermore, the experts confirm the opinion that fragmentation is > no good idea. Other solutions, maybe at higher layers, have to be > defined. > > Thanks to Dieter Smely for his help finding the answer. > > Best regards, Michelle Wetterwald ---- Senior expert in networking > and telecommunications > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Wed Jul 27 10:20: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 9AAEF12D196 for ; Wed, 27 Jul 2016 10:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287] 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 m3qYDhCpRcRY for ; Wed, 27 Jul 2016 10:20:09 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id CCA8212D108 for ; Wed, 27 Jul 2016 10:20:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,430,1464645600"; d="scan'208";a="4411615" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 27 Jul 2016 19:20:07 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 9285717CD; Wed, 27 Jul 2016 19:20:07 +0200 (CEST) From: =?iso-8859-1?B?Suly9G1lIEjkcnJp?= To: "'Alexandre Petrescu'" , References: <002f01d1e7f0$ebcca640$c365f2c0$@eurecom.fr> <004501d1e7f2$bb513ba0$31f3b2e0$@eurecom.fr> <28599ddd-5f3a-0994-3d47-c0168499c474@gmail.com> In-Reply-To: <28599ddd-5f3a-0994-3d47-c0168499c474@gmail.com> Date: Wed, 27 Jul 2016 19:20:07 +0200 Organization: EURECOM Message-ID: <009401d1e82b$1f3cefa0$5db6cee0$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG3GRqfoI2sN9mPXhDgUZ2f+ULdGAHjNXkOAjKomtGgQUoPkA== Content-Language: en-us Archived-At: Subject: Re: [its] MTU and size of a typical CAM / DENM / ITS messages X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 17:20:11 -0000 Hi Alex, Answers inline... [...] >> So, the ITS-G5/802.11p/DSRC MTU can be big or small..it all depends = on=20 >> what I called at the IETF meeting the =91equivalent transmit time on=20 >> channel=92. So, whatever would be the MTU _from a PHY perspective_, = it=20 >> should not take more than 1ms to be transmitted on the channel. >Out of that 1ms can we calculate the packet size that can be = transmitted during it? You need to fix one parameter: if you fix the modulation, then yes. Otherwise, you fix the packet size and change the modulation. >> The control channel (ch 178 US, ch. 180 EU) fixed a compulsory=20 >> modulation of 6Mbps (QPSK =BD). This limits the _MTU to 750 bytes_ = (if=20 >> my computations are correct..) >Is the QPSK 1/2 modulation accepted in EU too? Yes, 6Mbps is also the default (and restricted) modulation on the CCH in = EU. >> ..of course, you may always try to send a larger packet, but again,=20 >> the channel might change =91during=92 the transmission of your packet = and=20 >> you might lose it. >> >> According to Michelle=92s e-mail, such MTU is fine for CAM/DENM=85 >Well, one of the upper limits in Michelle's email is 800bytes (DENM = without security) and that is exceeding the 750bytes you mention above. Ok, but as this is merely stochastic, we can exceed a bit (or even be at = the limit), it might still be OK (or even not work at lower packet size..). = We should avoid 'exceeding' 750Bytes...but it is all about channel conditions..and if you are OK with retransmission in case of packet losses... >> Now, if you want to send IPv6 traffic, and assuming the channel=20 >> coherence time is 1ms, then you have to adapt the modulation to get=20 >> bigger MTUs=85So, I would support the conclusion of the discussion we = >> had is that for IPv6 packets to be transmitted on=20 >> ITS-G5/DSRC/802.11p/.., we should indicate a _minimum MTU *as*=20 >> required by IPv6_ that should be delivered by ITS-G5/../=85. >I agree. The minimum MTU size that is required in order to support = IPv6 is 1280bytes. We will definitely write that down. OK, great. I will also further check if other studies mentioned different channel coherence time (or if we could have classification of it as function of = a particular context..) >(for the term "minimum MTU" remark the abbreviation expands into = "minimum maximum transmission unit size", which led to some confusion >sometimes; = but let's go with it for now). Indeed. >> and _ITS-G5 will try to get it by playing with modulation_..If >> ITS-G5 cannot provide it for =91any=92 reason, then it just means the = >> channel is not good enough for IPv6 at the moment, and it should = delay=20 >> its transmission. > This logic sounds more dynamic than I thought of. > You seem to be saying there is a variable MTU size, and buffering = (rather than fragmentation) can be employed to adapt to the IPv6 MTU size in > = time. > > I wonder whether that can be noticed in practice in the command line = on linux? Well, it is all dynamic in wireless...what I mean is that MTU is a conceptual representation in wireless. We need to identify a 'true' parameter, and extract the MTU from it. My proposal was to use a = 'transmit duration', as this would also allow us to control the congestion...the = 1ms channel coherence time could be a guideline, but we could also get a different value.. My point is it should be a channel 'usage time' rather than a 'packet size'... If you fix the channel usage time (ex. 1ms) per IPv6 packet, then it is quite easy to extract the MTU for each modulation (8 in total)..so, this could be a basic function that can be implemented..and available as = API... The ITS-G5 API can change the modulation, and the DCC (called channel congestion control in the US) can also tell you how long you can use the channel (in the case we would choose to use more than 1ms per IPv6 = packet). So, both parameters may be used. But the best option would be to have = this at the facilities layer (it is already being discussed at the ETSI = ITS...so, you could configure your IPv6 traffic accordingly (and not have to 'stop = it' below). >> If IPv6 requires a bigger MTU, then it is the role of the ITS-G5 to=20 >> notify IPv6 of the MTU-modulation-range(SINR) combinations, so that >> IPv6 can adjust the most appropriate MTU. >Is there a means by which ITS-G5 (aka 802.11-OCB) notifies the IP networking layer about something? An API? A field in a header? As mentioned, best would be to use a facilities layer, but if we want to = use plain IPv6 and ITS-G5, then you can have access to the ITS-G5 management functions, there are command-line functions to retrieve or change = modulation or other things.=20 But more generally, I think we will need a 'service management' message = or something similar..first (as mentioned also during the IETF meeting) as = we need to announce on which channel the IPv6 will be transmitted...but = second we can use this message to announce 1) the modulation and 2) the = respective MTU.=20 This kind of management message was the duty of WiFi beacons...but as = they are not there for ITS-G5, we need to compensate with something...could = we have an IPv6 management message taking this role?=20 >> As Michelle mentioned (and supporting also Dieter), I would avoid=20 >> fragmenting at the access technology layer.. >Do you mean MAC layer? Yes... >> 802.11a is not good at efficient fragmentation (but 802.11ac is J). >Err... the 802.11 Data Headers do feature a 'More Fragments' bit in the Flags byte of the Frame Control Field. When that bit is '0' the text = says >'This is the last fragment'. > >It makes think fragmentation is 802.11, and not a matter of 802.11a or 802.11ac. You seem to say there is a difference? This is not on the mechanism, but on the efficiency.=20 .11a separates each fragment by a SIFS and must add a ACK after each = unicast fragment. And each fragment must have its MAC header, and as any MAC = packet, the header cannot have an increased modulation (BPSK 1/2 by default). = So, whatever you would do on the fragment (increasing modulation), you will = be limited by the fixed overhead given by the number of extra headers, the = SIFS and ACKs. Also, the mechanism can be seen as a monopoly on the channel. = As all fragment are transmitted after a SIFS, any other traffic will have limited chances (or actually no chance due to virtual carrier sensing) = to even access the channel... .11ac (starting already by .11n and even .11e as option) allows you to optimize the fragmentation by transmitting a group ACK for all fragment, = and even reduce the time between fragment (RIFS < SIFS). As time on a = wireless vehicular channel is critical, we need to avoid such extra overhead. btw, the maximum transmission length on 802.11ac is defined as 5ms (but = I could not find the equivalent for 11.a...maybe it is the same).=20 Cheers, J=E9r=F4me From nobody Wed Jul 27 10:24: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 5D6DB12D4FB for ; Wed, 27 Jul 2016 10:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287] 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 y0-ghI4sXKya for ; Wed, 27 Jul 2016 10:24:21 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id E795D12B04D for ; Wed, 27 Jul 2016 10:24:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,430,1464645600"; d="scan'208";a="4411640" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 27 Jul 2016 19:24:20 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 22339187C; Wed, 27 Jul 2016 19:24:20 +0200 (CEST) From: =?iso-8859-1?B?Suly9G1lIEjkcnJp?= To: "'Alexandre Petrescu'" , References: <002f01d1e7f0$ebcca640$c365f2c0$@eurecom.fr> <004501d1e7f2$bb513ba0$31f3b2e0$@eurecom.fr> <28599ddd-5f3a-0994-3d47-c0168499c474@gmail.com> In-Reply-To: <28599ddd-5f3a-0994-3d47-c0168499c474@gmail.com> Date: Wed, 27 Jul 2016 19:24:19 +0200 Organization: EURECOM Message-ID: <009601d1e82b$b5c35450$2149fcf0$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG3GRqfoI2sN9mPXhDgUZ2f+ULdGAHjNXkOAjKomtGgQXUnIA== Content-Language: en-us Archived-At: Subject: Re: [its] MTU and size of a typical CAM / DENM / ITS messages X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 17:24:22 -0000 Hi Alex, I further found some baseline 802.11 metrics that could be of interest = to the draft: .11a: maximum MAC Service Data Unit (MSDU - MAC payload...): 2 304 Bytes = - this is I think one of the values you mentioned in the presentation...I = do not think there was any protocol or physical limitations fixing it to = 2304B. What I found on some books is that it has been 'chosen' as such.. The = idea I think was to allow upper layers to transmit combinations of 256 bytes (including extra headers..). Maybe somebody could find the true = reasoning behind this value... The maximum length of a 802.11a embedded MAC frames on the PHY layer = (so, maximum PSDU) is encoded in 12 bits, giving a maximum length of 4048 = bytes. So, in theory, it could get higher than 1500 bytes..and as matter of = fact, if 802.11a allows up MSDU to 2304 bytes, 802.11ac allows up to 11 454 bytes...but keeping in mind that the maximum transmit time is 5ms...so = .11ac benefits from high modulation and wider bands. In our case, 802.11-2012 for 5GHz fixes indeed 2304 as maximum MSDU, = reduced in practice to 1500 for IP traffic.=20 Now, if we take a bottom up approach and fix transmit time to 1ms = (instead of 5ms), fix modulation to 6Mpbs and 10Mhz channel, then 'effective' = PPDU (PLCP frame) is reduced to 750 bytes...and accordingly, 726B of MAC = MPDU, so 692 of MSDU and removing SNAP, 684Bytes effective for L3+ packets. That = is small I have to admit...even for CAMs/DENMs. --- So, as MTU to the draft, we could follow three approaches, which = strongly depend on how sensitive IPv6 would be with incorrect MTUs..:=20 Solution A: easy one: take the 802.11 standard value...2304 = Bytes...cannot be wrong, but will not by any mean provide a 'true' mMTU that could be useful to IPv6 in challenging conditions. Solution B (the neutral way): take the mMTU required by IPv6 without any further support from ITS-G5. Cannot be wrong as well, as lower than = 2304, but same as before, will not reflect the true transfer unit in = challenging vehicular communications. Solution C: take the mMTU of IPv6 as threshold requirement for IPv6 = packets to be sent on ITS-G5 (stronger requirement than solution B), define a maximum transmit duration (I mentioned 1ms, but maybe this is extreme..) that ITS-G5/DSRC can allocate for each IPv6 packet and use this to = configure a mMTU for different modulations (and write it in the IETF draft, so it = ends up like a look-up table). For all MTU that are lower than the mMTU = required by IPv6, IPv6 'should' not be able to be transmitted on ITS-G5.=20 What do you think? Best Regards, J=E9r=F4me From nobody Thu Jul 28 07:24: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 CF39312D0AD for ; Thu, 28 Jul 2016 07:24:10 -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 POwccE1eyfKT for ; Thu, 28 Jul 2016 07:24:06 -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 9C8FA12D78B for ; Thu, 28 Jul 2016 07:24:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7C39430047E for ; Thu, 28 Jul 2016 10:24:04 -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 10026) with ESMTP id gr-FAnvoxU62 for ; Thu, 28 Jul 2016 10:24:03 -0400 (EDT) Received: from [5.5.33.33] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 55F2A3002A1 for ; Thu, 28 Jul 2016 10:24:03 -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: <3ab766e1-1c5c-4910-f2fb-7f14f3071f77@htt-consult.com> Date: Thu, 28 Jul 2016 10:23:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1d2dd5c8-8149-c2c5-ab48-25c9a2871189@htt-consult.com> <7e2d1572-9333-7d74-30ad-c47cd0d8512f@htt-consult.com> <7234D8CC1B664F878FAA845C4061AD7C@china.huawei.com> <4d95a92d-6dad-2ee5-5a41-70c8b9d11397@fischer-tech.eu> <5c4c4684-a3bf-f208-b6ed-1bd9bbf052b2@htt-consult.com> <3ab766e1-1c5c-4910-f2fb-7f14f3071f77@htt-consult.com> To: "its@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [its] Charter text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 14:24:11 -0000 I got word from our Area Director that the IESG would like to see a = statement in the charter about coordination with IEEE 802.11. I added = it. Here is the diff: = https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=3Ddiff&versi= on=3D19 Here is the full charter: = https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart Russ From nobody Fri Jul 29 02:52: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 C897C12DA27 for ; Fri, 29 Jul 2016 02:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Wd9CVgs90N3y for ; Fri, 29 Jul 2016 02:52:12 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 044DC12DA2A for ; Fri, 29 Jul 2016 02:52:12 -0700 (PDT) Received: from 34.205.115.87.dyn.plus.net ([87.115.205.34]:56268 helo=[192.168.0.4]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bT4Sf-000318-C2; Fri, 29 Jul 2016 10:52:09 +0100 From: Bob Briscoe To: Alexandre Petrescu , "Carlos Pignataro (cpignata)" Message-ID: <579B2748.2070101@bobbriscoe.net> Date: Fri, 29 Jul 2016 10:52:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010509020401070804020604" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: its@ietf.org Subject: [its] Arguments for using IP for automotive connectivity X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 09:52:15 -0000 This is a multi-part message in MIME format. --------------010509020401070804020604 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Alexandre, Carlos, [cc'ing its@ietf.org, but I'm not subscribed] I just read your article in the IETF Journal about Intelligent Transportation Systems. Your arguments for using IP are largely aspirational or observational (ie. either "we hope IP will be used", or "we notice IP is being used"). This article [Briscoe04] gives some more solid arguments for why it is important and likely that most devices will implement an IP stack. Even though it dates from 2004 I believe most of the points it makes are still relevant. The argument for an interoperable generic stack is spread throughout, but particularly section 2.2 on connectivity, and the sections leading up to the straw-man proposal in section 3.1. First, I'll quote from the conclusions to sum up the economic arguments for a generic stack: "We have questioned the assumption that tiny cheap computing devices will be considered disposable and application-specific. Economies of scale in volume device manufacturing will always favour reuse of the investment in generic device /designs/, whether each unit is disposable or not. Also, the investment in /deploying/ devices will be higher than their cost, tending to encourage new ways to combine deployed devices to novel ends." This last point is based on the idea from [Fine99] that different industries have different "clock-speeds". Because the automotive industry's clock-speed is so much slower than the computing industry's, it will want to deploy computing devices within vehicles that can be soft-updated many times during the vehicle's lifetime. There is also a practical argument about creating connectivity (e.g. how do you platoon a set of cars that includes imported vehicles using different radio frequencies, or vehicles of a wide range of ages?). Quoting from section 2.2: "It is true that humans will often deploy sensor networks for specific purposes and ensure that their wireless transmissions can all reach each other, that they are all transmitting on the same frequencies, with the same codings and with the same application level languages and formats. However, many applications will include the creation of connectivity as part of the application. And it will be desirable to be able to use existing devices and models to create new applications. So we have to allow devices to find each other and form into networks in the first place. [...] There are dozens of radio link standards in fashion at any one time (Bluetooth, the WiFi family, etc), using different frequencies in each region. And hundreds of legacy standards still in use across thousands of different devices. To find each other by radio contact, the [device] would have to scan many frequency ranges and try all common [and legacy] coding, link and message formats (e.g. Jini, SLP, Twine, JESA, etc). The chances of such an approach leading to reliable seamless connectivity, any time, anywhere, are slim unless only one or two link standards predominate for all time. An alternative approach would be to arrange at least the first stages of connectivity over a network common to any randomly chosen pair of devices, which was the purpose of introducing the Internet protocol — an intermediary between different link technologies (‘IP over everything’). So both the PDA and the monitor use their own link technologies to connect to their respective points of presence on the Internet. The monitor advertises its location on a geographical extension of the Web (e.g. geographic mark-up language or SensorML), and the [device], knowing its own location and coverage, uses a geographical search engine to find suitable [peer devices] within range. Clearly, the indirect approach to connectivity may also fail to connect our two devices due to lack of mutually understood standards at the application level (e.g. the XML format of the appropriate geographical search responses). However, the direct link approach has the same chances of mismatch at the application layer on top of the chances of mismatch at the physical, link and transport layers." *References** * [Briscoe04] The Implications of Pervasive Computing on Network Design, Bob Briscoe (BT), chapter in Alan Steventon and Steve Wright (Eds.) Intelligent spaces (2006), Springer Verlag, ISBN: 1-84628-002-8 Pre-print: http://www.bobbriscoe.net/pubs.html#pervimp [Fine99] Fine, Charles H. "Industry clockspeed and competency chain design: An introductory essay." In /Automation in Automotive Industries/, pp. 6-10. Springer Berlin Heidelberg, 1999. http://link.springer.com/chapter/10.1007/978-3-642-59864-7_2#page-1 HTH Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------010509020401070804020604 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Alexandre, Carlos, [cc'ing its@ietf.org, but I'm not subscribed]

I just read your article in the IETF Journal about Intelligent Transportation Systems.

Your arguments for using IP are largely aspirational or observational (ie. either "we hope IP will be used", or "we notice IP is being used").

This article [Briscoe04] gives some more solid arguments for why it is important and likely that most devices will implement an IP stack. Even though it dates from 2004 I believe most of the points it makes are still relevant. The argument for an interoperable generic stack is spread throughout, but particularly section 2.2 on connectivity, and the sections leading up to the straw-man proposal in section 3.1.

First, I'll quote from the conclusions to sum up the economic arguments for a generic stack:
"We have questioned the assumption that tiny cheap computing devices will be considered disposable and application-specific. Economies of scale in volume device manufacturing will always favour reuse of the investment in generic device designs, whether each unit is disposable or not.  Also, the investment in deploying devices will be higher than their cost, tending to encourage new ways to combine deployed devices to novel ends."
This last point is based on the idea from [Fine99] that different industries have different "clock-speeds". Because the automotive industry's clock-speed is so much slower than the computing industry's, it will want to deploy computing devices within vehicles that can be soft-updated many times during the vehicle's lifetime.

There is also a practical argument about creating connectivity (e.g. how do you platoon a set of cars that includes imported vehicles using different radio frequencies, or vehicles of a wide range of ages?). Quoting from section 2.2:
"It is true that humans will often deploy sensor networks for specific purposes and ensure that their wireless transmissions can all reach each other, that they are all transmitting on the same frequencies, with the same codings and with the same application level languages and formats. However, many applications will include the creation of connectivity as part of the application. And it will be desirable to be able to use existing devices and models to create new applications. So we have to allow devices to find each other and form into networks in the first place. [...]

There are dozens of radio link standards in fashion at any one time (Bluetooth, the WiFi family, etc), using different frequencies in each region. And hundreds of legacy standards still in use across thousands of different devices. To find each other by radio contact, the [device] would have to scan many frequency ranges and try all common [and legacy] coding, link and message formats (e.g. Jini, SLP, Twine, JESA, etc). The chances of such an approach leading to reliable seamless connectivity, any time, anywhere, are slim unless only one or two link standards predominate for all time.

An alternative approach would be to arrange at least the first stages of connectivity over a network common to any randomly chosen pair of devices, which was the purpose of introducing the Internet protocol — an intermediary between different link technologies (‘IP over everything’).  So both the PDA and the monitor use their own link technologies to connect to their respective points of presence on the Internet. The monitor advertises its location on a geographical extension of the Web (e.g. geographic mark-up language or SensorML), and the [device], knowing its own location and coverage, uses a geographical search engine to find suitable [peer devices] within range.

Clearly, the indirect approach to connectivity may also fail to connect our two devices due to lack of mutually understood standards at the application level (e.g. the XML format of the appropriate geographical search responses). However, the direct link approach has the same chances of mismatch at the application layer on top of the chances of mismatch at the physical, link and transport layers."
References
[Briscoe04] The Implications of Pervasive Computing on Network Design, Bob Briscoe (BT), chapter in Alan Steventon and Steve Wright (Eds.) Intelligent spaces (2006), Springer Verlag, ISBN: 1-84628-002-8 Pre-print: http://www.bobbriscoe.net/pubs.html#pervimp

[Fine99] Fine, Charles H. "Industry clockspeed and competency chain design: An introductory essay." In Automation in Automotive Industries, pp. 6-10. Springer Berlin Heidelberg, 1999. http://link.springer.com/chapter/10.1007/978-3-642-59864-7_2#page-1


HTH



Bob
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------010509020401070804020604-- From nobody Fri Jul 29 06:32: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 DD67A12D0E5 for ; Fri, 29 Jul 2016 06:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 S5HMLBR2ny94 for ; Fri, 29 Jul 2016 06:31:49 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 6F32C12B010 for ; Fri, 29 Jul 2016 06:31:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 1BDE362273; Fri, 29 Jul 2016 09:31:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nEqV6eV+Ur3T; Fri, 29 Jul 2016 09:31:36 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2E57362271; Fri, 29 Jul 2016 09:31:36 -0400 (EDT) To: Bob Briscoe , Alexandre Petrescu , "Carlos Pignataro (cpignata)" References: <579B2748.2070101@bobbriscoe.net> From: Robert Moskowitz Message-ID: <4b2e1e8d-d65e-64a4-8dd4-1315b8e1c10c@htt-consult.com> Date: Fri, 29 Jul 2016 09:31:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <579B2748.2070101@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------6F79EFFE02B467BCFEC6B7FC" Archived-At: Cc: its@ietf.org Subject: Re: [its] Arguments for using IP for automotive connectivity X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 13:31:57 -0000 This is a multi-part message in MIME format. --------------6F79EFFE02B467BCFEC6B7FC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Having worked, and worked with the Automotive Industry for most of my life, I could refute a number of assumptions stated below. Don't have the energy right now, having just flown on the redeye back from IEEE 802 plenary. but Bob's point about the article in the IETF Journal, I have to agree with. For much the same reasons. Other fights are going on in the Industry. What will happen in the next two years remains a open question. Look for real applications that cannot be met by other services. Consider that IP offers a new attack platform, so carefully consider how to deal with that before offering yet another superhighway into the cars. On 07/29/2016 05:52 AM, Bob Briscoe wrote: > Alexandre, Carlos, [cc'ing its@ietf.org, but I'm not subscribed] > > I just read your article in the IETF Journal about Intelligent > Transportation Systems. > > Your arguments for using IP are largely aspirational or observational > (ie. either "we hope IP will be used", or "we notice IP is being used"). > > This article [Briscoe04] gives some more solid arguments for why it is > important and likely that most devices will implement an IP stack. > Even though it dates from 2004 I believe most of the points it makes > are still relevant. The argument for an interoperable generic stack is > spread throughout, but particularly section 2.2 on connectivity, and > the sections leading up to the straw-man proposal in section 3.1. > > First, I'll quote from the conclusions to sum up the economic > arguments for a generic stack: > > "We have questioned the assumption that tiny cheap computing > devices will be considered disposable and application-specific. > Economies of scale in volume device manufacturing will always > favour reuse of the investment in generic device /designs/, > whether each unit is disposable or not. Also, the investment in > /deploying/ devices will be higher than their cost, tending to > encourage new ways to combine deployed devices to novel ends." > > This last point is based on the idea from [Fine99] that different > industries have different "clock-speeds". Because the automotive > industry's clock-speed is so much slower than the computing > industry's, it will want to deploy computing devices within vehicles > that can be soft-updated many times during the vehicle's lifetime. > > There is also a practical argument about creating connectivity (e.g. > how do you platoon a set of cars that includes imported vehicles using > different radio frequencies, or vehicles of a wide range of ages?). > Quoting from section 2.2: > > "It is true that humans will often deploy sensor networks for > specific purposes and ensure that their wireless transmissions can > all reach each other, that they are all transmitting on the same > frequencies, with the same codings and with the same application > level languages and formats. However, many applications will > include the creation of connectivity as part of the application. > And it will be desirable to be able to use existing devices and > models to create new applications. So we have to allow devices to > find each other and form into networks in the first place. [...] > > There are dozens of radio link standards in fashion at any one > time (Bluetooth, the WiFi family, etc), using different > frequencies in each region. And hundreds of legacy standards still > in use across thousands of different devices. To find each other > by radio contact, the [device] would have to scan many frequency > ranges and try all common [and legacy] coding, link and message > formats (e.g. Jini, SLP, Twine, JESA, etc). The chances of such an > approach leading to reliable seamless connectivity, any time, > anywhere, are slim unless only one or two link standards > predominate for all time. > > An alternative approach would be to arrange at least the first > stages of connectivity over a network common to any randomly > chosen pair of devices, which was the purpose of introducing the > Internet protocol — an intermediary between different link > technologies (‘IP over everything’). So both the PDA and the > monitor use their own link technologies to connect to their > respective points of presence on the Internet. The monitor > advertises its location on a geographical extension of the Web > (e.g. geographic mark-up language or SensorML), and the [device], > knowing its own location and coverage, uses a geographical search > engine to find suitable [peer devices] within range. > > Clearly, the indirect approach to connectivity may also fail to > connect our two devices due to lack of mutually understood > standards at the application level (e.g. the XML format of the > appropriate geographical search responses). However, the direct > link approach has the same chances of mismatch at the application > layer on top of the chances of mismatch at the physical, link and > transport layers." > > *References** > * > > [Briscoe04] The Implications of Pervasive Computing on Network > Design, Bob Briscoe (BT), chapter in Alan Steventon and Steve > Wright (Eds.) Intelligent spaces (2006), Springer Verlag, ISBN: > 1-84628-002-8 Pre-print: http://www.bobbriscoe.net/pubs.html#pervimp > > [Fine99] Fine, Charles H. "Industry clockspeed and competency > chain design: An introductory essay." In /Automation in Automotive > Industries/, pp. 6-10. Springer Berlin Heidelberg, 1999. > http://link.springer.com/chapter/10.1007/978-3-642-59864-7_2#page-1 > > > > HTH > > > > Bob > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --------------6F79EFFE02B467BCFEC6B7FC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Having worked, and worked with the Automotive Industry for most of my life, I could refute a number of assumptions stated below.  Don't have the energy right now, having just flown on the redeye back from IEEE 802 plenary.


but Bob's point about the article in the IETF Journal, I have to agree with.  For much the same reasons.


Other fights are going on in the Industry.  What will happen in the next two years remains a open question.  Look for real applications that cannot be met by other services.  Consider that IP offers a new attack platform, so carefully consider how to deal with that before offering yet another superhighway into the cars.


On 07/29/2016 05:52 AM, Bob Briscoe wrote:
Alexandre, Carlos, [cc'ing its@ietf.org, but I'm not subscribed]

I just read your article in the IETF Journal about Intelligent Transportation Systems.

Your arguments for using IP are largely aspirational or observational (ie. either "we hope IP will be used", or "we notice IP is being used").

This article [Briscoe04] gives some more solid arguments for why it is important and likely that most devices will implement an IP stack. Even though it dates from 2004 I believe most of the points it makes are still relevant. The argument for an interoperable generic stack is spread throughout, but particularly section 2.2 on connectivity, and the sections leading up to the straw-man proposal in section 3.1.

First, I'll quote from the conclusions to sum up the economic arguments for a generic stack:
"We have questioned the assumption that tiny cheap computing devices will be considered disposable and application-specific. Economies of scale in volume device manufacturing will always favour reuse of the investment in generic device designs, whether each unit is disposable or not.  Also, the investment in deploying devices will be higher than their cost, tending to encourage new ways to combine deployed devices to novel ends."
This last point is based on the idea from [Fine99] that different industries have different "clock-speeds". Because the automotive industry's clock-speed is so much slower than the computing industry's, it will want to deploy computing devices within vehicles that can be soft-updated many times during the vehicle's lifetime.

There is also a practical argument about creating connectivity (e.g. how do you platoon a set of cars that includes imported vehicles using different radio frequencies, or vehicles of a wide range of ages?). Quoting from section 2.2:
"It is true that humans will often deploy sensor networks for specific purposes and ensure that their wireless transmissions can all reach each other, that they are all transmitting on the same frequencies, with the same codings and with the same application level languages and formats. However, many applications will include the creation of connectivity as part of the application. And it will be desirable to be able to use existing devices and models to create new applications. So we have to allow devices to find each other and form into networks in the first place. [...]

There are dozens of radio link standards in fashion at any one time (Bluetooth, the WiFi family, etc), using different frequencies in each region. And hundreds of legacy standards still in use across thousands of different devices. To find each other by radio contact, the [device] would have to scan many frequency ranges and try all common [and legacy] coding, link and message formats (e.g. Jini, SLP, Twine, JESA, etc). The chances of such an approach leading to reliable seamless connectivity, any time, anywhere, are slim unless only one or two link standards predominate for all time.

An alternative approach would be to arrange at least the first stages of connectivity over a network common to any randomly chosen pair of devices, which was the purpose of introducing the Internet protocol — an intermediary between different link technologies (‘IP over everything’).  So both the PDA and the monitor use their own link technologies to connect to their respective points of presence on the Internet. The monitor advertises its location on a geographical extension of the Web (e.g. geographic mark-up language or SensorML), and the [device], knowing its own location and coverage, uses a geographical search engine to find suitable [peer devices] within range.

Clearly, the indirect approach to connectivity may also fail to connect our two devices due to lack of mutually understood standards at the application level (e.g. the XML format of the appropriate geographical search responses). However, the direct link approach has the same chances of mismatch at the application layer on top of the chances of mismatch at the physical, link and transport layers."
References
[Briscoe04] The Implications of Pervasive Computing on Network Design, Bob Briscoe (BT), chapter in Alan Steventon and Steve Wright (Eds.) Intelligent spaces (2006), Springer Verlag, ISBN: 1-84628-002-8 Pre-print: http://www.bobbriscoe.net/pubs.html#pervimp

[Fine99] Fine, Charles H. "Industry clockspeed and competency chain design: An introductory essay." In Automation in Automotive Industries, pp. 6-10. Springer Berlin Heidelberg, 1999. http://link.springer.com/chapter/10.1007/978-3-642-59864-7_2#page-1


HTH



Bob
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


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

--------------6F79EFFE02B467BCFEC6B7FC--