From nobody Wed Sep 6 17:22:33 2017 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 7C0541326EC for ; Wed, 6 Sep 2017 17:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 Rq-R1sZ_i5kp for ; Wed, 6 Sep 2017 17:22:24 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F33312ECEC for ; Wed, 6 Sep 2017 17:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=108420; q=dns/txt; s=iport; t=1504743744; x=1505953344; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zxaHPb6et+Phq0xzSjyXL9m3NpwOfKnULviR+ylpRLI=; b=Xro7DtyL0zgt4aK26YftpoCo0sNMPvDB+uaD0EgUETeQ9KnWN1H55ple syWyIBQJvf8zZeukyTnl0wdhE8YaZf6Jt8SuizEJucK9Cj7K7Nf8m49L0 o97AgrZI8YjDo3MkUzdcShJka8/Vrd1SDARqUWFH1LU2E8Y3OUUsNeMiG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAQCNkLBZ/4MNJK1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNaZIEVB6Ajd4dCjX2CAQMCCBgNgV6CbE8ChEJDFAECAQEBAQE?= =?us-ascii?q?BAWsohRkBAQEBAQEBARYCAQxABwICBxACAQgSNCEGCxcOAgQOBRuJfgMNCBCqf?= =?us-ascii?q?QMCDIMQOoFDhXoNhAMBAQEBAQEBAQEBAQEBAQEBAQEBAQEdMgGCcwSBMVGBToF?= =?us-ascii?q?iAYJzNYJXgVcLARAFCgQCFiwGhUIFigYJjg6IGzwCh1mBE4JHg1dPhHaCExs/h?= =?us-ascii?q?Q2DfoEqhAaBSYxThTeCdAIRGQGBOAE2IVsydxVJhRMCAgEcgWd2AQGISIExgQ8?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.42,355,1500940800"; d="scan'208";a="281827005" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2017 00:22:18 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v870MIcl028567 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Sep 2017 00:22:18 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 6 Sep 2017 19:22:17 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Wed, 6 Sep 2017 19:22:17 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandre Petrescu CC: "its@ietf.org" Thread-Topic: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt Thread-Index: AQHTH6nS3MdwWO6+I0K2nyn/HA8hRQ== Date: Thu, 7 Sep 2017 00:22:17 +0000 Message-ID: References: <45acdd94-a77f-14aa-c606-d9f506c9b21d@gmail.com> In-Reply-To: <45acdd94-a77f-14aa-c606-d9f506c9b21d@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: text/plain; charset="Windows-1252" Content-ID: <592420029307FF4DBB996014C27F7731@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 00:22:32 -0000 Alex, Ack! That is fine. I am sure we will have lot more discussions on this draft. I think it needs few more revisions. =20 Sri On 8/30/17, 7:33 AM, "Alexandre Petrescu" wrote: >Sri, > >I want to let yo know I have today finished to read the entire set of >comments. I will try to address them soon. > >Alex > >Le 28/08/2017 =E0 05:00, Sri Gundvelli (sgundave) a =E9crit : >>=20 >> Attached is my review feedback. >>=20 > In general there is lot of good information in the document.But, >> there are also few areas where additional clarifications will reatly >> help. >>=20 >> 1.) Its not clear, if the document makes any asumption on the >> operating environment/communication profile. There is ot much >> discussion on that aspect; For example, Is it always aone-hop >> communication between RSU and OBU where the 802.11-OCB link? So, is >> the use of IPv6 only in that context of 1-hop communication? >>=20 >> 2.) There is also no discussion on how these links get formed in >> vehiclar environment and when they are attached/detached. >>=20 >> 3.) How do ndes discover each other? How does ND resolution work? >> Are these mesages received by a multiple RSU=B9s, or a single RSU? >> Whats the impication of that. Note that you don=B9t have that issue in >> 802.11,given the association to an access point, which in turn maps >> the lins to a VLAN/subnet. >>=20 >> 4.) What happens as a vehicle moves between RU=B9s, how does it impact >> address configuration? Is DHCPv6 ased address configuration >> relevant here? >>=20 >>=20 >> Please see inlie for additional comments. >>=20 >[...] >>=20 >> Transmission of Pv6 Packets over IEEE 802.11 Networks in mode >> Outside >>=20 >>=20 >>=20 >>=20 >>=20 >> the Context of a Basic Service Set (IPv6-over-80211ocb) >>=20 >>=20 >>=20 >>=20 >>=20 >> draft-ietf-ipwave-ipv6-over-80211ocb-04.txt >>=20 >>=20 >>=20 >>=20 >> [Sri] May be change to, =B3.in mode .." =8B> =B3..operating in mode ..= =B2? >>=20 >>=20 >>=20 >> Abstract >=20 >> In order to transmit IPv6 packets on IEEE 802.11 networks run >> outside the context of a basic service set (OCB, earlier "802.11p") >> there is a need to define a few parameters such as the recommended >> Maximum Transmission Unit size, the header format preceding the IPv6 >> header, the Type value within it, and others. This document >> decribes these parameters for IPv6 and IEEE 802.11 OCB networks; it >> portrays the layering of IPv6 on 802.11 OCB similarly to other known >> 802.11 and Etherne layers - by using an Ethernet Adaptation Layer. >>=20 >> Sri] Is it =B3recommended MTU size", or "supported MTU size on the >> 82.11 OCB link? >>=20 >>=20 >>=20 >> In addition, the document attempts to ist what is different in >> 802.11 OCB (802.11p) compared to more 'traditional' 802.11a/b/g/n >> layers, layers over which IPv6 protocols operates without ssues. >> Most notably, the operation outside the context of a BSS (OB) has >> impact on IPv6 handover behaviour and on IPv6 security. >> >> [Sri] Minor comment. May be instead of using the =B3layer=B2 terminol= ogy, >> you may want to present this as IPv6 support on "802.1 OCB" links. >>=20 >>=20 >> An example of an IPv6 packet captured while transmitted over an IEEE >> 802.11 OCB link (802.11p) is given. >>=20 >> [Sri] Last paragraph can be ommitted in my view. That=B9s too much of >> detail for Abstract. >>=20 >>=20 >> Status of This Memo >>=20 >> This Internet-Draft is submitted in full conformance with the >> provisions ofBCP 78 andBCP 79 >> . >>=20 >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF). Note that other groups may also distribute >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 1] >>=20 >> ----------------------------------------------------------------------- >> >> =20 >>=20 >>-2> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> working documents as Internet-Drafts. The list of current Internet->> D= rafts is athttp://datatracker.ietf.org/drafts/current/. >>=20 >> Internet-Drafts are draft documents valid for amaximum of six >> months and may be updated, replaced, or obsoleted by other documents >> at any time. It is inapropriate to use Internet-Drafts as >> reference material or to cite them other than as "work in progress." >>=20 >> This Internet-Draft will expire on February 18, 2018. >>=20 >> Copyright Notice >>=20 >> Copyright (c) 2017 IETF Trust and the persons identified as the >> document authors. All rights reserved. >>=20 >> This document is subject toBCP 78 >> and the IETF Trust's Legal Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) i effect on the date of >> publication of this document. Please review tese documents >> carefully, as they describe your rights and restrictios with >> respect to this document. Code Components extracted from this >> documet must include Simplified BSD License text as described in >> ection 4.e of the Trust Legal Provisions and are provided without >> arranty as described in the Simplified BSD License. >>=20 >> Table of Contents >>=20 >> 1=20 >>=20 >>>io-1>. >> Introduction . . . . . . . . . . . . . . . . . . . . . . . .3>>=20 >>>-3> >> >>=20 >2 >>=20 >>>ion-2>. >> Terminology . . . . . . . . . . . . . . . . . . . . . . . . .5 >>=20 >>-5> >> >>=20 >3. Communication Scenarios where IEEE 802.11 OCB Lins are Used 6 >> 4=20 >>=20 >>>ion-4>. >> Aspects introduced by the OCB mode to 802.11 . . . . . . . .6 >>=20 >>>-6> >> >>=20 >5 >>=20 >>>ion-5>. >> Layering of IPv6 over 802.11-OCB as over Ethernet . . . . . .10 >>=20 >>>-10> >> >>=20 >5.1 >>=20 >>>ion-5.1>. >> aximum Transmission Unit (MTU) . . . . . . . . . . . . .10 >>=20 >>>-10> >> >>=20 >5.2 >>=20 >>>ion-5.2> >> Frame Format . . . . . . . . . . . . . . . . . . . . . .11 >>=20 >>https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#pag >>-11> >> >>=20 >5.2.1 >>=20 >>>ion-5.2.1>. >> Ethernet AdaptationLayer . . . . . . . . . . . . . .12 >>=20 >>>-12> >> >>=20 >5.3 >>=20 >>>ion-5.3>. >> Link-Local Addresses . . . . . . . . . . . . . . . . . .13 >>=20 >>>-13> >> >>=20 >5.4 >>=20 >>>ion-5.4>. > Address Mapping . . . . . . . . . . . . . . . . . . . . .14 >>=20 >>>-14> >> >>=20 >5.4.1 >>=20 >>>ion-5.4.1>. >> Address Mapping -- Unicast . . . . . . . . . . . . .14 >>=20 >>>-14> >> >>=20 >5.4.2 >>=20 >>>ion-5.4.2>. >> Address Mapping -- Multicast . . . . . . . . . . . .14 >>=20 >>>-14> >> >> >5.5 >>=20 >>>ion-5.5>. >> Stateless Autoconfiguration . . . . . . .. . . . . . . .15 >>=20 >>>-15> >> >>=20 >5.6 >>=20 >>>ion-5.6>. >> Subnet Structure . . . . . . . . . . . . . . . . . . . .16 >>=20 >>>-16> >> >>=20 >6 >>=20 >>>ion-6>. >> Example IPv6 Packet captured over a IEEE 802.11-OCB link . .16 >>=20 >>>-16> >> >>=20 >6.1 >>=20 >>>ion-6.1>. >> Capture in Monitor Mode . . . . . . . . . . . . . . . . .17 >>=20 >>>-17> >> >>=20 >6.2 >>=20 >>>ion-.2>. >> Capture in Normal Mode . . . . . . . . . . . . . . . . .19 >>=20 >>>-19> >> >>=20 >7 >>=20 >>>ion-7>. > Security Considerations . . . . . . . . . . . . . . . . . . .21 >>=20 >>https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page >>-21> >> >>=20 >8 >>=20 >>>ion-8>. >> IANA onsiderations . . . . . . . . . . . . . . . . . . . . .22 >>=20 >>>-22> >> >>=20 >9 >>=20 >>>ion-9>. >> Contributors . . . . . . . . . . . . . . . . . . . . . . .22 >>=20 >>>-22> >> >>=20 >10 >>=20 >>>ion-10>. > Acknowledgements . . . . . . . . . . . . . . . . . . . . . .22 >>=20 >>-22> >> >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 Page 2] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-3> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> 11=20 >>=20 >>>ion-11>. >> References . . . . . . . . . . . . . . . . . . . . . . . . .23 >>=20 >>>-23> >> >>=20 >11.1 >>=20 >>>ion-11.1>. >> Nrmative References . . . . . . . . . . . . . . . . . .23 >>=20 >>>-23> >> >>=20 >11.2 >>=20 >>>ion-11.2>. >> Informative References . . . . . . . . . . . . . . . . .24 >>=20 >>>-24> >> >>=20 >Appendix A >>=20 >>>ndix-A>. >> ChangeLog . . . . . . . . . . . . . . . . . . . . .26 >>=20 >>>-26> >> >>=20 >Appedix B >>=20 >>>ndix-B>. >> Changes Needed on a software driver 802.11a to become a >> 802.11-OCB driver . . 28 >>=20 >>>-28> >> >>=20 >Appendix C >>=20 >>ndix-C>. >> Design Considerations . . . . . . . . . . . . . . .30 >>=20 >>>-30> >> >>=20 >C.1 >>=20 >>>ndix-C.1>. >> Vehicle ID . . . . . . . . . . . . . . . . . . . . . . .30 >>=20 >>>-30> >> >>=20 >C.2 >>=20 >>>ndix-C.2>. >> Reliability Requirements . . . . . . . . . . . . . . . .30 >>=20 >>>-30> >> >>=20 >C.3 >>=20 >>>ndix-C.3>. >> Multiple interfaces . . . . . . . . . . . . . . . . . . .31 >>=20 >>>-31> >> >>=20 >C.4 >>=20 >>>ndix-C.4>. >> MAC Address Generation . . . . . . . . . . . . . . . . .32 >>=20 >>>-32> >> >>=20 >Appendix D >>=20 >>>ndix-D>. >> IEEE 802.11 Messages Transmitted i OCB mode . . . .32 >>=20 >>>-32> >> >>=20 >Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .32 >>=20 >>>-32> >> >>=20 >>=20 >> 1=20 >>=20 >>>ion-1>. >> >>=20 >Introduction >>=20 >>=20 >>=20 >> This document decribes the transmission of IPv6 packets on IEEE Std >> 802.11 OCB networks (earlier known as 802.11p). >>=20 >>=20 >> [Sri] Please add a reference to the IEEE specification that defines >> the OCB mode. >>=20 >>=20 >>=20 >> This involves the layering of IPv6 networking o top of the IEEE >> 802.11 MAC layer (with an LLC layer). Compared to running IPv6 over >> the Ethernet MAC layer, there is no modification required to the >> standards: IPv6 works fine directly over 802.11 OCB too (with an LLC >> layer. >>=20 >> The term "802.11p" is an earlier definition. As of year 2012, the >> behaviour of "802.11p" networks has been rolled in the documen IEEE >> Std 802.11-2012. In this document the term 802.11p disappears. >> Instead, each 802.11p feature is conditioned by a flag in the >> Management Information Base. That flag is named "OCBActivated". >> Whenever OCBActivated s set to true the feature it relates to >> represents an earlier 802.11p feature. For example, an802.11 >> STAtion operating outside the context of a basic service set has the >> OCBActivated flag set. Such a statio, when it has the flag set, it >> uses a BSS identifier equal to ff:ff:ff:ff:ff:ff. >>=20 >> In the following text we use the term "802.11p" to mean 802.11-2012 >> OCB. >>=20 >> The IPv6 network layer operates on 802.11 OCB in the same manner as >> it operates on 802.11 WiFi, with a few particular exceptions. The >> IPv6 network layer operates on WFi by involving an Ethernet >> Adaptation Layer; this Ethernet Adaptation Layer maps 802.11 headers >>to Ethernet II headers. The operation of IP on Ethernet is >> described in [RFC1042 ] and >> [RFC464 ]. The situation of >> IPv6 networking layer on Ethernet Adaptation Layer is illustrated >> below: >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 3]>>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-4> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 >> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet >> Adaptation Layer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> 802.11 WiFi MAC | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.11 WiFi >> PHY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >> (in the above figure, a WiFi profile is represented; this is used >> also for OCB profile.) >>=20 >> A more theoretical and detailed view of layer stacking, and >> interfaces between the IP layer and 802.11 OCB layers, is >> illustrated below. The IP layer operates on top of the EtherType >> Protocol Discrimination (EPD); this Discrimination layer is described >> in IEEE Std 802.3-2012; the interface between IPv6 and EPD is the >> LLC_SAP (Lin Layer Control Service Accesss Point). >>=20 >>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 >> | +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ { LLC_SAP } >> 802.11 OCB +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary | >> EPD | | | | | LME | >> | +-+-+-{ MAC_SAP }+-+-+-| MLME_SAP | | MAC Sublayer >> | | | 802.11 OCB | and ch. coord. | | SME | >> Services -+-+-{ PHY_SAP }+-+-+-+-+-+-+-| | | >> | PLME | | PHY Layer | PLME_SAP | >> +-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+>>=20 >>=20 >> In addition to the description of interface between IP and MAC using >> "Ethernet Adaptation Layer" and "Ethernet Protocol Discrimination >> (EPD)" it is worth mentioning that SNAP [RFC1042 >> ] is used to carry the IPv6 >> Ethertype. >>=20 >> However, there may be some deployment consideratios helping >> optimize the performances of running IPv6 over 802.11-OCB (e.g. in >> the case of handovers between 802.11 OCB-enabled access routers, or >> the consideration of using the IP security layer [RFC4301 >> ]). >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 4] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-5> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> There are currently no specifications for handover between OCB links >> since these are currently specified as LLC-1 links (i.e. >> connectionless). Any handovers must be performed above the Data >> Link Laer. Also, while there is no encryption applied below the >> network lyer using 802.11p, 1609.2 [ieee1609.2 >>=20 >>>ieee1609.2>] >> does provide security services for applications to use so that there >> can easily be data security over the air without ivoking IPsec. >>=20 >> We briefly introduce the vehicula communication scenarios where >> IEEE 802.11-OCB links are used. >>=20 >>=20 >> [Sri] I have not seen much discussion on the link / communication >> assumptions. >>=20 >>=20 >>=20 >> This is followed by a description of differences i specification >> terms, between 802.11 OCB and 802.11a/b/gn (and the same differences >> expressed in terms of requirements to software implementation are >> listed inAppendix B >>=20 >>>ndix-B>.) >> >> The document then concentrates on the parameters of layering IP >> over 802.11 OCB as over Ethernet: value of MTU, the contents of >> Frame Format, the rules for forming Interface Identifiers, the >> mechanism for Address Mapping and for State-less Address >> Auto-configuration. These are precisely the same as IPv6 over >> Ethernet [RFC2464 ]. >>=20 >> As an example, these characteristics of layering IPv6 straight over >> LLC over 802.11 OCB MAC are illustrated by dissecting an IPv6 packet >> captured over a 802.11 OCB link; this is described in the section >> Section 6=20 >>=20 >>>ion-6>. >> >> A couple of points can be considered as different, although they >> are not required in order to have a working implementation of >> IPv6-over- 802.11-OCB. These points ar consequences of the OCB >> operation wich is particular to 802.11 OCB (Outside the Context of a >> BSS). First, the handovers betweenOCB links need specific behaviour >> for IP Router Advertisements, or otherwise 802.11 OCB's Time >> Advertisement, or of higher layer messages such as the 'Basic Safety >> Message' (in the US) or the 'Cooperative Awareness Message' (in the >> EU) o the 'WAVE Routing Advertisement'; second, the IP security >> mechanisms are necessary, since OCB means that 802.11 is stripped of >> all 802.11 link-layer security; a small additional security aspect >> which is shared between 802.11 OCB and other 802.11 links is the >> rivacy concerns related to the address fomation mechanisms. >>=20 >> In the published literature, many document describe aspects related >> o running IPv6 over 802.11 OCB: >> [I-D.jeong-ipwave-vehicular-networking-survey >>=20 >>>I-D.jeong-ipwave-vehicular-networking-survey>]. >> >>=20 >>=20 >> 2=20 >>=20 >>>ion-2>. >> >=20 >Terminology >>=20 >>=20 >>=20 >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT" >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be inerpreted as described inRFC 2119 >> [RFC2119 >> ]. >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 5] >>=20 >> ----------------------------------------------------------------------- >> >> =20 >>=20 >>>-6> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> RSU: Road Side Unit. A computer equipped with at least one IEEE >> 802.11 interface operated in OCB mode. This definition applies to >> this document. An RSU may be connected to the Internet, and may be >> equipped with additional wired or wireless network interfaces >> running IP. An RSU MAY be an IP Router. >>=20 >>=20 >> [Sri] RSU can be comparedto an 802.11 access point; Or, WTP as >> defined in CAPWAP specification, RFC5415. >>=20 >>=20 >> Peraps. rephrase as below?: >>=20 >>=20 >> "RSU: Road Side Unit. Its a wireless termination point (WTP), as >> defined in RFC5415 with one key difference, where the wireless >> physical and the mac layer is configured to operate in 802.11 OCB >> mode. The RSU communicates with the On board Unit (OBU) in the >> vehicle over 802.11 wireless link operating in OCB mode.=B2 >>=20 >>=20 >>=20 >> ** Also, since you are defining the RSU term, should you also not >> define OBU (On board Unit) in the vehicle which is the entity on the >> other end of the link? =B3RSU ----802.11-OCB=8B=8BOBU=B2 ? May be introd= uce >> the OCB definition separately, just as you did with RSU, and show the >> communication link as 802.11-OCB. >>=20 >>=20 >>=20 >> OCB: outside the context of a basic service set (BSS): A mode of >> operation in which a STA is not a member of a BSS and does not >> utilize IEEE Std 802.11 authntication, association, or data >> confidentiality. >>=20 >> 802.11-OCB, or 802.11 OCB: text in document IEEE 802.11-2012that is >> flagged by "dot11OCBActivated". This means: IEEE 802.11e for >> quality of service; 82.11j-2004 for half-clocked operations; and >> (what was known earlier as) 802.11p for operation in the 5.9 GHz band >> and in mode OCB. >>=20 >>=20 >> [Sri] The text starting with. =B3This means=B2 is not clear to me. Does >> it 802.11e is supported with 802.11OCB mode. Please clarify >>=20 >>=20 >>=20 >> 3=20 >>=20 >>>in-3>. >> >>=20 >Communication Scenarios where IEEE 802.11 OCB Links are Used >>=20 >>=20 >>=20 >> The IEEE 802.11 OCB Networks are used for vehicular communicatons, >> as 'Wireless Access in Vehicular Environments'. The IP >> communication scenarios for these environments have been desribed in >> several documents, among which we refer the reader to one recently >> updated [I-D.petrscu-its-scenarios-reqs >>=20 >>>I-D.petrescu-its-scenarios-reqs>], >> about scenarios and requirements for IP in Intelligent Transportation >> Systems. >>=20 >>=20 >> [Sri] You can do bit more justice to this section. >>=20 >> Explain the link model. =B3STA ----802.11-OCB=8B=8BSTA=B2. Then talk abo= ut >> the applicability in Vehicular networks, with STA's as RSU and OCB. >>=20 >> You may also want to talk about, how links get ormed/terminated; how >> nodes peer/discover and how mobility works ..etc. While 802.11-OCB >> i clearly specified and the use of IPv6 over such link is also not >> radically new, but the operating environment which is vehicular >> brings many new things. That description is not present any where. >>=20 >>=20 >> 4=20 >>=20 >>>ion-4>. >> >>=20 >Aspects introduced by the OCB mode to 802.11 >>=20 >=20 >>=20 >> In the IEEE 802.11 OCB mode, all nodes in the wireless range can >> directly communicate with each other without autentication/ >> association procedures. Briefly, the IEEE 802.11 OCB mode has the >> following properties: >>=20 >>=20 >>=20 >> [Sri] Can you add some text on how nodes (ST1 and STA2) discover each >> other on such links supporting 802.11 OCB mode. >>=20 >> o The use by each node of a 'wildcard' BSSID (i.e., ech bit of the >> BSSID is set to 1) >>=20 >> o No IEEE 802.11 Beacon frames transmitted >>=20 >> o No authentication required >>=20 >> o No association needed >>=20 >> o No encryption provided >>=20 >>=20 >> [Sri] Can you clarify what you mean when you say =B3No xxx required=B2 / >> =B3No xxx needed=B2 for the above capabilities. What does =B3needed=B2 = or >> =B3required=B2 mean? Does it mean, =B3Authentication", =B3Association" a= nd >> =B3Encryption=B2 is optional on this link, or that its not supported on >> 802.11 OCB links. >>=20 >>=20 >>o Flag dot11OCBActivated set to true >>=20 >> The following message exchange diagram illustrates a comparison >> between traditional 802.11 and 802.11 in OCB mode. The 'Data' >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 6] >>=20 >> ----------------------------------------------------------------------- >> >> =20 >>=20 >>>-7> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> messages can be IP messages such as the messages used in Stateless >> or Stateful Address Auto-Configuration, or other IP messages. >>=20 >>=20 >>=20 >> [Sri] Lets separatethe discussion on IP Address configuration using >> SLAAC/DHCP on such links from the above description. The Data packets >> here can be application packets such as HTTP or other packets. May >> be additional discussion is needed on the IP addres configuration on >> 802.11-OCB links. >>=20 >>=20 >>=20 >> Other 802.11 anagement and control frames (non IP) may be >> transmitted, as specified in the 802.11 standard. For information, >> the ames of these messages as currently specified by the 802.11 >> standard are listed inAppendix D >>=20 >>>ndix-D>. >> >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> STA AP STA1 STA2 | >> | | | |<------ Beacon -------| >> |<------ Data -------->| | | | >> | |---- Probe Req. ----->| |<------ Data -------->| >> |<--- Probe Res. ------| | | | >> | |<------ Data -------->| |---- Auth Req. ------>| >> | | |<--- Auth Res. -------| >> |<------ Data -------->| | | | >> | |---- Asso Req. ------>| |<------ Data -------->| >> |<--- Asso Res. -------| | | | >> | |<------ Data -------->| |<------ Data -------->| >> | | |<------ Data -------->| >> |<------ Data -------->| >>=20 >> (a) 802.11 Infrastructure mode (b) 802.11 OCB mode >>=20 >>=20 >> The link 802.11 OCB was specified in IEEE Std 802.11p (TM) -2010 >> [ieee802.11p-2010 >>=20 >>>ieee802.11p-2010>] >> as an amendment to IEEE Std 802.11 (TM) -2007, titled "Amendment 6: >> Wireless Access in Vehicular Environments". Since then, this >> amedment has been included in IEEE 802.11(TM)-2012 [ieee802.11-2012 >>=20 >>=20 >>>ieee802.11-2012>], >> titled "IEEE Standard for Information technology-- Telecommunications >> and information exchange between systems Local and metropolitan area >> networks--Specific requirements Part 11: Wireless LAN Medium Access >> Control (MAC) and Physical Layer (PHY) Specifications"; the >> modifications are diffused throughout various sections (e.g. the Time >> Advertisement message described in the earlier 802.11 (TM) p >> amendment is now described in section 'Frame formats', and the >> operation outside the context of a BSS described in section 'MLME'). >>=20 >> In document 802.11-2012, specifically anything referring >> "OCBActivated", or "outside the context of a basic service set" is >> actually referring to the 802.11p aspects introduced to 80.11. >> Note that in earlier 802.11p documents the term "OCBEnabled" was>> used = instead of te current "OCBActivated". >>=20 >>=20 >>=20 >>=20 >>=20 >> Perescu, et al. Expires February 18, 2018 [Page 7] >>=20 >> ----------------------------------------------------------------------- >> >> =20 >>=20 >>-8> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 > In order to delineate the aspects introduced by 802.11 OCB to >> 802.1, we refer to the earlier [ieee802.11p-2010 >>=20 >>>ieee802.11p-2010>]. >> The amendment is concerned with vehicular communications, where the >> wireles link is similar to that of Wireless LAN (using a PHY layer >> specifid by 802.11a/b/g/n), but which needs to cope with the high >> mobility factor inherent in scenarios of communications between >> moving vehicles, and between vehicles and fixed infrastructure >> deployed along roads. While 'p' is a ltter just like 'a, b, g' and >> 'n' are, 'p' is concerned more wit MAC modifications, and a little >> with PHY modifications; the thers are mainly about PHY >> modifications. It is possible in practice to combine a 'p' MAC with >> an 'a' PHY by operating outside the context of a BSS with OFDM at >> 5.4GHz. >>=20 >> The 802.11 OCB links are specified to be compatible as much as >> possible with the behaviour of 802.11a/b/g/ and future generation >> IEEE WLAN links.* From the IP perspective, a 802.11 OCB MAC layer >> offers practically the same interface to IP a the WiFi and Ethernet >> layers do (802.11a/b/g/n and 802.3).* >>=20 >>=20 >> [Sri] A packet sent from a vehicle=B9s OBU is received by a single RSU, >> or multiple RSU=B9s? How does the link-layer resolution happen? >>=20 >>=20 >> To support this similarity statement (IPv6 is layered on top of LLC >> on top of 802.11 OCB similarly as on top of LLC on top of >> 802.11a/b/g/n, and as on top of LLC on top of 802.3) it is useful to >> analyze the differences between 802.11 OCB and 802.11 >> specifications. Whereas the 802.11p amendment specifies relatively >> complex and numerous changes to the MAC layer (and very little to the >> PHY layer), we note there are only a few characteristics which may be >> important for an implementation transmitting IPv6 packets on 802.11 >> OCB links. >>=20 >> In the list below, the only 802.11 OCB fundamental points which >> influence IPv6 are the OCB operation and the 12Mbit/s maximum which >> may be afforded by the IPv6 applications. >>=20 >>=20 >> [Sri] I am really not sure how lik throughput (12Mbps) relates to >> "IPv6 support on OCB links". >>=20 >> >>=20 >> o Operation Outside the Context of a BSS (OCB): the (earlier >> 802.11p) 802.11-OCBlinks are operated without a Basic Service Set >> (BSS). This means tht the frames IEEE 802.11 Beacon, Association >> Request/Response, Authentication Request/Response, and similar, are >> not use. The used identifier of BSS (BSSID) has a hexadecimal value >> alwys 0xffffffffffff (48 '1' bits, represented as MAC address >> ff:ffff:ff:ff:ff, or otherwise the 'wildcard' BSSID), as opposed to >> an arbitrary BSSID alue set by administrator (e.g. >> 'My-Home-AccessPoint'). The OCB operation - namely the lack of >> beacon-based scanning and lack of authentication - has a potentially >> strong impact on the use of the Mobile IPv6 protocol [RFC6275 >> ] and on the protocols for IP >> layer security [RFC4301 ]. >>=20 >>=20 >> [Sri] The document till now has been arguing heavily on how IPv6=20 >> operates so naturally on these links and now I see discussion on >> =B3Impact to a high-level protocol such as MIPv6=B2. You may want to fix >> the earlier text. In any case, the absence of link-layer security >> practically impacts every application, not just MIPv6. Also, MIPv6 >> does not make any assumptions on the link-layer security. Also, the >> the 0xFF-FF-FF-FF-FF-FF as the BSSID, makes the messages readable by >> all other RSU=B9s in proximity. I think the discussion on the nature of >> the link, who all see=B9s the messages.. how L2 addresses are resolved >> is not explained clearly. >>=20 >>=20 >>=20 >>=20 >> o Timing Advertisement: is a new message defined in 802.11-OCB,=20 >> which does not exist in 802.11a/b/g/n. This message is used by >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 8] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-9> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> stations to inform other stations about the value of time. It is=20 >> similar to the time as delivered by a GNSS system (Galileo, GPS, ...) >> or by a cellular system. This message is optional for=20 >> implementation.*At the date of writing, an experienced reviewer >> considers that currently no field testing has used this message. >> Another implementor considers this feature implemented in an initial >> manner. In the future, it is speculated that this message may be >> useful for very simple devices which may not have their own hardware >> source of time (Galileo, GPS, cellular network), or by vehicular >> devices situated in areas not covered by such network (in tunnels, >> underground, outdoors but shaded by foliage or buildings, in remote >> areas, etc.) * >>=20 >>=20 >> [Sri] The first part explaining Timing Advertisement messages is >> great, but the rest of the commentary is unnecessary and not needed. >> We don=B9t speculate the protocol adoption success in IETF >> specifications, or about the experience level of the =B3reviewer" :) >>=20 >>=20 >>=20 >> o Frequency range: this is a characteristic of the PHY layer, with=20 >> almost no impact to the interface between MAC and IP. However, it is >> worth considering that the frequency range is regulated by a regional >> authority (ARCEP, ETSI, FCC, etc.); as part of the regulation >> process, specific applications are associated with specific frequency >> ranges. In the case of 802.11-OCB, the regulator associates a set of >> frequency ranges, or slots within a band, to the use of applications >> of vehicular communications, in a band known as "5.9GHz". This band >> is "5.9GHz" which is different from the bands "2.4GHz" or "5GHz" used >> by Wireless LAN. However, as with Wireless LAN, the operation of >> 802.11-OCB in "5.9GHz" bands is exempt from owning a license in EU >> (in US the 5.9GHz is a licensed band of spectrum; for the the fixed >> infrastructure an explicit FCC autorization is required; for an >> onboard device a 'licensed-by-rule' concept applies: rule >> certification conformity is required); however technical conditions >> are different than those of the bands "2.4GHz" or "5GHz". On one >> hand, the allowed power levels, and implicitly the maximum allowed >> distance between vehicles, is of 33dBm for 802.11-OCB (in Europe), >> compared to 20 dBm for Wireless LAN 802.11a/b/g/n; this leads to a >> maximum distance of approximately 1km, compared to approximately 50m. >> On the other hand, specific conditions related to congestion=20 >> avoidance, jamming avoidance, and radar detection are imposed on the >> use of DSRC (in US) and on the use of frequencies for Intelligent >> Transportation Systems (in EU), compared to Wireless LAN >> (802.11a/b/g/n). >>=20 >> o Prohibition of IPv6 on some channels relevant for IEEE >> 802.11-OCB, as opposed to IPv6 not being prohibited on any channel on >> which 802.11a/b/g/n runs: >>=20 >> * Some channels are reserved for safety communications; the IPv6=20 >> packets should not be sent on these channels. >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 9] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-10> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> * At the time of writing, the prohibition is explicit at higher=20 >> layer protocols providing services to the application; these higher >> layer protocols are specified in IEEE 1609 documents. >>=20 >> * National or regional specifications and regulations specify the=20 >> use of different channels; these regulations must be followed. >>=20 >> o 'Half-rate' encoding: as the frequency range, this parameter is=20 >> related to PHY, and thus has not much impact on the interface between >> the IP layer and the MAC layer. >>=20 >> o In vehicular communications using 802.11-OCB links, there are=20 >> strong privacy requirements with respect to addressing. While the=20 >> 802.11-OCB standard does not specify anything in particular with=20 >> respect to MAC addresses, in these settings there exists a strong=20 >> need for dynamic change of these addresses (as opposed to the non-=20 >> vehicular settings - real wall protection - where fixed MAC addresses >> do not currently pose some privacy risks). This is further described >> in sectionSection 7=20 >>=20 >>>ion-7>. >> A relevant function is described in IEEE 1609.3-2016 [ieee1609.3=20 >>=20 >>>ieee1609.3>], >> clause 5.5.1 and IEEE 1609.4-2016 [ieee1609.4=20 >>=20 >>>ieee1609.4>], >> clause 6.7. >>=20 >>=20 >> Other aspects particular to 802.11-OCB which are also particular to=20 >> 802.11 (e.g. the 'hidden node' operation) may have an influence on=20 >> the use of transmission of IPv6 packets on 802.11-OCB networks.*The >> subnet structure which may be assumed in 802.11-OCB networks is=20 >> strongly influenced by the mobility of vehicles.* >>=20 >>=20 >> [Sri] Per my earlier comment, the link model, addressing ..etc needs >> to be explained in more detail. It is not clear what exactly the >> =B3subnet structure=B2 that is assumed in 802.11-OCB. >>=20 >>=20 >> 5=20 >>=20 >>>ion-5>. >> >>=20 >Layering of IPv6 over 802.11-OCB as over Ethernet >>=20 >>=20 >>=20 >> 5.1=20 >>=20 >>>ion-5.1>. >> >>=20 >Maximum Transmission Unit (MTU) >>=20 >>=20 >>=20 >> The default MTU for IP packets on 802.11-OCB is 1500 octets. It is=20 >> the same value as IPv6 packets on Ethernet links, as specified in=20 >> [RFC2464 ]. This value of the >> MTU respects the recommendation that every link in the Internet must >> have a minimum MTU of 1280 octets (stated in [RFC2460 >> ], and the recommendations >> therein, especially with respect to fragmentation). If IPv6 packets >> of size larger than 1500 bytes are sent on an 802.11-OCB interface >> card then the IP stack will fragment. In case there are IP >> fragments, the field "Sequence number" of the 802.11 Data header >> containing the IP fragment field is increased. >>=20 >> Non-IP packets such as WAVE Short Message Protocol (WSMP) can be=20 >> delivered on 802.11-OCB links. Specifications of these packets are=20 >> out of scope of this document, and do not impose any limit on the >> MTU size, allowing an arbitrary number of 'containers'. Non-IP >> packets such as ETSI 'geonet' packets have an MTU of 1492 bytes. >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 10] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-11> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> The Equivalent Transmit Time on Channel is a concept that may be >> used as an alternative to the MTU concept. A rate of transmission >> may be specified as well. The ETTC, rate and MTU may be in direct=20 >> relationship. >>=20 >> [Sri] The last paragraph needs some additional context. Did >> 802.11-OCB introduce ETTC concept? >>=20 >>=20 >>=20 >>=20 >> 5.2=20 >>=20 >>>ion-5.2>. >> >>=20 >Frame Format >>=20 >>=20 >>=20 >> IP packets are transmitted over 802.11-OCB as standard Ethernet=20 >> packets. As with all 802.11 frames, an Ethernet adaptation layer is=20 >> used with 802.11-OCB as well. This Ethernet Adaptation Layer=20 >> performing 802.11-to-Ethernet is described inSection 5.2.1=20 >>=20 >>>ion-5.2.1>. >> The Ethernet Type code (EtherType) for IPv6 is 0x86DD (hexadecimal >> 86DD, or otherwise #86DD). >>=20 >> The Frame format for transmitting IPv6 on 802.11-OCB networks is the=20 >> same as transmitting IPv6 on Ethernet networks, and is described in=20 >> section 3 of [RFC2464] >> . The frame format >> for transmitting IPv6 packets over Ethernet is illustrated below: >>=20 >>=20 >> 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination |=20 >> +- -+ | Ethernet |=20 >> +- -+ | Address |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source |=20 >> +- -+ | Ethernet |=20 >> +- -+ | Address |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1|=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 |=20 >> +- -+ | header |=20 >> +- -+ | and |=20 >> +- -+ / payload ... /=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Each tic mark represents one >> bit.) >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 11] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-12> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> Ethernet II Fields: >>=20 >> Destination Ethernet Address the MAC destination address. >>=20 >> Source Ethernet Address the MAC source address. >>=20 >> 1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1 binary representation of the >> EtherType value 0x86DD. >>=20 >> IPv6 header and payload the IPv6 packet containing IPv6 header and >> payload. >>=20 >>=20 >> 5.2.1=20 >>=20 >>>ion-5.2.1>. >> >>=20 >Ethernet Adaptation Layer >>=20 >>=20 >>=20 >> In general, an 'adaptation' layer is inserted between a MAC layer >> and the Networking layer. This is used to transform some parameters=20 >> between their form expected by the IP stack and the form provided by=20 >> the MAC layer. For example, an 802.15.4 adaptation layer may >> perform fragmentation and reassembly operations on a MAC whose >> maximum Packet Data Unit size is smaller than the minimum MTU >> recognized by the IPv6 Networking layer. Other examples involve >> link-layer address transformation, packet header insertion/removal, >> and so on. >>=20 >> An Ethernet Adaptation Layer makes an 802.11 MAC look to IP=20 >> Networking layer as a more traditional Ethernet layer. At >> reception, this layer takes as input the IEEE 802.11 Data Header and >> the Logical-Link Layer Control Header and produces an Ethernet II >> Header. At sending, the reverse operation is performed. >>=20 >>=20 >> +--------------------+------------+-------------+---------+-----------+ >> >>=20 >| 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer| >> +--------------------+------------+-------------+---------+-----------+ >> >>=20 >\ / \ / >> ----------------------------- --------=20 >> ^---------------------------------------------/ | 802.11-to-Ethernet >> Adaptation Layer | v +---------------------+-------------+---------+=20 >> | Ethernet II Header | IPv6 Header | Payload |=20 >> +---------------------+-------------+---------+ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 12] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-13> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> The Receiver and Transmitter Address fields in the 802.11 Data >> Header contain the same values as the Destination and the Source >> Address fields in the Ethernet II Header, respectively. The value of >> the Type field in the LLC Header is the same as the value of the >> Type field in the Ethernet II Header. >>=20 >> The ".11 Trailer" contains solely a 4-byte Frame Check Sequence. >>=20 >> The Ethernet Adaptation Layer performs operations in relation to IP=20 >> fragmentation and MTU. One of these operations is briefly described=20 >> in sectionSection 5.1=20 >>=20 >>>ion-5.1>. >> >> In OCB mode, IPv6 packets can be transmitted either as "IEEE 802.11=20 >> Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in=20 >> the following figure: >>=20 >>=20 >> +--------------------+-------------+-------------+---------+-----------+ >> >>=20 >| 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer| >> +--------------------+-------------+-------------+---------+-----------+ >> >> or >>=20 >> +--------------------+-------------+-------------+---------+-----------+ >> >>=20 >| 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload |.11 Trailer| >> +--------------------+-------------+-------------+---------+-----------+ >> >>=20 >>=20 >> The distinction between the two formats is given by the value of the=20 >> field "Type/Subtype". The value of the field "Type/Subtype" in the=20 >> 802.11 Data header is 0x0020. The value of the field "Type/Subtype"=20 >> in the 802.11 QoS header is 0x0028. >>=20 >> The mapping between qos-related fields in the IPv6 header (e.g.=20 >> "Traffic Class", "Flow label") and fields in the "802.11 QoS Data=20 >> Header" (e.g. "QoS Control") are not specified in this document.=20 >> Guidance for a potential mapping is provided in=20 >> [I-D.ietf-tsvwg-ieee-802-11=20 >>=20 >>>I-D.ietf-tsvwg-ieee-802-11>], >> although it is not specific to OCB mode. >>=20 >>=20 >>=20 >> [Sri] The applicability of the QoS mapping draft to 802.11-OCB needs >> further investigation, IMO. >>=20 >>=20 >>=20 >>=20 >> 5.3=20 >>=20 >>>ion-5.3>. >> >>=20 >Link-Local Addresses >>=20 >>=20 >>=20 >> The link-local address of an 802.11-OCB interface is formed in the=20 >> same manner as on an Ethernet interface. This manner is described >> in section 5 of [RFC2464] >> . >>=20 >>=20 >>=20 >> [Sri] Does this go against the 8064 recommendation on Interface=20 >> identifier generation? >>=20 >> May be RFC7217 for interface identifier generation in conjunction >> with the link-local address generation per RFC2464 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 13] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-14> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> 5.4=20 >>=20 >>>ion-5.4>. >> >>=20 >Address Mapping >>=20 >>=20 >>=20 >> For unicast as for multicast, there is no change from the unicast >> and multicast address mapping format of Ethernet interfaces, as >> defined by sections6=20 >>=20 >>>ion-6> >> and7=20 >>=20 >>>ion-7> >> of [RFC2464 ]. >>=20 >>=20 >>=20 >> [Sri] RFC6085 specified mapping is also relevant; If the >> communication peers are aware that there is only one peer, it should >> apply 6085 specified mapping. That mode is relevant for 802.11-OCB >> types links as well. >>=20 >>=20 >>=20 >> 5.4.1=20 >>=20 >>>ion-5.4.1>. >> >>=20 >Address Mapping -- Unicast >>=20 >>=20 >>=20 >> The procedure for mapping IPv6 unicast addresses into Ethernet link-=20 >> layer addresses is described in [RFC4861 >> ]. The Source/Target Link-=20 >> layer Address option has the following form when the link-layer is=20 >> Ethernet. >>=20 >> [Sri] I thought, mapping of IPv6 unicast addresses to Ethernet=20 >> link-layer addresses is specified in section 6, of RFC2464 and not in >> RFC4861. >>=20 >>=20 >>=20 >>=20 >> 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |=20 >> +- Ethernet -+ | |=20 >> +- Address -+ | |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >> Option fields: >>=20 >> Type 1 for Source Link-layer address. 2 for Target Link-layer >> address. >>=20 >> Length 1 (in units of 8 octets). >>=20 >> Ethernet Address The 48 bit Ethernet IEEE 802 address, in canonical >> bit order. >>=20 >>=20 >> 5.4.2=20 >>=20 >>>ion-5.4.2>. >> >>=20 >Address Mapping -- Multicast >>=20 >>=20 >>=20 >> IPv6 protocols often make use of IPv6 multicast addresses in the=20 >> destination field of IPv6 headers. For example, an ICMPv6 link-=20 >> scoped Neighbor Advertisement is sent to the IPv6 address ff02::1=20 >> denoted "all-nodes" address. When transmitting these packets on=20 >> 802.11-OCB links it is necessary to map the IPv6 address to a MAC=20 >> address. >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 14] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-15> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> The same mapping requirement applies to the link-scoped multicast=20 >> addresses of other IPv6 protocols as well. In DHCPv6, the=20 >> "All_DHCP_Servers" IPv6 multicast address ff02::1:2, and in OSPF the=20 >> "All_SPF_Routers" IPv6 multicast address ff02::5, need to be mapped=20 >> on a multicast MAC address. >>=20 >> An IPv6 packet with a multicast destination address DST, consisting=20 >> of the sixteen octets DST[1] through DST[16], is transmitted to the=20 >> IEEE 802.11-OCB MAC multicast address whose first two octets are the=20 >> value 0x3333 and whose last four octets are the last four octets of=20 >> DST. >>=20 >> [Sri] Please add a reference to Section 7, RFC4861 and also RFC6085. >> In general, for both unicast and multicast, you may want to clearly >> say that this is per the existing specs and duplicated here for >> convenience. >>=20 >>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1|=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DST[13] | DST[14] |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DST[15] | DST[16] |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >> A Group ID TBD of length 112bits may be requested from IANA; this=20 >> Group ID signifies "All 80211OCB Interfaces Address". Only the >> least 32 significant bits of this "All 80211OCB Interfaces Address" >> will be mapped to and from a MAC multicast address. >>=20 >> Transmitting IPv6 packets to multicast destinations over 802.11 >> links proved to have some performance issues=20 >> [I-D.perkins-intarea-multicast-ieee802=20 >>=20 >>>I-D.perkins-intarea-multicast-ieee802>]. >> These issues may be exacerbated in OCB mode. Solutions for these >> problems should consider the OCB mode of operation. >>=20 >>=20 >> 5.5=20 >>=20 >>>ion-5.5>. >> >>=20 >Stateless Autoconfiguration >>=20 >>=20 >>=20 >> The Interface Identifier for an 802.11-OCB interface is formed using=20 >> the same rules as the Interface Identifier for an Ethernet >> interface; this is described insection 4 of [RFC2464] >> . No changes are >> needed, but some care must be taken when considering the use of the >> SLAAC procedure. >>=20 >>=20 >>=20 >> [Sri] Per my earlier comment, please refer to the current >> recommendation on interface-identifier generation and its use in >> link-local, global or other addresses. >>=20 >> The bits in the the interface identifier have no generic meaning and >> the identifier should be treated as an opaque value. The bits >> 'Universal' and 'Group' in the identifier of an 802.11-OCB interface >> are significant, as this is an IEEE link-layer address. The details >> of this significance are described in [I-D.ietf-6man-ug=20 >>=20 >>>I-D.ietf-6man-ug>]. >> Petrescu, et al. Expires February 18, 2018 [Page 15] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-16> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> As with all Ethernet and 802.11 interface identifiers ([RFC7721 >> ]), the identifier of an >> 802.11-OCB interface may involve privacy risks. A vehicle embarking >> an On-Board Unit whose egress interface is 802.11-OCB may expose >> itself to eavesdropping and subsequent correlation of data; this may >> reveal data considered private by the vehicle owner; there is a risk >> of being tracked; see the privacy considerations described inAppendix >> C=20 >>=20 >>>ndix-C>. >> >>=20 >>=20 >> [Sri] I think there are other security issues here; the absence of=20 >> link-layer security opens up Mac-spoofing and IP address hijacking. >> That should be mentioned. >>=20 >>=20 >>=20 >> If stable Interface Identifiers are needed in order to form IPv6=20 >> addresses on 802.11-OCB links, it is recommended to follow the=20 >> recommendation in [I-D.ietf-6man-default-iids=20 >>=20 >>>I-D.ietf-6man-default-iids>]. >> >>=20 >>=20 >> 5.6=20 >>=20 >>>ion-5.6>. >> >>=20 >Subnet Structure >>=20 >>=20 >>=20 >> The 802.11 networks in OCB mode may be considered as 'ad-hoc'=20 >> networks. The addressing model for such networks is described in=20 >> [RFC5889 ]. >>=20 >>=20 >> [Sri] Per my earlier comment, there is no system level view of the=20 >> network where 802.11-OCB links are used. So, in the absence of such=20 >> discussion So, I am not sure what part of RFC5889 is applicable here. >> For example, link-local addresses may just work fine. >>=20 >>=20 >>=20 >> 6=20 >>=20 >>>ion-6>. >> >>=20 >Example IPv6 Packet captured over a IEEE 802.11-OCB link >>=20 >>=20 >>=20 >> We remind that a main goal of this document is to make the case that=20 >> IPv6 works fine over 802.11-OCB networks. Consequently, this >> section is an illustration of this concept and thus can help the >> implementer when it comes to running IPv6 over IEEE 802.11-OCB. By >> way of example we show that there is no modification in the headers >> when transmitted over 802.11-OCB networks - they are transmitted like >> any other 802.11 and Ethernet packets. >>=20 >> We describe an experiment of capturing an IPv6 packet on an=20 >> 802.11-OCB link. In this experiment, the packet is an IPv6 Router=20 >> Advertisement. This packet is emitted by a Router on its 802.11-OCB=20 >> interface. The packet is captured on the Host, using a network=20 >> protocol analyzer (e.g. Wireshark); the capture is performed in two=20 >> different modes: direct mode and 'monitor' mode. The topology used=20 >> during the capture is depicted below. >>=20 >>=20 >> +--------+ +-------+ | | >> 802.11-OCB Link | | ---| Router >> |--------------------------------| Host | | | >> | | +--------+ +-------+ >>=20 >>=20 >> During several capture operations running from a few moments to=20 >> several hours, no message relevant to the BSSID contexts were=20 >> captured (no Association Request/Response, Authentication Req/Resp, >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 16] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-17> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> Beacon). This shows that the operation of 802.11-OCB is outside the=20 >> context of a BSSID. >>=20 >> Overall, the captured message is identical with a capture of an IPv6=20 >> packet emitted on a 802.11b interface. The contents are precisely=20 >> similar. >>=20 >>=20 >> [Sri] I suggest moving this discussion under the section >> =B3Implementation Status=B2, which will eventually be removed from the >> RFC. There is nothing new here. This are details on experimentation. >> But, if you think there is some useful information such as discussion >> on Capture mode ..etc, you may want to move this entire section to >> Appendix. Implementors may use these tools for verification. >>=20 >>=20 >>=20 >>=20 >> 6.1=20 >>=20 >>>ion-6.1>. >> >>=20 >Capture in Monitor Mode >>=20 >>=20 >>=20 >> The IPv6 RA packet captured in monitor mode is illustrated below. The >> radio tap header provides more flexibility for reporting the=20 >> characteristics of frames. The Radiotap Header is prepended by this=20 >> particular stack and operating system on the Host machine to the RA=20 >> packet received from the network (the Radiotap Header is not present=20 >> on the air). The implementation-dependent Radiotap Header is useful=20 >> for piggybacking PHY information from the chip's registers as data >> in a packet understandable by userland applications using Socket=20 >> interfaces (the PHY interface can be, for example: power levels, >> data rate, ratio of signal to noise). >>=20 >> The packet present on the air is formed by IEEE 802.11 Data Header,=20 >> Logical Link Control Header, IPv6 Base Header and ICMPv6 Header. >>=20 >>=20 >>=20 >> Radiotap Header v0=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 >> |Header Revision| Header Pad | Header length |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Present flags |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Data Rate | Pad |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> IEEE 802.11 Data Header=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Type/Subtype and Frame Ctrl | Duration |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Receiver Address...=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... >> Receiver Address | Transmitter Address...=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... >> Transmitter Address |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> BSS Id...=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... >> BSS Id | Frag Number and Seq Number |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 17] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-18> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> Logical-Link Control Header=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> DSAP |I| SSAP |C| Control field | Org. code...=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... >> Organizational Code | Type |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> IPv6 Base Header=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 >> |Version| Traffic Class | Flow Label |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Payload Length | Next Header | Hop Limit |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> | + + | >> | + Source Address + | >> | + + | >> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> | + + | >> | + Destination Address + | >> | + + | >> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Router Advertisement=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Type | Code | Checksum |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Cur Hop Limit |M|O| Reserved | Router Lifetime |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Reachable Time |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Retrans Timer |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Options ... +-+-+-+-+-+-+-+-+-+-+-+- >>=20 >>=20 >> The value of the Data Rate field in the Radiotap header is set to 6=20 >> Mb/s. This indicates the rate at which this RA was received. >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 18] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-19> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> The value of the Transmitter address in the IEEE 802.11 Data Header=20 >> is set to a 48bit value. The value of the destination address is=20 >> 33:33:00:00:00:1 (all-nodes multicast address). The value of the >> BSS Id field is ff:ff:ff:ff:ff:ff, which is recognized by the >> network protocol analyzer as being "broadcast". The Fragment number >> and sequence number fields are together set to 0x90C6. >>=20 >> The value of the Organization Code field in the Logical-Link Control=20 >> Header is set to 0x0, recognized as "Encapsulated Ethernet". The=20 >> value of the Type field is 0x86DD (hexadecimal 86DD, or otherwise=20 >> #86DD), recognized as "IPv6". >>=20 >> A Router Advertisement is periodically sent by the router to=20 >> multicast group address ff02::1. It is an icmp packet type 134. >> The IPv6 Neighbor Discovery's Router Advertisement message contains >> an 8-bit field reserved for single-bit flags, as described in >> [RFC4861 ]. >>=20 >> The IPv6 header contains the link local address of the router=20 >> (source) configured via EUI-64 algorithm, and destination address >> set to ff02::1. Recent versions of network protocol analyzers (e.g.=20 >> Wireshark) provide additional informations for an IP address, if a=20 >> geolocalization database is present. In this example, the=20 >> geolocalization database is absent, and the "GeoIP" information is=20 >> set to unknown for both source and destination addresses (although=20 >> the IPv6 source and destination addresses are set to useful values).=20 >> This "GeoIP" can be a useful information to look up the city,=20 >> country, AS number, and other information for an IP address. >>=20 >>=20 >> [Sri] Not sure, why all of this text should be in the specification. >>=20 >>=20 >> The Ethernet Type field in the logical-link control header is set to=20 >> 0x86dd which indicates that the frame transports an IPv6 packet. In=20 >> the IEEE 802.11 data, the destination address is 33:33:00:00:00:01=20 >> which is he corresponding multicast MAC address. The BSS id is a=20 >> broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link=20 >> duration between vehicles and the roadside infrastructure, there is=20 >> no need in IEEE 802.11-OCB to wait for the completion of association=20 >> and authentication procedures before exchanging data. IEEE=20 >> 802.11-OCB enabled nodes use the wildcard BSSID (a value of all 1s)=20 >> and may start communicating as soon as they arrive on the=20 >> communication channel. >>=20 >>=20 >> 6.2=20 >>=20 >>>ion-6.2>. >> >>=20 >Capture in Normal Mode >>=20 >>=20 >>=20 >> The same IPv6 Router Advertisement packet described above (monitor=20 >> mode) is captured on the Host, in the Normal mode, and depicted=20 >> below. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 19] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-20> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> Ethernet II Header=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Destination...=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 >> ...Destination | Source...=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 >> ...Source |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> IPv6 Base Header=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 >> |Version| Traffic Class | Flow Label |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Payload Length | Next Header | Hop Limit |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> | + + | >> | + Source Address + | >> | + + | >> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> | + + | >> | + Destination Address + | >> | + + | >> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Router Advertisement=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Type | Code | Checksum |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Cur Hop Limit |M|O| Reserved | Router Lifetime |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Reachable Time |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Retrans Timer |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> Options ... +-+-+-+-+-+-+-+-+-+-+-+- >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 20] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-21> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> One notices that the Radiotap Header is not prepended, and that the=20 >> IEEE 802.11 Data Header and the Logical-Link Control Headers are not=20 >> present. On another hand, a new header named Ethernet II Header is=20 >> present. >>=20 >> The Destination and Source addresses in the Ethernet II header=20 >> contain the same values as the fields Receiver Address and=20 >> Transmitter Address present in the IEEE 802.11 Data Header in the=20 >> "monitor" mode capture. >>=20 >> The value of the Type field in the Ethernet II header is 0x86DD=20 >> (recognized as "IPv6"); this value is the same value as the value of=20 >> the field Type in the Logical-Link Control Header in the "monitor"=20 >> mode capture. >>=20 >> The knowledgeable experimenter will no doubt notice the similarity >> of this Ethernet II Header with a capture in normal mode on a pure=20 >> Ethernet cable interface. >>=20 >> It may be interpreted that an Adaptation layer is inserted in a pure=20 >> IEEE 802.11 MAC packets in the air, before delivering to the=20 >> applications. In detail, this adaptation layer may consist in=20 >> elimination of the Radiotap, 802.11 and LLC headers and insertion of=20 >> the Ethernet II header. In this way, it can be stated that IPv6 >> runs naturally straight over LLC over the 802.11-OCB MAC layer, as >> shown by the use of the Type 0x86DD, and assuming an adaptation >> layer (adapting 802.11 LLC/MAC to Ethernet II header). >>=20 >>=20 >> 7=20 >>=20 >>>ion-7>. >> >>=20 >Security Considerations >>=20 >>=20 >>=20 >> Any security mechanism at the IP layer or above that may be carried=20 >> out for the general case of IPv6 may also be carried out for IPv6=20 >> operating over 802.11-OCB. >>=20 >>=20 >> 802.11-OCB does not provide any cryptographic protection, because it=20 >> operates outside the context of a BSS (no Association Request/=20 >> Response, no Challenge messages). Any attacker can therefore just=20 >> sit in the near range of vehicles, sniff the network (just set the=20 >> interface card's frequency to the proper range) and perform attacks=20 >> without needing to physically break any wall. Such a link is way=20 >> less protected than commonly used links (wired link or protected=20 >> 802.11). >>=20 >> [Sri] Per my earlier comment, there is more than one attack vector >> possible >>=20 >> 1.) Absence of link-layer security and the potential for mac address >> spoofing >>=20 >> 2.) IP address / Session hijacking >>=20 >> 3.) Data privacy per your text >>=20 >>=20 >>=20 >> At the IP layer, IPsec can be used to protect unicast >> communications, and SeND can be used for multicast communications. >>=20 >>=20 >> [Sri] IPSec can be used for protecting both multicast or unicast=20 >> communication; RFC-5374 with GDOI. >>=20 >>=20 >>=20 >>=20 >> If no protection is used by the IP layer, upper layers should be >> protected. Otherwise, the end-user or system should be warned about >> the risks they run. >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 21] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-22> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> As with all Ethernet and 802.11 interface identifiers, there may=20 >> exist privacy risks in the use of 802.11-OCB interface identifiers.=20 >> Moreover, in outdoors vehicular settings, the privacy risks are more=20 >> important than in indoors settings. New risks are induced by the=20 >> possibility of attacker sniffers deployed along routes which listen=20 >> for IP packets of vehicles passing by. For this reason, in the=20 >> 802.11-OCB deployments, there is a strong necessity to use >> protection tools such as dynamically changing MAC addresses. This >> may help mitigate privacy risks to a certain level. On another hand, >> it may have an impact in the way typical IPv6 address >> auto-configuration is performed for vehicles (SLAAC would rely on MAC >> addresses amd would hence dynamically change the affected IP >> address), in the way the IPv6 Privacy addresses were used, and other >> effects. >>=20 >>=20 >> 8=20 >>=20 >>>ion-8>. >> >>=20 >IANA Considerations >>=20 >>=20 >>=20 >> 9=20 >>=20 >>>ion-9>. >> >>=20 >Contributors >>=20 >>=20 >>=20 >> Romain Kuntz contributed extensively about IPv6 handovers between=20 >> links running outside the context of a BSS (802.11-OCB links). >>=20 >> Tim Leinmueller contributed the idea of the use of IPv6 over=20 >> 802.11-OCB for distribution of certificates. >>=20 >> Marios Makassikis, Jose Santa Lozano, Albin Severinson and Alexey=20 >> Voronov provided significant feedback on the experience of using IP=20 >> messages over 802.11-OCB in initial trials. >>=20 >> Michelle Wetterwald contributed extensively the MTU discussion,=20 >> offered the ETSI ITS perspective, and reviewed other parts of the=20 >> document. >>=20 >>=20 >> 10=20 >>=20 >>>ion-10>. >> >>=20 >Acknowledgements >>=20 >>=20 >>=20 >> The authors would like to thank Witold Klaudel, Ryuji Wakikawa,=20 >> Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan=20 >> Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray=20 >> Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan,=20 >> Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne,=20 >> Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark,=20 >> Bob Moskowitz, Andrew (Dryden?), Georg Mayer, Dorothy Stanley and=20 >> William Whyte. Their valuable comments clarified certain issues and=20 >> generally helped to improve the document. >>=20 >> Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB=20 >> drivers for linux and described how. >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 22] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-23> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> For the multicast discussion, the authors would like to thank Owen=20 >> DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and=20 >> participants to discussions in network working groups. >>=20 >> The authours would like to thank participants to the Birds-of-=20 >> a-Feather "Intelligent Transportation Systems" meetings held at IETF=20 >> in 2016. >>=20 >>=20 >> 11=20 >>=20 >>>ion-11>. >> >>=20 >References >>=20 >>=20 >>=20 >> 11.1=20 >>=20 >>>ion-11.1>. >> >>=20 >Normative References >>=20 >>=20 >>=20 >> [I-D.ietf-6man-default-iids] Gont, F., Cooper, A., Thaler, D., and S. >> LIU, "Recommendation on Stable IPv6 Interface Identifiers",=20 >> draft-ietf-6man-default-iids-16=20 >> (work >> in progress), September 2016. >>=20 >> [I-D.ietf-6man-ug] Carpenter, B. and S. Jiang, "Significance of IPv6=20 >> Interface Identifiers",draft-ietf-6man-ug-06 >> (work in=20 >> progress), December 2013. >>=20 >> [I-D.ietf-tsvwg-ieee-802-11] Szigeti, T., Henry, J., and F. Baker, >> "Diffserv to IEEE 802.11 Mapping",draft-ietf-tsvwg-ieee-802-11-06=20 >> (work >> in progress), August 2017. >>=20 >> [RFC1042] Postel, J. and J. Reynolds, "Standard for the >> transmission of IP datagrams over IEEE 802 networks", STD 43,RFC 1042 >> , DOI 10.17487/RFC1042, February >> 1988, =20 >> editor.org/info/rfc1042 >. >>=20 >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=20 >> Requirement Levels",BCP 14 ,RFC >> 2119 , DOI 10.17487/RFC2119, >> March 1997, > editor.org/info/rfc2119 >> >. >>=20 >> [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6=20 >> (IPv6) Specification",RFC 2460 , >> DOI 10.17487/RFC2460, December 1998, >> . >>=20 >> [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet=20 >> Networks",RFC 2464 , DOI >> 10.17487/RFC2464, December 1998,=20 >> . >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 23] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-24> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.=20 >> Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963 >> , DOI 10.17487/RFC3963, January >> 2005, . >>=20 >> [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,=20 >> "Randomness Requirements for Security",BCP 106 >> ,RFC 4086 >> , DOI 10.17487/RFC4086, June >> 2005, =20 >> editor.org/info/rfc4086 >. >>=20 >> [RFC4301] Kent, S. and K. Seo, "Security Architecture for the=20 >> Internet Protocol",RFC 4301 , >> DOI 10.17487/RFC4301, December 2005, >> . >>=20 >> [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)=20 >> for IPv6",RFC 4429 , DOI >> 10.17487/RFC4429, April 2006,=20 >> . >>=20 >> [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,=20 >> "Neighbor Discovery for IP version 6 (IPv6)",RFC 4861 >> , DOI 10.17487/RFC4861, >> September 2007, > editor.org/info/rfc4861 >> >. >>=20 >> [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing=20 >> Model in Ad Hoc Networks",RFC 5889 >> , DOI 10.17487/RFC5889,=20 >> September 2010, . >>=20 >> [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility=20 >> Support in IPv6",RFC 6275 , DOI >> 10.17487/RFC6275, July 2011, >> . >>=20 >> [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.=20 >> Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power >> Wireless Personal Area Networks (6LoWPANs)", RFC 6775 >> , DOI 10.17487/RFC6775, November >> 2012, . >>=20 >> [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and >> Privacy Considerations for IPv6 Address Generation Mechanisms", RFC >> 7721 , DOI 10.17487/RFC7721, >> March 2016, . >>=20 >>=20 >> 11.2=20 >>=20 >>>ion-11.2>. >> >>=20 >Informative References >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 24] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-25> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> [fcc-cc] "'Report and Order, Before the Federal Communications=20 >> Commission Washington, D.C. 20554', FCC 03-324, Released on February >> 10, 2004, document FCC-03-324A1.pdf, document freely available at >> URL http://www.its.dot.gov/exit/fcc_edocs.htm downloaded on October >> 17th, 2013.". >>=20 >> [fcc-cc-172-184] "'Memorandum Opinion and Order, Before the Federal=20 >> Communications Commission Washington, D.C. 20554', FCC 06-10, >> Released on July 26, 2006, document FCC- 06-110A1.pdf, document >> freely available at URL=20 >> http://hraunfoss.fcc.gov/edocs_public/attachmatch/=20 >> =20 >> FCC-06-110A1.pdf=20 >> >> downloaded on June 5th, 2014.". >>=20 >> [I-D.jeong-ipwave-vehicular-networking-survey] Jeong, J., Cespedes, >> S., Benamar, N., Haerri, J., and M. Wetterwald, "Survey on IP-based >> Vehicular Networking for Intelligent Transportation >> Systems",draft-jeong-ipwave-=20 >>=20 >>>ey-03> >> >>=20 >vehicular-networking-survey-03 >>=20 >>>ey-03> >> (work in progress), June 2017. >>=20 >> [I-D.perkins-intarea-multicast-ieee802] Perkins, C., Stanley, D., >> Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 >> Wireless Media", draft-perkins-intarea-multicast-ieee802-03=20 >> >> (work in progress), July 2017. >>=20 >> [I-D.petrescu-its-scenarios-reqs] Petrescu, A., Janneteau, C., Boc, >> M., and W. Klaudel, "Scenarios and Requirements for IP in >> Intelligent Transportation Systems",draft-petrescu-its-scenarios-=20 >> =20 >> reqs-03 >> >> (work in progress), October 2013. >>=20 >> [ieee1609.2] "IEEE SA - 1609.2-2016 - IEEE Standard for Wireless >> Access in Vehicular Environments (WAVE) -- Security Services for=20 >> Applications and Management Messages. Example URL=20 >> http://ieeexplore.ieee.org/document/7426684/ accessed on August >> 17th, 2017.". >>=20 >> [ieee1609.3] "IEEE SA - 1609.3-2016 - IEEE Standard for Wireless >> Access in Vehicular Environments (WAVE) -- Networking Services.=20 >> Example URLhttp://ieeexplore.ieee.org/document/7458115/=20 >> accessed >> on August >> 17th, 2017.". >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 25] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-26> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> [ieee1609.4] "IEEE SA - 1609.4-2016 - IEEE Standard for Wireless >> Access in Vehicular Environments (WAVE) -- Multi-Channel Operation. >> Example URL http://ieeexplore.ieee.org/document/7435228/ accessed >> on August 17th, 2017.". >>=20 >> [ieee802.11-2012] "802.11-2012 - IEEE Standard for Information >> technology-- Telecommunications and information exchange between=20 >> systems Local and metropolitan area networks--Specific requirements >> Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer >> (PHY) Specifications. Downloaded on October 17th, 2013, from IEEE >> Standards, document freely available at URL=20 >> http://standards.ieee.org/findstds/=20 >> =20 >> standard/802.11-2012.html=20 >> >> retrieved on October 17th, 2013.". >>=20 >> [ieee802.11p-2010] "IEEE Std 802.11p (TM)-2010, IEEE Standard for >> Information Technology - Telecommunications and information exchange=20 >> between systems - Local and metropolitan area networks - Specific >> requirements, Part 11: Wireless LAN Medium Access Control (MAC) and >> Physical Layer (PHY) Specifications, Amendment 6: Wireless Access in >> Vehicular Environments; document freely available at URL=20 >> http://standards.ieee.org/getieee802/=20 >> =20 >> download/802.11p-2010.pdf=20 >> >> retrieved on September 20th, 2013.". >>=20 >>=20 >> Appendix A=20 >>=20 >>>ndix-A>. >> >>=20 >ChangeLog >>=20 >>=20 >>=20 >> The changes are listed in reverse chronological order, most recent=20 >> changes appearing at the top of the list. >>=20 >> Fromdraft-ietf-ipwave-ipv6-over-80211ocb-03=20 >> >> todraft-ietf-ipwave-=20 >> >> >>=20 >ipv6-over-80211ocb-04 >> >> >> o Removed a few informative references pointing to Dx draft IEEE=20 >> 1609 documents. >>=20 >> o Removed outdated informative references to ETSI documents. >>=20 >> o Added citations to IEEE 1609.2, .3 and .4-2016. >>=20 >> o Minor textual issues. >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 26] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-27> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> Fromdraft-ietf-ipwave-ipv6-over-80211ocb-02=20 >> >> todraft-ietf-ipwave-=20 >> >> >>=20 >ipv6-over-80211ocb-03 >> >> >> o Keep the previous text on multiple addresses, so remove talk >> about MIP6, NEMOv6 and MCoA. >>=20 >> o Clarified that a 'Beacon' is an IEEE 802.11 frame Beacon. >>=20 >> o Clarified the figure showing Infrastructure mode and OCB mode >> side by side. >>=20 >> o Added a reference to the IP Security Architecture RFC. >>=20 >> o Detailed the IPv6-per-channel prohibition paragraph which >> reflects the discussion at the last IETF IPWAVE WG meeting. >>=20 >> o Added section "Address Mapping -- Unicast". >>=20 >> o Added the ".11 Trailer" to pictures of 802.11 frames. >>=20 >> o Added text about SNAP carrying the Ethertype. >>=20 >> o New RSU definition allowing for it be both a Router and not=20 >> necessarily a Router some times. >>=20 >> o Minor textual issues. >>=20 >> Fromdraft-ietf-ipwave-ipv6-over-80211ocb-01=20 >> >> todraft-ietf-ipwave-=20 >> >> >>=20 >ipv6-over-80211ocb-02 >> >> >> o Replaced almost all occurences of 802.11p with 802.11-OCB, >> leaving only when explanation of evolution was necessary. >>=20 >> o Shortened by removing parameter details from a paragraph in the=20 >> Introduction. >>=20 >> o Moved a reference from Normative to Informative. >>=20 >> o Added text in intro clarifying there is no handover spec at IEEE,=20 >> and that 1609.2 does provide security services. >>=20 >> o Named the contents the fields of the EthernetII header (including=20 >> the Ethertype bitstring). >>=20 >> o Improved relationship between two paragraphs describing the=20 >> increase of the Sequence Number in 802.11 header upon IP=20 >> fragmentation. >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 27] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-28> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> o Added brief clarification of "tracking". >>=20 >> Fromdraft-ietf-ipwave-ipv6-over-80211ocb-00=20 >> >> todraft-ietf-ipwave-=20 >> >> >>=20 >ipv6-over-80211ocb-01 >> >> >> o Introduced message exchange diagram illustrating differences=20 >> between 802.11 and 802.11 in OCB mode. >>=20 >> o Introduced an appendix listing for information the set of 802.11=20 >> messages that may be transmitted in OCB mode. >>=20 >> o Removed appendix sections "Privacy Requirements", "Authentication=20 >> Requirements" and "Security Certificate Generation". >>=20 >> o Removed appendix section "Non IP Communications". >>=20 >> o Introductory phrase in the Security Considerations section. >>=20 >> o Improved the definition of "OCB". >>=20 >> o Introduced theoretical stacked layers about IPv6 and IEEE layers=20 >> including EPD. >>=20 >> o Removed the appendix describing the details of prohibiting IPv6 >> on certain channels relevant to 802.11-OCB. >>=20 >> o Added a brief reference in the privacy text about a precise >> clause in IEEE 1609.3 and .4. >>=20 >> o Clarified the definition of a Road Side Unit. >>=20 >> o Removed the discussion about security of WSA (because is non-IP). >>=20 >> o Removed mentioning of the GeoNetworking discussion. >>=20 >> o Moved references to scientific articles to a separate 'overview'=20 >> draft, and referred to it. >>=20 >>=20 >> Appendix B=20 >>=20 >>>ndix-B>. >> >>=20 >Changes Needed on a software driver 802.11a to become a >>=20 >>=20 >> 802.11-OCB driver >>=20 >> The 802.11p amendment modifies both the 802.11 stack's physical and=20 >> MAC layers but all the induced modifications can be quite easily=20 >> obtained by modifying an existing 802.11a ad-hoc stack. >>=20 >> Conditions for a 802.11a hardware to be 802.11-OCB compliant: >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 28] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-29> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> o The chip must support the frequency bands on which the regulator=20 >> recommends the use of ITS communications, for example using IEEE=20 >> 802.11-OCB layer, in France: 5875MHz to 5925MHz. >>=20 >> o The chip must support the half-rate mode (the internal clock=20 >> should be able to be divided by two). >>=20 >> o The chip transmit spectrum mask must be compliant to the >> "Transmit spectrum mask" from the IEEE 802.11p amendment (but >> experimental environments tolerate otherwise). >>=20 >> o The chip should be able to transmit up to 44.8 dBm when used by=20 >> the US government in the United States, and up to 33 dBm in Europe; >> other regional conditions apply. >>=20 >> Changes needed on the network stack in OCB mode: >>=20 >> o Physical layer: >>=20 >> * The chip must use the Orthogonal Frequency Multiple Access (OFDM) >> encoding mode. >>=20 >> * The chip must be set in half-mode rate mode (the internal clock=20 >> frequency is divided by two). >>=20 >> * The chip must use dedicated channels and should allow the use of >> higher emission powers. This may require modifications to the >> regulatory domains rules, if used by the kernel to enforce local >> specific restrictions. Such modifications must respect the >> location-specific laws. >>=20 >> MAC layer: >>=20 >> * All management frames (beacons, join, leave, and others) emission >> and reception must be disabled except for frames of subtype Action >> and Timing Advertisement (defined below). >>=20 >> * No encryption key or method must be used. >>=20 >> * Packet emission and reception must be performed as in ad-hoc mode, >> using the wildcard BSSID (ff:ff:ff:ff:ff:ff). >>=20 >> * The functions related to joining a BSS (Association Request/=20 >> Response) and for authentication (Authentication Request/Reply,=20 >> Challenge) are not called. >>=20 >> * The beacon interval is always set to 0 (zero). >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 29] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-30> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> * Timing Advertisement frames, defined in the amendment, should be >> supported. The upper layer should be able to trigger such frames >> emission and to retrieve information contained in received Timing >> Advertisements. >>=20 >>=20 >> Appendix C=20 >>=20 >>>ndix-C>. >> >>=20 >Design Considerations >>=20 >>=20 >>=20 >> The networks defined by 802.11-OCB are in many ways similar to other=20 >> networks of the 802.11 family. In theory, the encapsulation of IPv6=20 >> over 802.11-OCB could be very similar to the operation of IPv6 over=20 >> other networks of the 802.11 family. However, the high mobility,=20 >> strong link asymetry and very short connection makes the 802.11-OCB=20 >> link significantly different from other 802.11 networks. Also, the=20 >> automotive applications have specific requirements for reliability,=20 >> security and privacy, which further add to the particularity of the=20 >> 802.11-OCB link. >>=20 >>=20 >> C.1=20 >>=20 >>>ndix-C.1>. >> >>=20 >Vehicle ID >>=20 >>=20 >>=20 >> Automotive networks require the unique representation of each of=20 >> their node. Accordingly, a vehicle must be identified by at least=20 >> one unique identifier. The current specification at ETSI and at >> IEEE 1609 identifies a vehicle by its MAC address uniquely obtained >> from the 802.11-OCB NIC. >>=20 >> A MAC address uniquely obtained from a IEEE 802.11-OCB NIC=20 >> implicitely generates multiple vehicle IDs in case of multiple=20 >> 802.11-OCB NICs. A mechanims to uniquely identify a vehicle=20 >> irrespectively to the different NICs and/or technologies is >> required. >>=20 >>=20 >> C.2=20 >>=20 >>>ndix-C.2>. >> >>=20 >Reliability Requirements >>=20 >>=20 >>=20 >> The dynamically changing topology, short connectivity, mobile=20 >> transmitter and receivers, different antenna heights, and many-to-=20 >> many communication types, make IEEE 802.11-OCB links significantly=20 >> different from other IEEE 802.11 links. Any IPv6 mechanism >> operating on IEEE 802.11-OCB link MUST support strong link asymetry, >> spatio- temporal link quality, fast address resolution and >> transmission. >>=20 >> IEEE 802.11-OCB strongly differs from other 802.11 systems to >> operate outside of the context of a Basic Service Set. This means >> in practice that IEEE 802.11-OCB does not rely on a Base Station for >> all Basic Service Set management. In particular, IEEE 802.11-OCB >> SHALL NOT use beacons. Any IPv6 mechanism requiring L2 services from >> IEEE 802.11 beacons MUST support an alternative service. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 30] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-31> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> Channel scanning being disabled, IPv6 over IEEE 802.11-OCB MUST=20 >> implement a mechanism for transmitter and receiver to converge to a=20 >> common channel. >>=20 >> Authentication not being possible, IPv6 over IEEE 802.11-OCB MUST=20 >> implement an distributed mechanism to authenticate transmitters and=20 >> receivers without the support of a DHCP server. >>=20 >> Time synchronization not being available, IPv6 over IEEE 802.11-OCB=20 >> MUST implement a higher layer mechanism for time synchronization=20 >> between transmitters and receivers without the support of a NTP=20 >> server. >>=20 >> The IEEE 802.11-OCB link being asymetic, IPv6 over IEEE 802.11-OCB=20 >> MUST disable management mechanisms requesting acknowledgements or=20 >> replies. >>=20 >> The IEEE 802.11-OCB link having a short duration time, IPv6 over >> IEEE 802.11-OCB MUST implement fast IPv6 mobility management >> mechanisms. >>=20 >>=20 >> C.3=20 >>=20 >>>ndix-C.3>. >> >>=20 >Multiple interfaces >>=20 >>=20 >>=20 >> There are considerations for 2 or more IEEE 802.11-OCB interface=20 >> cards per vehicle. For each vehicle taking part in road traffic, >> one IEEE 802.11-OCB interface card could be fully allocated for Non >> IP safety-critical communication. Any other IEEE 802.11-OCB may be >> used for other type of traffic. >>=20 >> The mode of operation of these other wireless interfaces is not=20 >> clearly defined yet. One possibility is to consider each card as an=20 >> independent network interface, with a specific MAC Address and a set=20 >> of IPv6 addresses. Another possibility is to consider the set of=20 >> these wireless interfaces as a single network interface (not=20 >> including the IEEE 802.11-OCB interface used by Non IP safety=20 >> critical communications). This will require specific logic to=20 >> ensure, for example, that packets meant for a vehicle in front are=20 >> actually sent by the radio in the front, or that multiple copies of=20 >> the same packet received by multiple interfaces are treated as a=20 >> single packet. Treating each wireless interface as a separate=20 >> network interface pushes such issues to the application layer. >>=20 >> The privacy requirements of [] imply that if these multiple=20 >> interfaces are represented by many network interface, a single=20 >> renumbering event SHALL cause renumbering of all these interfaces. If >> one MAC changed and another stayed constant, external observers would >> be able to correlate old and new values, and the privacy benefits of >> randomization would be lost. >>=20 >>=20 >>=20 >>=20 >> Petrescu, et al. Expires February 18, 2018 [Page 31] >>=20 >> ------------------------------------------------------------------------ >> >> =20 >>=20 >>>-32> >> >>=20 >Internet-Draft IPv6-over-80211ocb August 2017 >>=20 >>=20 >> The privacy requirements of Non IP safety-critical communications=20 >> imply that if a change of pseudonyme occurs, renumbering of all >> other interfaces SHALL also occur. >>=20 >>=20 >> C.4=20 >>=20 >>>ndix-C.4>. >> >>=20 >MAC Address Generation >>=20 >>=20 >>=20 >> When designing the IPv6 over 802.11-OCB address mapping, we will=20 >> assume that the MAC Addresses will change during well defined=20 >> "renumbering events". The 48 bits randomized MAC addresses will >> have the following characteristics: >>=20 >> o Bit "Local/Global" set to "locally admninistered". >>=20 >> o Bit "Unicast/Multicast" set to "Unicast". >>=20 >> o 46 remaining bits set to a random value, using a random number=20 >> generator that meets the requirements of [RFC4086 >> ]. >>=20 >> The way to meet the randomization requirements is to retain 46 bits=20 >> from the output of a strong hash function, such as SHA256, taking as=20 >> input a 256 bit local secret, the "nominal" MAC Address of the=20 >> interface, and a representation of the date and time of the=20 >> renumbering event. >>=20 >>=20 >> Appendix D=20 >>=20 >>>ndix-D>. >> >>=20 >IEEE 802.11 Messages Transmitted in OCB mode >>=20 >>=20 >>=20 >> For information, at the time of writing, this is the list of IEEE=20 >> 802.11 messages that may be transmitted in OCB mode, i.e. when=20 >> dot11OCBActivated is true in a STA: >>=20 >> o The STA may send management frames of subtype Action and, if the=20 >> STA maintains a TSF Timer, subtype Timing Advertisement; >>=20 >> o The STA may send control frames, except those of subtype PS-Poll,=20 >> CF-End, and CF-End plus CFAck; >>=20 >> o The STA may send data frames of subtype Data, Null, QoS Data, and=20 >> QoS Null. >>=20 >> Authors' Addresses >>=20 >>=20 >>=20 >> _______________________________________________ its mailing list=20 >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>=20 From nobody Thu Sep 7 08:20:49 2017 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 4CBC4132F93 for ; Thu, 7 Sep 2017 08:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Q_5kjve-9QCK for ; Thu, 7 Sep 2017 08:20:38 -0700 (PDT) Received: from xenon41.um.es (xenon41.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6D9132F91 for ; Thu, 7 Sep 2017 08:20:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id 41BFC20BFB for ; Thu, 7 Sep 2017 17:20:31 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon41.um.es Received: from xenon41.um.es ([127.0.0.1]) by localhost (xenon41.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AM_xeDsJXKcw for ; Thu, 7 Sep 2017 17:20:30 +0200 (CEST) Received: from inf-205-241.inf.um.es (inf-205-241.inf.um.es [155.54.205.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: josesanta) by xenon41.um.es (Postfix) with ESMTPSA id 8C3CD20B44 for ; Thu, 7 Sep 2017 17:20:29 +0200 (CEST) From: =?utf-8?Q?Jos=C3=A9_Santa_Lozano?= Content-Type: multipart/alternative; boundary="Apple-Mail=_FF92C8B0-0AAA-404A-8F2A-6BBDA9915154" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <58D01021-E27E-44AC-BCDD-31800CDE38E4@um.es> Date: Thu, 7 Sep 2017 17:20:29 +0200 To: its X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [ipwave] Comments on draft-ietf-ipwave-ipv6-over-80211ocb-04 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 15:20:45 -0000 --Apple-Mail=_FF92C8B0-0AAA-404A-8F2A-6BBDA9915154 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, Please, find attached a list of comments and suggestions embedded in a = PDF document of the draft, with the aim of make easier their following. Expecting that they result of interest and help. Regards, --=20 Jos=C3=A9 Santa Lozano Department of Information and Communication Engineering Faculty of Computer Science University of Murcia 30100 Murcia, Spain Phone: +34-868-884616 / +34-868-884455 Fax: +34-868-884151 Web: http://ants.inf.um.es/~josesanta --Apple-Mail=_FF92C8B0-0AAA-404A-8F2A-6BBDA9915154 Content-Type: multipart/mixed; boundary="Apple-Mail=_6C4FB1E6-5F1C-4947-8CF5-867D918B36DC" --Apple-Mail=_6C4FB1E6-5F1C-4947-8CF5-867D918B36DC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear all,

Please, find attached a list of comments and suggestions embedded in a PDF document of the draft, with the aim of make easier their following.

Expecting that they result of interest and help.

Regards,

--Apple-Mail=_6C4FB1E6-5F1C-4947-8CF5-867D918B36DC Content-Disposition: inline; filename=draft-ietf-ipwave-ipv6-over-80211ocb-04.pdf Content-Type: application/pdf; x-unix-mode=0644; name="draft-ietf-ipwave-ipv6-over-80211ocb-04.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjYNJeLjz9MNCjU3OCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgMzAy L0xlbmd0aCAxNTU2L04gMzUvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN6kWctuXDcM/RX9wYgvPYDA QJs2XRQFDCc7w4sgGRTZeAp7Arh/X93hUareu6q0MDi+D84hKZKHHAkxaOCaA2kw0ZAk1JJCtUBC NVCUdqe029T+spRAnALV7T+xwLG2/7RpkNiuWAysuT3TtHCW7Q1uyqk9k2tojzSFpX3g0i5HDqK1 PUjtQ2p6mDVIFWrKKGism9YclLU2rRbUSlNv7VbevtlKsJjbMykHY2t6mmYzSUEaOCvtsmz2EMXt e5phTZkkCsm0XcntQ+Z2JeeQSsMjzeoc2/0GIeQNizaEWZsDNJaQrX3hu3en95fvz9em8PT7t6+v j9rc97C5bhPN6E00190uRv93c9xNNr/dpOC+4uXmtJvE65vLXFaXxeXmr5skSPb3N2e59O/ZXHWT husN900m3Ic+Aa7NSTepuJ78vc1DLvFccfybezapwLM5p8mn06e//zqf7j//eX69u2uO+un5+XJ9 fSRY58qUEqQrVY6QuM9QyvgSGKlskHifs3/p+8vz9fx8fQ23+6c/zl+/ff758va4qbUWiaL81EC9 nLeg3R55OL9evr98Ob82jL++XX/7eP18PQd36ulDU9cidPt8/3L58vF8fTzd//Lh9On8dn26uzs9 XG6Px3+t/Y+xCLV7nHrgEDeEDdFCsBAjhMhFD5QLhCUiai4YsUPoXBgCiLghbIgaggX3w4su4Gu4 Gp6GoxEn14IjghOLA2auxVyLuRZzLeZazLXgJJprSXEXQlqMoR9cj2Hi2Rgmh4xsSQ45OeTshiMz kKjZDc9ueHbDs2tB7mTXgowurqW4luJaimsprqW4FqRccS3FtSB/q2uprqXyzplJ15zpWe7OrDrr zOqQK0pZ3Ie8psW0jUPMKU4HnSKKc0QGR6RwBPIfZYwgUaSpF3kkD5JPkX2K9FPPv/Gwx8UAEdLF Tfe6OmU66hOhQBEqFHmJGiF7XVspsjpA9qI3BxlRQVEkVEWSfRaQ19IFyCJjY5hOBMJBIBRiQiWm Xop/FGEcpF5/dd/oSFZzRsdep/PNrvcGFHm1A1Rd7credzrUOg0VzYmscy5wMEAnNChChyK0KEro l6k3RZiKEq6o4YoiruWQM94kF1wwdjWab2sE6ITGRuhslA6VabV1kLdJQPZmOcemECVvpiNE77kr EPMIsUxDROAJ7ZvQvwkNnEqnUThAR1P8KC2YUkZTyrwpFaaA31OFKX2eqThAFQeodpZ7OEB10SSO wwHiOH2AOIJXo7szujujuzO6u4LJad6nL8fFg8Y0mkLzphBMwQDFGDUYswb3YaNPG32gQlS1T22I qnpUR1Np1VQe+grzdF/hPv9w2UNkW4VYB4jOHqYgOhEYoTn1WIAmNkKbpnMMYsEgFowhz2KXmNMi BjXkiCFHDDliYLYGZms4gIYDaNynP+jFRGsYaQ0zrXF/Hnox1ho4nEk8uHKRZrIOnI1V5115OICa VqGNB9DmD6D1xQG8DHppoJeGU2A4BdZPgfYpHVHCtG99Qu8jOgiQgQAZlkKWoAfLKkvQk/q8j2iD ZRhYhmGAtnyItq0mjnO47tI87VKYyDCRYSKnQ667cxYgpzHX03yuYx/BWEgw+hhjJcHYSTDYB+e+ YEKFxV6CsZhg0FoGrWWwGwa7YbAbBrvhsmcznFZzd2QzPM9mGH2P0fcYfY/BZhhshsFmuPZtW1+3 Yd8WsXBD+RSUT0H5FJRPQfkUlE8BxZDYt619fwd9WCAIyqzQ4ZStsigZFwQyvyAQUArhvnsEdFR8 QcUXVHxBxRdUfEHFl77J7KtMn9oHk2V1wSAyUBCRaQoifXnat6coq4KyKiirgrIq2hexfZcOV+g+ QUQWKYzokCCi0wkiWNsKRmOxvkQGdIzGgs4gtm+GYqsH1IZmKGm6GQqakKS+AAd0NCFJB+hpselI GqHneeh5n/aSV6HlMe3zfNqjGQiagaAZyGHHIXk1bcuwF5Ri85CRpnXPMqQs7gGlDmsYqdNrGKn9 VzSczdp/n9lP0VIX1zA6TtE6P0Vr3I+KujoVa0wjtGnOpkQHaIvcTMdfAvX//hT4jwADADFgLyUN ZW5kc3RyZWFtDWVuZG9iag01NzkgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDE5 L0xlbmd0aCAxMjcvTiAzL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeslQwUDAxNlYwMwJSRgqGRkYK Njb6TonFqW75eSX6zvmlRZmpRfquecn5KZl56QomhiZAHUH6waVJJZUFqfohQMIQTOqDNNjZIeuO SixIcwHqSkosKdb3S8xNBYq4JBGn1yM1pyy1JDM5EcluY4jdYJNA8rhNAggwAFX/Rh8NZW5kc3Ry ZWFtDWVuZG9iag01ODAgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDE4MDMvTGVu Z3RoIDM5MDgvTiAyMDAvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN68W1uP28YV/isE+tI+aDT3SxEY SFMUKNCnpH0KgkDRam019morae3k3/f7yBmKDCwuNaINwyvqwjPfnHPm3KlkIxulGqVjo0KjnW9U bIzBu9TYgE9k46VrtGqCwYtuIj7Rpkn80DYp4Z1rlAx4i3uVV40OIGd9Q5LG6EanRlkQN1jJSdUY LOeib/CV8kFiNSztXGMs1rb4HvQSiBmQkArfE0XC9xEwQmpMAg5vG0sgTja4RVvcZLGUA1BrAEX6 xlq8Ap8FtAB8LSTHbQESvrTYqAQoC5JKuQakjEqpcYCgo22cBjQfG2cADX+cBTQsTqgeewevTAA+ h60F4HOgF6NqHCF6D74BIoji0irg8wEQwQeQtAZ88IBiwAewwFr8CYDuQDxoQMU6wQAq1gmEKvEe W4gJ70EvgQ+QjpPgQwBEhU3gI6fBxAhIBlIkFCsNJIbXGJqILTgQ59Y8wEdADmAeILgIIeInLmE/ EfQS9hMTtgBiYKFX3jUJkDWYl3TjDRZPsfFO4hW/c/ixkvhhULzA5qPlBXabKG8ZsU3sXXEfCqAU FgqaKqCoWvxKaWxV8hODC6BUipvFOwWdCwHyVdTDCJ4oaGJIWEdBF0MCZAU1ixI8VBBpVBCWwsL4 LbQOy0TDu6BC0QKCAnsBEATxdXTgoCIjApRaYYcxUgch8pjAR9JKUlJrwQQJdilwLymwUjmyw/E3 sUnG8jepSZZrQfzJgYaC/JMHH6HsTQqen+DHEeqooAIpkQmBZ0hCCRSkqyTXVpCbktrwROKdNOQs uSKt5EnhHZYbJyDpuHNuCETwu8Q7At8n3hFJP/GORLCJJ1XiCKhEvqvAq0gJYD88AhBB5KlzlAFQ aXJacTda8g7Psyh5R4BENFcEDFwp3pF4whRlw+NFlYfcPK8optY0cC+6NQ4QLayFom2hGXI8ta0F 8firaUM0DxkVG1fYVytRHcEnTX7rBI5r6oaR4Ia2tDoK3NCtCvCvhtxgiWhHPPXD0oR53uEkbYXh FbhIo6KMh1A0JWECLIBuNYr6oClvQ4XQOJlQHElTZ6k5XIMctjrxW+zc2vZe7MPibOGKGhZoYQOt YeS3VIn2IOtIveHR0JS507RglLkzuI+mCKwH3zVl7jztXauEgZKhjF2SNLO8I+E3mjL3NGmaMm8P rabMcWyxS8ocB5dXkdpJepS5D/jWSCoqTxZNlApQNlxRQ6mshic38BtDHQywY7hy1F8YCEMtASh+ hjVCbL+lY0ngrKGWwI7BmkKe0G7I19D1gLm80tTuSFtM3feKV9Tz0Npj3hGhA4ZagmOJOzS1W9I6 wwZA97Hf9pAn7tLoVuMtf+ep56RHvYKtIBXqr7S8F1yX+Nd88836W/z/Yf2f7//J/39+dz4/n/66 Xp8Ph/cnsd+dH8Xh+Hb9/PC4/mX7HOJf3rxZ/+1wfNgdf6QXlT+tv99tzz+CZ6JVxCASIOKYiEDP FEVU+qf1Dy+/nH9/3q3/tX/6df1vXn379HQ4v3lz6/rpyvqwGILrlvWDFZT1nPXH1P6+O53XuiPq k6DDkcLDm4YoJN2OEs64W3eEDT1szpvzcbP9dXe8bOvhuHk8n9bbl+Nx93ReX2Out4IuUCmhLV2+ FrDFAS/qdigVwoU54d5hpcBcnPqkKGt4bTDXVrDifHw5nXe7C4D3++3u6bRb7Z8eD1cwJCPgUhDp CNUdKwHHbbSQzt4sXtuRjIE6CucrDKxhwm4QATBqEdqZm4majqgFc9owraNqE4DGaqJhiNQkKWwc IJVKmHA7UT9CWqgWpJVElRxB9R4vF6iInARimpupxjHUTDVDrSWq3AgqlDvaAVTvRDAVVLNWwc1B NQvVArWWaJYVqMC6Wy0SPbjCOwI3QKzvBZqJFqC1ROMQqFFCxgtQq0QKFTTDCGgmWoBWEtVZTxEA CuZCgEg/qKwRhjmgFDJVQE0jqJlogVpJVOshT2UQrfPPPFVR6BrPpkZAM9ECtJaoHQBF9CWsvQCV XiDkvZ2mGQItRAvQWqJuJHyEm3CkvfARQQrr7oaaiWao1UT9GGqABYwXqBEhQLgbaiZaoNYSHZ59 7ZKIshe/ZvRUo/ujs1+IFqCVRI0cAs2hYgFaGyqOTn4hWoBWEjVq6KEY20oof/FQyCVFMndDzVQL 1Eqixgx5qi3CswtPjUN8VkFTj4BmogVoLdGhK4WVE/riobQ2QlVovnEjoJloAVpLNI2ELxGeyYHw mQTU6H4cQc1UC9RKonakp8hVBUuRBaoCcavU7VTlEGqhmqFWE9UjqMELlgB6qPjYmbuhZqoFai1R M4KK5C+wgoPAnFUFJ7y7G2imWYBWEjX3pcmfgzkKzQNPUFto59aDQRaqKmiO4t1CM2+9mujQmpTE HHRnJ+avAy3ZfgZaSdQPYzOPv0hFeqBKIiu9naYbAS1EC9BKomGU63q8WFb+LIjjbYrISiuIjuKd QjQjrSUaR6mu5+GRF6TRC5sqkI6cs/cGtC9Ig0WmW4F0ZElwxJGTXpB6jZy0gujIOxeiBWkt0ZGa GlgUlqU77+ydhJW29wLNRAvQWqJuCFTD2sULUBORk94NNBMtQGuJhiFQ5ZGRXoDqgIy0gqYfAc1E C9BaomkIVFrR1rMzUOWQkVbQHEU7hWgBWkk0jc69Sxopqe1Pk0RiZu5FWogWpMsQjRLWvifqEjLK +qpp6+2d80jIbPb2zgfkY3ahSvTxcauQmFyrhed8uGQaDrL085KCWxAgHbLXECCj97ZHoHE+bX2u 45ZuNVRxlcU1XXJi08ArEkGXvprlEHAC4BoCLwW7dW0Izao8IlSbQ2hdW+JeMDINqvRCQDP2Xt9o kIvVXr+EElZGanV/UgFZzjypC2m1SWB842QSbL1aK1lmcloihbV31i8sLGRkZ7erXVlIOtS0LeKw E1TKF8aFrvFXV74IA0Up+XunKLPS95uYD592VfmB/pKVwa96PS8rWwiA1V6YC4BO/WrTwrj44UtD 15NbgNn1VLYAgxwqU9FQTifUqmdpgLUgrbKCAw0dSIt0S9V0f9TynCztD1h6pfs8I/fra/OM4Ifc 7DqKnEmQonQpKyTkRjRzP01FSzdR3U/TyzsGP5pAKGm7MUbYpZv0OMSIst0rMxDZjFGZFzdiEx48 TymU0mIZAaksLarli0vKLk6y1Gp1CCL23jPLvtZ7hqykOiIHihx7FBx+M8i0NReJYGjFKEHevYrI 0GHykBo4zcEy5EacrUQAc0cvveVpGSXIVq92kmAYvJWWP1iR9LyO/0IBUbY7pT9sIAQ7r5V7IwB5 7TxxxC/3PQHhnr6nCssfpqGXL26kk1KtFymt+ZwK9Fl7F4vOytpvlf2fTlhwf3hamStCyLk+DrRs ZzQlg2TEsakiK1dpcSlo+ZmkvCuXz0rKJyYEltSV0st2hlN5RbAdN2urMTaN0oG26w5z5qAsuelu qicuunQgJ8OdUi+eC4/Uz02qX+9SW4bVelS9vEfVI4+aOysdv2obKyV1pPXrS+tQZWWrk+zipHPh plDNNnUW1YV8iob70JfiQZ5Srd2XHvrevrjfHv5ZZfib4r7or8V9PHrB9tVgowMCi+pqsB56/27u w+RNdWMfpnqWZEHF9yPjY0DMc+swZRxTxAmwNTiHLrUbd+sDn3ba7UtZn6vqikzCXmyrsU4YW21c bd4eQyo+atX29XVf7Wj7+vVDLV+jgBqCVlcLKJJhdN9dRi7E53gqjWDp2+XB63K2s37V9thsPgd0 J6xZZjecK2i1ftiMQpBcwOy0dvH6pYsxTc+H50Ath+u1kZoZxkAlq8sFp9qS6PKVBzN06F17sw/B K7ub5gukyF+xwzHhpSzyXKX7ZxgsIqs07xGGiVmyQZyoR3FixXzW8k7KxC9W71gw3bdy+SkidV+r cmJ8rCOZrUwmWWlk7PD4dmP4cPeG3aXaKXxrv9hEVmdk2tEEl1HWTibY4ekpXoiTeH7hJL99umrF j1b+w+Zp9bB73Ly8xyf7h9NK+at1lzZLLZbCwLDa2oedZgJ7ebuS1+CwBMTp11yvyw9/zarX1eA5 nz5+eovL3W4VpV4pNYGsi07YO+IDyblOY+F65ZKJ8kTbOhv1Lv7mwzY4NjPj788j+PTpk8CSq93D /nw4tij4TNpr3XOs3z7kkx9PCl7Iu4qVdTCy4pZWSX5Mb1ar5JbHBNXVdKEtgpeKaUmGFq+YTrRR teMoTo+gm2K4A8GEHCa7uW39sn+4BhHBzAd2lkSRtaGvIGdtmFNBXqiAnfsX5eGNzpDOenbjdj5M oLBRqMuDGXCDyS/8YPIrRR9I3l66cj7SZN3RmJtmg53qJuQ6okmazra2kOjs14voDYKiaQUv48e5 nDdr/Phmxk7CSP1gcWbsrMHim0zuVR/MGBx5bz+Fayzz3uXLfzL6aR98mQNuffAdCCbEMAHDIECT +jLl6zQH2mblwUvCKEqZZ3iz1Z0VKS/UhudDfdDBMklaBtTmTJLezogJGK3Z7QfaOrO7eEEIni1N mt0SxWeze0cYP8WG6yhoHUq6mK3DrHxxqapHO9dVJghyYDprguB2JlxHYaJt5wBLCtMpwx0pTB2M fDZtMPBYfXxsAc4Z81WKlEYZmmcLcyCRrxiPIIDTZwhGFpfHBIw/Jm5tLWzxvG1qUqkboi0FJCOT CPMKSDezYQJF7gf22SNstrsnebzChnAdQE7Ycr5Shjy+SL4yCSP1yUq2UXdkKze3TkqiktOEzIUv kydMwriUckuAXFnL9cMAuTwn0BW4ah8T8ItX0TOj9ueTeDicxdvDx/Xut/15/bjd/rx7OGxP4t35 wytRThmCR7xb3UgHjnfHzQsEdDoJLN4hIYCfn19+eb/frjfn82b77sPmvH23/sd3362kXyklv1UC uvVKDa+EH100WBl+fFGEiEs8A8V2bsWFJFxYtsr4393h6e1q//xp83G3+rh7t9++vN8cV0+786fD 8dc9vju9HD/ufl9Jc7W8pRnS988GdK2TOX2wrw61uPgyMpkHMesDnqtYn3dEdFrtn86b426z+vDy /rzfbk7ntnbK0umrIIv77R51Wdb/FpDn4+60fVnhlK9O293T5rg/nFbH3f9OE+KGH3aXMmKpZi5a RrwDXnGabcOEcwO+rfnO6Zh89mhTXL89vz8cd4KXLUSc7ZcPuycOzWqP47l+xXUh5fKxH2XQUeMU T2H5vwADADlWckUNZW5kc3RyZWFtDWVuZG9iag01ODEgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVj b2RlL0ZpcnN0IDUwNi9MZW5ndGggMzAyNS9OIDU3L1R5cGUvT2JqU3RtPj5zdHJlYW0NCmje7Fpt c9vGEf4F+Q83ykwiTY3jvb/Isjqu3aTqJI7qqP1i58MRACXUFMESoGX31/dZEKQo01QoW85oOtYM ROy97t3uPrt7B60FE0xryaTx+PVMRYvfwLTHoyOzEr9GMOcNfiUL6KGNYjFQuWZSGocXw6RSES+W SR0lXhyT1mqmrWLSS3QGIX3ELBaNo0Vja5mSCo2tY0oFhRcwYAw1Dkw5gZGdYco79HJoHCwmdygV Eo2pVBJbjljV4HvBI6iAdlZg5ECjBxTT6I56BPDkaZwQiQAVQUSJUSM9EcXg0gjqEQMzEjOjmBkV DYotM9qjXkpmjBNUz4zFThiJ0oDBjMITManB2qy21FUxa7ABRmnmRDeYYU5io4yyzFmsySjHnKMB lWdeC3TXDi9gChMy7w2VBOaDppLIQqRJ8URBJaiODqyCKRY9NtJAolJqT+w5kpPH2JbKArbo6Gjw FM+vg3++PKFn/6Jtp4eDQVWW5bvpuJ6VnF55PTsfFHU+vywn7cAbG6S0g5TnZdOUxcHx8eAv9awo Z69Ij8Rvg5dl3r5SynANuQnBjVDYFM8jJC25iuq3wa/zYft+Wg5+qiZvBmf09nQyqdvj4y/JkrSa Q51kCNxCKkooDgWXMXII8naebo72vGwwqV6M6iIW5r3gDnrvA4fQfJAcMr//ZcKQVBjcvjznLXek odJxp5gLjpv4Kbw0bZoUaVY016yMqknRtEWzqhsEbKKUmYIx8ov2cnw7b9YYHhVZq+YwGWstD9I8 EN40fgh2hOaeWNU86nvi7bxs6R0MQZpXk3GdltxNiT3Bp8Xodu5gQxy7RrBFGmak5srqh8Id4JMb AtXF3hkhufb67ibl10wKLoIHci4axkTQz72+84IbrLit6zGtth11q8ViBsUsjdqMirJqepXelvh5 67L6bTnLsHIp63yYCb1t0dJzeD94SW4MOSyAGvyNcFxr9YdyaLZwqL3C3q04NMAj8msPiEO4A48t DJpbgJSShsP9wblyY9Xd9SbcNxR/1prV7XrjFcAPHr/XG68NF9I+CM3u9WbJYa83D4nDhd54iiOM XeqNVwCrP1jI8nYhr/B6IeRPxOsvooa9kJcc9kJ+SBwuhLx0Kr2QP9mpxAcFDuJ2vXGIRinNWYID vK+yD0Oze71ZcrgEhwfE4UJvHH5MWIGDiwF6Y++sN0Gs6Y3ykjskg4tgBGkqt/7ufirIz1PFjw2p 7n/I9cTGIVL3yvYLdx5bKj9hSLM2JHIvBP8GuStyAYTdigtr7j6kXY8VnQOXuh8SqTm4vDtSBHf/ e7ke0UIpkXguF24iErNP4TLcP5frELnMHxdcfmL6uMW8Z6PciOC2AQzSQaGuEzEYbtgtD/vImuK6 +RqN/RHLXMIYDBzvvvPx/s03fqb5Pj3FvxeMzrsEe4ltffZKYG1BGMkEYiJNx3oAaGldwIKfzcrU VvXkeWrL/eeHSO68iALRlNFK/Umo74X4/mDwAzODn7dXv/h5XzmfhE0SmBxD5p0RWfDJZIUcRYes 3lifDganzBBXg9N6Op92R2NE/WOeitO6mrTNKwNJ05mdFZ4H5ZmB05PWXNN9vYmeTGVV39O92hiN BarYGZRHMmGQOCok8CJw40O3f//eP0v5RSrqg9Vu/trOqjflL/N2cLb/97opDz7c2h8A84NfpuWE jdK4KQenaVZO2u6oj5bRTW2RYIkuNyV2PeXmS+av5dYtf5vgSDwrwUEv8EgubpMUGLghqZOXZ93Z IjF1cna9rrPyXfvXomo/FOV6f4gyDLUYCSezoRyKbJQMhKp1yowZOS2TE87kG6JU8kNRKkPhIx2Z Co556PiYKwore3pZ3wV1hNF9fU9DlGeDH2c1NmpxemigvVbRAS1iDjpKlotjRASB1vp7F6oSHwpV 2dAxvhBqv4xdhSq2CLWetJiu2R9XTdsc3EXIZ+BtOk55uSFOpdfF6RPYdyZmUYoiy0u8JVUOM61z 64cyyFwNN8WpF6t/tn/053eXY4ZoqwFbT/bA9d6fj4+GdfGeoWLSPNnrj5Gurq74le6AXcYYB+/o gG1v0ejw3SjdaAi6a9nkF+VlGoDMitSmAYYfoM8oHT49PfnXctKn+awepvYQAbFEbLBo0EzL/Mke SK722PHRlBXV7MneuJ3tHR810zS5plnTvh+XT/ZG2Oysqf5bHiIOFNP2cQuDyNK4Op8cjstR+ziv x/Xs8FvR/T3umr/+5qqszi/aw0k9u0zjRWE3Xl+yd9yJ7mhAcx4fDaZ4aHeODwYvn0PYiAqDtGz7 y9LVUUpNtyvkZSXdmSCipAsSwrDeNUG/wXHNqklTztobev4Mant3HVebOg6kVL2K09RK7ajhgNs7 wpYV4iOw5XaGrfX+0HOAVTLJpUxGYFfpAFtDYUaZ1aKMMUntS7Gp5/ZD2JKajsRiFzLSJZbSnmu6 POrpVT0FmFpd1y/oD2ELDpcruk5CtQiSEYyRddFwPn4B2DIbItW2Y7yX6WIZuwo1/A5sXV2Us/Lg LkLeCltW3ICtPKZkpbfZUIdhppLRCCiEyJAVQ7ZeluljXsh/ha1dYasT3WfDFnSby067pUVSbChC hQ/3CNj1FwItt6nhsKlrBVd8Z/028jOD5KjtbUHyejV02qAwz4PMdKFMJrXxWUq5z0poNspHKabO FUuh17Vab4TJiLY5ZmGYByjCFNYc7TXZ13bnMt6uqnt6KTnk8VHK7jTEq+4+nQunu+MbbMy9I5Pe kJt1hIG93Ba87yq363BKdrgUCPRJZOvgdHZRsos0KeisiFVNMyeyYcMSvKUxZAowyOtJUyEHKwuW hmj4iDU1m5LdDsfvWXtRNYzMjTUX9XxcoC/0uC3PZ9CEAq9oUaJ5+baq5w2bpllC1fSi4expu+g9 JYmxEyImb1jVsqvlQMOybcFYZxpFlWNEdnVR5ResxqAz4iyHeZRdz/OGYRvRMB/Pi+uZlxfBRJeQ FGuwu1BUfgskW63WIRnCuqm09gO/OpSpHDo1zHLjYoaQxGVpGH02KtTQj2weVQ6/+iJdwp7ry+5a elOD41dc3hWX/7+19vU3t+rtR/1RdxxiOVSUwiy6eVIs6J4OiugerV7UbWKpuCib6m26xixyQL8P V+1svoZWYcPLIHKjmXs3szbvDnhlfyeOerTdYJUQKm53MqjWN05iUhiOoixSNrI6ZEOPwCmOCoRQ So68JXvVCyej7bqJGvPVRHc10UfbwyYbggts+8vS+QrNHZ1nBfp4Q3WfQQUbmImSexO/SOBk9MYx lYlcLh0wTS13dsBhFwd80sMGerMmETClHl+qyymAKkFOs3pyTmTKW8ZG9YxNyqpDkp9PTtFxRtAw n1Xte85OJk0L+GPLYVdD7jVLdGrTG6wb2FWzlOf1fNLuPWI0SHVZjdOMs9eT15Mfq7dk7sTHiKZ9 xC7rYTXGHAy4u5pwDT1TUSyhlv2keMcbehfAmfMJajDdCrIBkFeE1ZMSWHdVz940j9hw3rLX+z2c vj7AutiYgLV8R2cH1L0k5a5GVY7xgd35xQSaeV6VXeW8WSB8U1+WrB4RfF8Cabs9mE+n9axlqWnq vOoABDOtLwPTEdnBc0OiuCU4sFpbvR1rrAberGMNICaJUthMeCuyaIE1SVqTpYhYE9BT5EP9MazZ DGgFXdAEhPKG20Dnu4HTt6VLelWvDJdeXtf3tBSOO0QZSinu6VO3QKcmvqf9dT3QhA6Gl9Udqdaq RXduq2SkS72eWtXSl4tSLWsX1G9fIXMXyPyjoOC7/8zr9vEteLBocBMUvvtWisfdv0+Ehtff3Bkc HiY0bI2/ENDDQS1sQAS6S5Hc2IWBRrnMFl+WTRrfdFV/g2KMSTnu7K428sWoCAuWEVgPDTs6LPt5 12HWoMMtwHijmjL9WAyTtUU28tplzhqVDUcF3YkZbZCPS2BKB4zmxvmV3QBGrRWnD+FNgDW6tQuw nl7VewQU9Cn5sn5BLw+XVeRqUSjozkQ7Tt+NYwwv7/8+zG7ehxnVcdtHGgveb5Pc/wQYAAiPEQ0N ZW5kc3RyZWFtDWVuZG9iag01ODIgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDQv TGVuZ3RoIDY1NS9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN50lktuHDEMRK8yF4hG/JOA4UNk ZUfIDYzscv8wcNRoU+FugHqiWkWqRv6Yj5eX51ycP74/395/PL7xwxkfv35/fPx8QivMBWB3jdGH hAXBRmAB6h0xlzG3igtIWpUWMLcqL5DZqlJVnjyczCI2ohUhhzHNlGwjtkCp3cOrquZZIOTaIhYY duvz8O3pcNaVYjBAPEg3ktZatAWwqqg4ME/H++sw/fW+AB8q2WDfslRZVQdECPJGtCJonGcwA9mI LZy9QV5VYhmcbbI9XxgLoS1Aq+8ezbpSgkdATN3tJzgQpKHksr+fcCG2TSSqqgoPgmDZNhIvzMvS FZBUrVW1qp8t1tv3pb/cXjBKf6XfPKp6XCEu/h4zymlynrXZgaGqZwE8ELZB4ca0EaoISSJgbHsS OV3W1keWqipjjlnQFWOsBwI+1HJcLi+sIsc8sR9ImSeOSrDywJz4K1NkRdtQmcfy2jKBinzeKeO5 Z1KwIug65pWKQodOGfuQAbB7Iml4Hy0ih3qPFtEq11wVO4jaDvGKHLMlcSClHRlgsw0QnXX50SuF AwEdBuZ6bYEVIY3MUZM9vEqVwLAcLJt+IYfdR0dUFkF7BVQP9d4RtSofQaZeEZHIMHKflxtREbb8 ywBH2S2xajiiZkc03xSbmEeROuIGFSGiIWIE++ViWBGUmbGSI7QJWkRtshsf6t0vkyoffplWRACG iQvsrppVpI6GpencXjNLv7WNd69vty/irEu/RoCnxdaXTnetr01VrdfbuRJCkuPsatcHSEWOx5un w94+Pd2qyhHDzcmvAulutNffo6rqMfIQeb3/IVEtPo4RsxZhwUHicL2iIp/f/RMpcP0N7v+rr69/ BBgAQhHjZg1lbmRzdHJlYW0NZW5kb2JqDTU4MyAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUv Rmlyc3QgMzgzL0xlbmd0aCAzNTUxL04gNDIvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN7sW21z28YR /gX9DzfqTGNNDfDeXxRbGY+dpO5MHNXxpB9ifzgAB4sxRbAkaFn99X0ObyRFiqJiadrpyGNJt1zg gLtn99ndu6OimlCiqCHaCqKYIMYY/JWEMR4bijDOGRqaMGXQgMC0VmhwwrnDTVwQLiwu5pIIyjga igiGnhXXRBgh0TBEWG7RsERyGm93aDhHlKBEOoVPBNRUxkb8NPYs8WrS4hOJB1uBniV+HJ6jpCC6 uV1KooWDHnea5nb0bljsg0piuEA/FMNyLDY4sRSDxQOJFRixdJJYaeIngjhm47tw4riRRBpBGFW4 UhqOlrZ4Y4NpYFTEFmaGMfQu0Q3jUuEzi+u4UvEzzJIQLLYoWjI+U+NeqZqWii28/bNnoxdn+PUG r2YBxNvT09HL32hqnaUYM03RCbpBgzMFhD6MXlbTOkzrxROfVcv6ePRyHnw9rqavfB2evDrhlBnq qGEaz2R/pfwbSr85Hv1A5Oin62o3qN/89CQXwVjNdIJZ1UmmpUmcdzzBODERUplc8uPRGZA28T1H Z9VsOWsMJ0r/WPrirBrjvX4TgqdC6TjFqZOWCM1Tui73eqtShekb9K38YfT25ZNn3325mJDPYb7A yJ4fsZQefXf6LKuKKwLFdPH86LyuZyej0eXlZXop0mr+ccScc6Mv5/XF5Ki96ORL6TcuhNxcucjP w4UfQUwKX/sRuh/hntKfvDh7/Wv/0Bf5vMp8fcJMyvCG7QWLWcifH0FM+RE5fTYjxXj+/GhSz49O ny1mfrqSyaK+moTnRyXwShbjf4cTJlM6q7+tw5c68ZPxx+nJJJT1t3k1qeYnf6bNv2+by9//6TKM P57XJ9NqfuEn7YdNf90nR6cN+s9G8Zmnz0Yz/MTZOT0evQ15/ZvgLoUPSitTa+MUq5RpBgh0Cqv7 MPplmf3+5J3Pz31RHUepvpqF0S/1fPwp/LysR++e/L1ahOPRu/jxi+m0qk9PYaU/EG5HP8/ClJR+ sgijMz+HKcIIdGMEzaPhLyklQokGbGOi1EH/YXhSYzzXe+8dgR3oCDcaPtx9n+Gvq6PhMysEeCVR hpeJLaVIXBAq8UyxYHKqgmU7DB8Mec3wOTWpxstLgVnG2DkTqVJrcq/nOo5mpW/lD+38cSpTBQ6V XKWRTzjTqdZgIwE7fADsQFHXsONONu/bYde+/aHYma/GzuzHzmxgV0iRlcYlIfciKay0ibceIg8c PC6ygha7sNNb2GmQQIwCHVYCmEhcNmDX6zvsBv0mdsqkDjGyxy66YQyTD4aduk/shFrDjpL4g0Gv RZyn+6INAvte4ARdB47lWpV56RLt4HSCyjLJcieSnGcuaM9yx3Y5HeayGfBjhLg9QjzdGR1eAVuQ jtUg2RsbnTkzTlOJxEwYm8b0j9tUWyR0Mapo01szXrYi4+kizOsNq34JI72zRSO5vG7REukC7S06 PhvSoRYtv8qiJd1r0ZKvW7TJlPHcwmAybRKWSw0qwi/rRJ6VNuS53mnR8tGi78GijUP6fcPfzpqR uqeGMiRDOqWuzTcjGKhPkH+yhzHn7eAq4FMoJzpzNjxKh5qzuMWc6/3m7Paas9owZ8dRKxmNSiCA llUOgrag5iSThfKq1MayfJc560dzPtSc668naAFiRiEMbEHUKCl1KlC4CiQrqNUfxqK3Uw5mUVQM BK1plA61aH6DRd9oxZpvkvLrt++apYT4Uq/frVKpOOrvi3F93czX74eZa8l8XjCX0FKHyNousZSj 6tVZ8EWBooXTXWZuryeQDHNhhG0Kn7gW0if7vTzoEc4c/H/QtzIAfTf6cV5hqlpkHU81ZieqBYIi ZzQ1cXkFSFNh7z2T5GYbVta8eAdrO4xDYWW3ENXluK7PyWc/WYbju4D9Dm84m/g8bMMqN4Jx7r23 jiYl9VniJWDNWLDgCqsZ5YwLtgtWQR/Z61D2WoNwT1jmNtYoNzaGmleksrF12didFcgypUu5EQ9D Ym7L2imSg97WpU0PtXTpvrLeNWpv2bSuhl0LVahcFD4pjRZJVkiV2NyIRAejY4z2Gc0au1Zsw67d 1iIdjaStiRFxDYJIAIAUoBcHLRcYy5q6lTvUBEWV6xg+BW5W4irMIcZvhEwxhHvnKGGvo6Yci6/b wta++6G4fe0ak92/xmQ315hknrPAZIYIgzCjMEuoC3KVFEFmeQ5EZcZ24CbZddwkU2ks+3vctEX0 kIPYa3vcevUGbhJsIqlb4YYkNBZYDwSbpPcIm7lrvmCZ3c4XpDw4X1i/P65bGFGEAslwyAXcjsdV 8jIvk5J5sH+Wl067XUCKrXwhViHwSzwnNW5IBzqx12rnkNGpQd3JW9mCRhKB6kA722QJfbZg8FfK B4CUb0GqTXzvDtJmEIdCqm8ras4DqfBrfnwXmG/MFOxmpkBFQEkTQhJokSUW/phY68qEOziMyUIo C7ULUPWYKRxc5/QA3lOeEK0cSfqQKRjEIW30g2QKHVNsWDq4NO4ndqauonSLrd+4b7LVuxTgZN4v DyBQROlAT6LuFk96/fKnM1LNSfz7WZMs1PV+r+LyUK9CPr3uVYXLgw2KJV5bmSgtPZIVnSdWCa1d oSxVZtdm4qNXHexVO8H8ag8TsG5jLKzcYtCsWaDiTDaW6Jx6EB+jfNsLMOXDmq8yLkqH7kDRu6YI W1YeUwR6eIqwfn9cUhBFxlWeJYHbLOFKFokTFAmfYJnMEO9EWe6y/a0UQUgkZOC3bvxEIMY6tyb3 emClnVzpW/l6kiAkS+MRCGhpXDMyEClrejPq3vem4rmK6zWWMUi1Wb83xVyUDkNVutuyhPGU+Akg BkFUszD32SSQvLq4CPN87CdkNq+KZV4v0j10x+3eBX/u6EbmoJAnMJ77RAak8y5Il/g80wm1lnqZ c1Z2C/6Mr+EcD548ctyBHHcoqF+1L8AtTXU8LBG345mGObv2sETc/TIPsi8QjxhdpzyuUs4HyoMr QzrUOVZVEWucwzKnWaxj1z3kLCKdTa7IVbXELC4nBSZ3UZF8XAdSn/ualAgn4It6PP1IZsv5DCNa PCUe8xzK8RcSvoAbph8DuQixMb5YdN1kgUxDQF30FBNEYro3GU+R85Xk9ZuzV+T9k2Luyzr5PVTT j8l4duk/h+RzOB/ny4mfJ9NoBVk1T4rxIq/gDlcJpe+P9znq+mbyDkc1m1sZmeNU20wlufM8yXjc mSuZS0RpUPcbG2he7HLULUK2Ns6s6dEhUsV1djnIg15pNORK38krvUqFtIRJBFdUTb086EHsTsiV vpeVRH+r62UMyjE49/31+u76Qd/Jq/6RRuv4fIv37kS3Uou4ISYHdSs+nss6iLL+i17Ws+Ct4xWp OGy83WizalL0E7A52j/i2DceWrPNmkc8/slTE90L+ULMa6J7qWiADRG/DQs/2aTgv+E5k/imd6Vh s0XDjKLi0v1KMKgiSgfSsJFft6aIn320tqGOa4q2DEFTmTjK8oQa0BqcHHlmMMEYKqiw7Q4t3aA1 s2MpCoHCuX60hGHeHbMrudcLAKTESt/K/V4kSM65eBJYpRKPZBbuG9eiJPyU3fuOVTx+ez2Egq+c HUKoo1E6FLu7hdBxTS4bp/xYVQVBYpDD4MflFbk8D3GlA+45XkCAu8MXxxezSbhAD1Dk0Ter3oPL Zb2cB7h27peLxpebG98/aRXvj8nbH17GKq9ZP3kaW80F+L/w44L8vlzUw92xw5nPP4Ua2jhH2dWu bGlIqZBRgYsu2neJr+uvUvIavOOnTzcfE/Ow6RWJ3u+nhZ8X390cnRWK+71mzDYX4FywOSxbJUIE n+RGUqTR1iQFwrj3imUua7bqmHEbZqxvjM4t8ESCT0ykj04e9Dbmf3Kl7+RB35VXg76TV9G/LbcG fSdfzw764503ZQeDvpUf4+vd4uv/pQtiAm5zwsEFb4+jMCzZOIJrDDxuuwj2EHHUbsVR5IzMKt1x McNvZvWBXGzlnbj46MdQvQn1ZTX/hJTqKM7XRQVEfZ4v5yCndB9XUbFnG0+pa1yFmoAq61mSW1Uk XkubZIVyCcupLn0o8pzZhqsUXecqux1yDUudsf3EDFzQy4Ney9QYttK38iNX3I0r/vKvZVV/u2En 7UfbxnKjVzGNMOBaCKRUzbl8IVrIFGMP4VVbG6eCwqN5n53GfAfSoV51UIaTpinJlvXTpkpp6Aeu s6gaqsQ0hS9jsN2imiyjOy1QgXwKhLz5/qefUZQspt/UoOXvQF/+guD5ZBGZdVw2tRCqG3Bv0wvI uiHKajHOxpNxfRVZN5L0tK0eJrHSaYACOJ8b2t7nxNJQvceJpWUb3xkorMkxkTFb5kUS2sU77xJV OupKz/OgxC4n3t6L78rrDoe4qpPG77oNcq8XNqXxm2C9vpP7hKA9pR+/FYZCu9G38qBvvmPAV/pO XullqpGn9+u/vTzo4VRc8ZW+lR9J5CAS+Z/1iFvjf1zQdI1dRoZq7dIo8QBMpdW9HfGIBecBPPWq 2jGFmMF/vvj1+5gi5Z9WmRrEupmyyPbNYkw9X4YOz0C+X86rGdIt5IWLsK+wkWItG9jBM+LaWS0r jHJ5ngSWswSlsI1bQCzhVPO8ZKiRRbaDZ/RWYYMkJI3fLu0P+XR1RycO2v7MT6/u5JWepZhbRJXU KtmLg5YxcIJaqTt50LfnUgZ1d0yl0/bHVHr16pjKI8PczjAPZss35zIN+C1uVLqhQogmZY36owzx HwEGAB8KvyUNZW5kc3RyZWFtDWVuZG9iag01ODQgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0ZpcnN0IDExOS9MZW5ndGggMTI1NC9OIDE0L1R5cGUvT2JqU3RtPj5zdHJlYW0NCmje7Jdbb9s2 FMc/wb4D4T00wSCKl8Ob47gI0m3ogLZZGuwlywMlUY1XxxIsZkn36XckX5rYTqOsy1sMyOLRISlS 58c/D5VhhBGlHXECb5YYYfBuiBUc75pwcK1fEa4sYAEId7p1SSKYUlgQRBjeujgRllksMCJ5W1k5 IoXBJ8oS6aB9YggwaclolP6CtdMPdZiR0k+bkJ74eZjFbiiMnKanIY/nyimKnYGj3BFjWgMcR+Mi /XidxS81Nqvq6zo9a4tHs1kVx2Ps++gE/94TZXjb13icHp8zbNtenLKL9LiaRXxZsxcvw9V+ejwP Pk6q2Rsfw96boWDcMMcM18CZ+4mJV4y92scBQ/puw83F2v3+3R4DkeW28ElWBpYUDMokA+MSAJZJ W3rpGd9PT4hQ3bgWY8dRssWMj/dGr2+vpuTvMG9wNIcDHOvg9XiUVcUXgo5Zczi4jLEepunNzQ29 kbSaf0q5cy69vYxX08Gi0vC29Pcqot3VbHKcrU/RTAoffYrdp9im9MOjk7d/rF56lM+rzMchN5QL HEBXoalDfjhAk4oBGY9qUkzmh4NpnA/Go6b2s682aeKXaTgclPiJk2byTxhyoKyOBzHcxsRPJ59m w2ko40FeTav58EfW/Q666n/+cBMmny7jcFbNr/x08bDrb/lkMG4DNkrbV45HaY1X+3HG++npG4ww cmYR4YcLFwusgCkqwRKwSBQIAlxSZVzHloEFXH/tneGAKzKZNWEefVHtr5E7RlJjerb3W9WE/U30 HsTa7MJa4KL5yjVafcEWj4FdEV/4OpLa559DbL4FOQN7D/K3ZzjMeurzsMU7M3d5ByUZt5YlwUuV WAkmybgXiRVW8yAtU7newXsbkBfee/K+EceH2TfCckUeLizZF05QcMi6Beo0kYxRJ1WHHwbwedBX W+grSR0uwBX6qrX6oi8fQL8/36dn6/WIrH+M88nn8OE6trP+uZjETervtkfqjbMi444lDhyyHqBI vIUsyXPhXSlzZYqwi3rdWb9f++KkmuAaPedWUotb43L+RDhNDTdre+1HmVJSfvUvbAzoWfrrvMJP 1X1abhk1SnaRtRZ3ZeeoFahu2Ew5uwqtzy/vhXQ9/SeHVW6FVePeDCtFU0y2Vt+wwiOKVs1IrGpS lcR/U8wk6ylmTN4TM5EDCMdkornIEi3AJhkTLMkwwKwoVFYW5a6wwouY9RWzOyH8bh0DZanluqMb c03QhgolOugwG30eHePbwCtcYnYNvGmtvsCrJ+vYJtqdjsn+OnanPQKPebyBUBaYraKY6QLyJHMM EhZcFpyRumRyF/BiU8dAYiKD63c5f4yFpEzesZd+cIZiqrX2L+1NHQOpKdeui6zBt4FGu+3NUkym /3cZU1vnDVD4QhTQZVSdba2+UdWPylggviHXTSgQzG8omXTc9FMy6YS6t0EVuQVWQIIZZkjyDACV LDOJYFqUvMwzXe46huiXY8gTlOxuFL9fzKylCsVMtVmY5R36rlUzZM8o9SxqprYOJKAZtXp10NZM tFZf7s0T1Wwb71bNlouxh5rda4/Q467NPVMqyYsiSzhgVmZF+1fkueYoHKgfO6BXdlPNJO4kDjPj 5fwxFoIaVKuVvfKrNpFWsPYv7U01kxqzMbeILJNdbmelw97wyCn+m5j9K8AA75r+Wg1lbmRzdHJl YW0NZW5kb2JqDTEgMCBvYmoNPDwvQWNyb0Zvcm0gNDE5IDAgUi9EZXN0cyA4IDAgUi9NZXRhZGF0 YSA0MTUgMCBSL05hbWVzIDQzNSAwIFIvUGFnZXMgMyAwIFIvVHlwZS9DYXRhbG9nPj4NZW5kb2Jq DTIgMCBvYmoNPDwvQXV0aG9yKCkvQ3JlYXRpb25EYXRlKEQ6MjAxNzA4MjExMzAwNTAtMDcnMDAn KS9DcmVhdG9yKGh0bWwycHMgdmVyc2lvbiAxLjAgYmV0YTcpL0tleXdvcmRzKCkvTW9kRGF0ZShE OjIwMTcwOTA3MTY0MTIwKzAyJzAwJykvUHJvZHVjZXIoR1BMIEdob3N0c2NyaXB0IDkuMDYpL1N1 YmplY3QoKS9UaXRsZShkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMDQgLSBU cmFuc21pc3Npb24gb2YgSVB2NiBQYWNrZXRzIG92ZXIgSUVFRSA4MDIuMTEgTmV0d29ya3MgaW4g bW9kZSBPdXRzaWRlIHRoZSBDb250ZXh0IG9mIGEgQmFzaWMgU2VydmljZSBTZXQggUlQdjYtb3Zl ci04MDIxMW9jYoIpPj4NZW5kb2JqDTUgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCAxMjQ0Pj5zdHJlYW0NCnicrVbfc+I2EH73X7FzL7mbAQVDwHB9gpSkXEmOHu50Op0+CFuAGlvy 6QeEviV/eVeyTYHcXS9NIIkDkr7d/Xb3036GFgmh5d7VM8mD808RrHQQgnurVdDt9uCihb/9iz5E 3UEfFAuWgT/l1j8HYfl/9UhyGMWIMoABGUC8DErkECL8iTokbEOcB29vmdlKdQe/4R8uVnCtpC3g O19DAjNmFNOJfRf/FYQh6fdbIcTT4O1EGKYEM80fFV2a7wXcvy7HwwZMJ/P43VmJJVKWgjbUWP0e 5oaKlKpUQ6xocvdtqFsCIyZoTpXDGt8XHB1+D1dsoSxVOwj7DWi3wv6XT99Im9EdTHROeQa/Cr5h SnOzc1jPjur49YHAT5QpxV8BC2BsFUtk/nKsS3TLcsNyiljtDol6rbZP6YtddBFPGUPYw0r5P0Bz Klb5zmK9vmpGICYwVkKbV8kI/C6v5c/ydbCca9MXVMqMZdJIATFL1kJmcvUyvoZ2ZbWBMPK9EyFW p0t6HVQln1JsS6FzrjVHk3IJk9mmBzNsVWY0SEwYTMbjMfRbbRKGUGmQBi4glymDj9Zonn6tUMya waVETbg3DpvCiGqewJypDU8YPg08OINNZ6iJNsJQJovHp/GmTpqanJllkxdbumH4OD3WbF0Qc29O WmG40AaVp66TCQapUozKSDBl6KaMuahjFkcRizpiZfHo16J1gSaHgS58oLoKVLtAP16OGsCoyjia f1PCF28e3VnFgOvKQ4omUUDRv5QtuWD4xZJt0T1Fc4ZKrUHbZA1Ue6NeSfJSc2/oPc9trStHicXe M6D536zhT60ZdRwspcqpgQJBWOquFLfmySg3NCoo93W8KxhsaGYZbLlZY/65aQCKO0gXgCZocc01 pDKx6I9B73Wi+IJ5PzWroA7CQOulMQdySDkStaf9BzQDhVSYq51HqnBQ6ZlyLtcli0EeHNc85xlS vXM8egfhTsjtfg+arIDGbhGtlYgamrDYgdUOmop/V4cpLfBKc1xO3UbyVHGxtGiacrenZHlPBTWo 0QXWFjqTcWzG7Rppd2Tx5RKTj1u4eFpUB/E8VOXyiFWWI4dlgeQSC+cMqSmt0uysOkPPF+erc3HI lW7UEfqm3q45FlFZ+ArlJpEZrhRMUYMZcxnGWkcXtWWaVDg3El0X0tBFtisjLA945Sg742kjjOZz X/qPsKZ1iXMMITG+03yxYTa8Uwu2phsurSrrqlrWLLEKb40vUD4UwO5pXmTMGxOHnQwJZsw6pjBW 3FB3u8FvvDVaNvo3ec+4uDsgH1O2wktMnLoy99OO88H3wA3L67vEfz6ZsLhr4UXlCjbS0maZI823 o0jKBqtq/cQ1zNWGu472xnB9HAe/BOW0+JzJMoxCgjdAu9sinUHkx8vR5QyivhsO95jPm1bbrYj0 2keYPo9HkM9zs92JSKf91M3BS9yM2mTQO8IkDq6Jt6NbaO4Tm1ZtfZg8Ddh8sK1G8LrDfTa8eFab YSxWqN1eok7nbVcVVN/BlVSY64fJOL56RPW8lca1DwpDqVcrN95ryHGkpZnG2wCFA/XUGlcWFxHp hoOBx6vnerxcUGoyUt+Z1fz8n+PzHzO6YhD+WVdTj/RgWxH76TqIkNCw2w1JJ4I86CJv+49ZMMf9 /wD+tkkODWVuZHN0cmVhbQ1lbmRvYmoNNyAwIG9iag08PC9PUE0gMS9UeXBlL0V4dEdTdGF0ZT4+ DWVuZG9iag0xMiAwIG9iag08PC9SNyA3IDAgUj4+DWVuZG9iag0xMyAwIG9iag08PC9SOSA5IDAg Uj4+DWVuZG9iag0xNSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE4NTk+PnN0 cmVhbQ0KeJy9ml1z0zgUhu/zK85wwzJDVMvf3rsCZYeZwnZpuNrZC8dWEoFtGVlum0v45XuOnaRK 6bIUmSaUtI796tWjo6MjJ5/BYxw8eu5ei3p28j6BdTfjQE+9nkVRDKGHP2mYQhJlKWgxW83o7OH9 zzM+KMDupajhxQJVMshYBovVbFTmkOC/JGDch0U9+w2eLT7Ozhazv2bjZQ9Vijnzw0HpTWOEboSZ v9L5yoD9eHNxFc/VldDz1PM5V8US7jxO+3XfGfA9npChIGJxgF1cnKNDgGulP8lmDaUq+lo0poO8 g+P2Ogaw2AioJMqoFRS91njm7VnPns44Z2nq8b3qeB1IVDOAbx8oPIwnj2PmhQgjYMnIdGNM+/vJ SZmb3Oi8+CQ0k8KsmNLrk3Jo9GRn78SBfuhzFsZ2u4zU5kHk0fG5j8djD98ph97ewQW5FjCYsahe 5ZUsYaU05FDnN7Lua2LZyRuoVWM2HTVwh2LelHjuFpYC+ha7LMrnGJltlRf0G0qpZacqgcdhuQVl NkLb42hQYIvwScrIWuAwvjE0JrLJ21arVkvUBKOg78S3neiwrZVAlIXYidR4Ol5TUdN4VSHp6o2o d02bTd7QZU8oprARwDbWWnQde4ICB2Zj3xYbeTfO4FpWFYibViI/1cBrsdR9rrfA0+cUvikjHy9V u9VyvTHwThl58HZ7+EvxdQh2eHO2eA0LTcFPJNEjtEJ3qkECJSKSK4nk0DC+820I70FC3puN0jQJ TtHe0Aah6YS+EiX7j54drsbfu375URSGkP38VPCjiPEQojBhQZYNMfni5QUkqUOY+5nHkvRI80Dq Ft7TDs7FOq+GGeDzjC6ZH2CNM+BCqyvZSUL7XlS5oYyC3R1EXu0j8p4I//LzQLJwpB4hfkxodnYw ZFuI28xQYZw0nZjLZqUceAVeyuKjBr9SmIvVioYXI5bA0TzFmT3SChK84C6stl+iIYSEV2AKMHa8 YJRdVCLH+ajFlRTXJIl/lN9hWGC6WfVVtX2+i+UtlKIrtMS0sVW93ocsjSyGrdGyMMNIXUuzoSMt ut+nCfWNnZeqFPhf3apmSCvihhIv5ZyVVvXx6VAj+J2UbIqqx0svZd1W41R7cfkKzsehAIM65Hdv tSSSl2KwBiEbEO48IdRxFg9haMcadYmSbUuHStSgLqkeM0mudd6YLbawUzlqhyTv93V3Pi/yZUVe kADmKhqAUe7n4zZNWcpxtoVeyNIgHcKIOwQlzQMqWWw9NqxJWpX9yBPYA59wXLs8rIdh5rMkPDIU uJVCASpm0Sjl5m1P31b0J6Bv61G5JHQtG1Wp9fbB7KehbxuKHOmnnHnJgX4wJIW67pt9ErvEqZNr qTClYB1Aa8fZGWA5yjiHP1++wLnVfBqrog8dTjd8xPfkMfcpFcQZ49loNJxiUC09Wv6HTEnl0zi1 xrKLcgl1sqY8iflz1+9fM6iWodhxUCNc9PmkU8pSdIm4A31LD/Gd51ssPrGuwGRMmx6gTc+O9pwG ABeT4dAZFaNYVB7Td4GfxuzYDvcc4YcRC4MDfCd33MMi7kgRC0UHexzr7Mg/EkR8b3dblgUuq10t O1p/4UMjsdx+u/jw9XvJzJ28ZcWZfBCwKEqmJG8pRsxlLdmTtwQR32ud1wJeK427r4ct5BOQt6xw l6Ai8rinjhOLvBt77jNc3WxRhO8W+KHP/GNJZHjIJqdl3ppxvRtS0a9Gb9ngLlFF6D3ctGWTBr2l GDGX6m4f9JYgJXusGObnqsBy/7Qs6R6C6H4s+Ccgb1nhjoWrnyUs41OStxUxLbqTtwWpyBlxY8Jv W1ptHzPd2Fa4S9eIPCp6wcTpxhZF+FOkG1vyHvzzOa2yRd59N/dPgN6y4Yw+QTLR1OgtUULvtNDu 0FuS96N/21fmf+BPgN6y4Yw+xp4lk+YbSzFiLnX9Pt9YgojvEtdUURH3096oQjUrue71uM7+8nxj WeGOm2Q/8lgw6RprK0bMZbu3J28JEvl+SXXNpdF9YXrcnD9mprescMedrB9g727X2Al2sraii7n9 TtbWo5LyJq/bSoy72Av6EMtAgcUljkE5bmFz+xbKsLmtsCCCqeBbdpzh+zGLg0nD3lKMp9jJ2oJ0 62okTbeB3yrcwCqNr6V4nLC3rIyfxjqQ5xRdk5K3FOMpdrK24DH5d7SdrUbwj0PessIzR/I4LdNk 0oRjKbqExSHhWHqU6UXRa2m29CFGJ0sxLq/d42V7y47veBuBZx7LsnhC+Laiy6epe/i2Hn0Qc/ru 9OfATwPftuM73kjgSYYL0qTwLUWXaXmAb+kNn1M0RsslVpb6B+8fTAzfsuMMP06YH0wK31J0urE6 rh+2HIPT4lOjritRrsX4fZTHRm+5cUZP33rYDeOFMLhNLPrngGVbXrH916zOhu+tdN9+a+XO17H+ vsjXAvx/Do6wJIDrna/3f8wSTpYSLH1iqGcRVsqHP6vZJZ7/LyeImCgNZW5kc3RyZWFtDWVuZG9i ag02MSAwIG9iag08PC9SNyA3IDAgUj4+DWVuZG9iag02MiAwIG9iag08PC9SOSA5IDAgUj4+DWVu ZG9iag02NCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE2Nzk+PnN0cmVhbQ0K eJy9WU1z2zYQvetX7PiSZsZGSYoiqfQky05HM06a2prmkMkBIiGLDUUqACjZx/SXdxcERchJJ3HI qeTEtgg+vH37CfozeMwHj972e7od/Xobw70a+UBveT+aTCIIPfyXhAnEk2kCUozWI1ptrn8e+QYB 7Ld0C5dLRJnClE1huR41yD7E+BWPmR/Acjv6BV4u/x5dL0d/jprbnosU+SwIDdKi1EKWQl9cSb7W 4L4W7/bRRbUX8iLxAt+v0hU8ec3q+1ppCDw/JkLjCYvGaOLyBhkCvHzRUXyesUnCEn86hThAREPT 93tY7Hseix0wBrdiLaQoU6EA2LPfp+o/z7QwiVjicAnGPV3pj1lsg4JePahZmTpA32e9ZA9CFkYu IEr3tpJbrvO9cH3wP4neEemtuuezJBxS9Q4QVQ8GUL0DRO0W5frndB9A9Y5IEPZTPUrws6hVvQez tr44gLPdTpRZ/gCzPtqHCQsCFxYVnG94eS9uqvvnlJr+ujskgqin7nHCvGRI3TvAo+6XA+jewR51 V/BWiExkUJXAQVVrfeBSQCYxFSRgY2O+z0FXtPtFHLOA+F1gDiaJ58MyswnuvFYirbYCwb71agAv /phftlsM5s8oYrZ4JT3dOQnZOBjSnR3g0Z3zAdzZwaKAV0Ll9yXMq1LlmZBYy/Cn76XUALJ3JMZe T93DgIXj6YBdw0Wc9+vVfsImwQkgqveX2ORpIWBx9dwxaQDhHSq9lR97bDIZVHkHcd6vX1vlHUCU 71YUOV/lRa4f8efPdS7FVpT6B8bVAZR3qPRWHq2L4kGVdxDnrM8c1yrvAKJ8b+pC5zsM+pxORmv+ o/PpIMo7VMZ90pmU9yIWTwdV3kGcsz6zXKu8A0jKz+YwyzIplILfRWlr/I9UngGUd6iM+6QzKj+Z hmzqTwdssC7iscNe9e+wLi6dEq6vr+0EA2/QC5zGp6XkpdrmWuMMlZdAk822ysSA2rssemufjJnX 9dhZrTeVVC/auHr+eX8A8xxKjXkXoT/BCxcBnkcjLzBTZq9sj9iUnrtg0WZBV8kWpZZVVqeURWbb iVkWnm6MKi03uYKsSmtqMZAJlcp8hVLpjQDduF8pSsVqbR4KwY6nnwQ2I/zIxMydzmiD49TcPP+x kUQRUwp9qOQnBV8El0WOY/GnsjrgRK7sqt0/zPLIy31V7JvdX74wQAV/FDIv74/7WzjzUYnD+46u ENuTCMZyYu6EL4dcbywWL+Hmxl6gPefVdocHggxRQNZlSZhmD3rwZTCv8T96QtYBnlssuoB9QkFZ UU7k6zxtSpZsOrYBJQileZlxmalXDXajxTovWwszXJ3q4rHZ1RFOV1VD/wlxvO/oxBvrRHSWkFs4 s4qeETO8q1U8E7hhTvzQ7JkiyR7xGj29C86t2k88uBIbvs+rWtLiDvfozQ36byUEGlwVRVMfyNxj KJE7rIUYIu3hiDY04YmL3cDTrQV2I1RFcax2XCpmURal0oJn52hUujmuWwuu68YTaYW1kWxENqtH PKStC35veVmMN7zEwtbwax+LoM8uuRImBrm2N6Ff+RZxztARM8yiPccaeNZSeb/BFkXecq/STQpD hfwua2FMOrLTGBcFrlJ03GxApNhhWTKDneOpJ3Yhq9eVBPHAtziXnNPKZkUr7XJmLKh2pmVSUtSa Dklme1REiwdNHuSw4ipPkaHc56kwTMmFnTYnthgVcA3uf1ej3JzimHY6hwMaTwbZu49Lz/FDC1VT seVweXcHSKXUmB1oGiYGL0ie9frV6dc3QnrRhNMag6s6kF3GkIMg7C5aurhE2K04qmPi7OuYRhP/ I3vc0mIrRyOpMJXOyUob5wrDA7a8xFEFK9nXW6FA3wB4n7/OUUGT0+jiA1ZTqfO0Ljj5OBU7c7I1 odi65TvMCJGivSmdJBSK0JYtCzHL+K7xHtwQwG9N8h2L29PraNeuLc6wwZwTUrVlr+puWyzaiw3h NgjbZkH0josp2W1zySwWKvnh5/9O4GMhmSQQBBGLxrHpe7ev574X9jqQ4Ynfj05AP6KgGRLtMUFP JywOnzINwqjPGB2MY3o2ccLUukHlunbccNozTQSZicCPIkJ4+rzLddpXgUE9uihqpaWpEiuByfmK 0NBEr/3zzzuhsbClNVZqDbxg7fOx64cdtjoFr8VK1lw+gp+cUwdKnjxH+/AOazSMP7axgRbCwUp0 +/so9kkdnHv8GLajSTDpfi1Gd7j+X/DDbzoNZW5kc3RyZWFtDWVuZG9iag05MyAwIG9iag08PC9S NyA3IDAgUj4+DWVuZG9iag05NCAwIG9iag08PC9SOSA5IDAgUj4+DWVuZG9iag05NiAwIG9iag08 PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEwODI+PnN0cmVhbQ0KeJy9Vltv4kYUfvevOMpL uypMbcxV+0QI6UYirRuQqmoVVYM9wHRtDzseh9KmD8kv7zljc3WIcqnWBiFmznzn/p35Ci7zwKW3 /A0T58ebDswzxwN69dxptdrQdPHbbXah0+p1QQtn5pC03f/qeBYByp8wgfMJovSgx3owmTkFsgcd /HR85jVgkjjfw4fJn85w4vzqFMdei9T2WKNpka5SI3QqTP1C85mB/ecquGvX1Z3Q9a7b8DwVTuHo 6efzPDPQcL0OGeS3WNtHFycjtPD4+aH+wvfDd47nsW7X9Z4Guq+skKGVRbhHoPeZcVr30Cxs1KAf 8aXhRqoURnwt9DfQXTyYEuZ58Ju8lHDdH3wjv6u6g0+//6+6j2roQaaAsQY+xUKEmZznWtSAF7qX Ws1kLEBm2FVLLTKBxRx9xAO4gp88E1G1mnicKZgpDb8MzjcQ7BHlGj7rtN3GRq4PidKCtOOPkSGP gacRRMJwPBHBnRQrUDOIbd4zw8MvMp3XSKiqVFKbzXgoMpgKsxKicOsqKI8TchlWMssuZjVyQsYx 9pjmxvpCWFMRqxUDmOwDqKUgmQywEo1akmGkwBbqZL0UEGhlVKjiEuRCZqGWiUyL4n0YBhePZeSO tgp8XI8ErU/RdUzK1XA4LKHGprDdryMRND5avVt/t+7aJiU3UROhkdRoNPhj3A9KnIeRTL+UbTRQ qdEqhrHQdxJR+iGGLssgUIj8yKqF8pZaO0EzbyWYffh/9gX/fUmLFQ+dK6OC5yrbuxJ5q26Ac5Wn EdfrI4QDrylHlZ37J72uRmu3cz26Hp46t7UV2atwd2MrytPBcvGEPuK8cT6N90n30M5nolVIUDGG CwahUjpixxhjNB3/lQWYnbKeCLDM1mGkXx+t4JloHZwjzt1OG9oJtuF6riZfQr3NHf9dpcCjSFoO MMr2a8EAS7uEBPNUk9uoUnLyDNmw2mRnJ0fnmT26298Q1hEfbciCCOsMpCEuWSltFpAg/aMAqkVj uYHxzxiRzyi/vSi97srl+8hpbWi0XGaJBm9LN5cDz2023nH78vES12segN5uZhWFOeQaWxPx6z5W L0rWtwGMrOPF2EA+soEySO2MxI+G1ye1Enhzq5E4DrGErzFHkKmEkriM1ZqChZWfZjKiwYFxy2Ah 4iVFT2GGE/m3qGaPlOOgwemZ8JSGGVaBzlMbc2sUXRfLvqvTIHsQbM6gHOIhzwSeKDO4wHST+G4i 7vq1LlI+pSHLLe+DVrmxAxHHNiKVCAfmkym25jaDNRNhrqVZlwPsPYXQbjC8w3udHprX2RRC03e9 dxRC0/Wx3Q5Abx9ZkXksPNyqt3qsadMeCIO3mzCvAfYFj9mmu4d/LSVuwKWY6hwpHbxujW7j3SNu +RzwuYDm7dbcNmvDqjT65ien45G9nTZDQxKnhcW5/Rs7Y5T/DzK7/swNZW5kc3RyZWFtDWVuZG9i ag0xMDEgMCBvYmoNPDwvUjcgNyAwIFI+Pg1lbmRvYmoNMTAyIDAgb2JqDTw8L1I5IDkgMCBSPj4N ZW5kb2JqDTEwNCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE4Mjk+PnN0cmVh bQ0KeJylWE1z27gSvOtXTOXit1USI1Jf1OYk2/Kuq+zYa8tv69VWDhAJSdhQpAKAtnVMfvn2ACT1 Yb/DRnZcUiiwMZju6RnqG3WDkLr8W70m69bHhxEtTSsk/tXL1mAwpH4Xf3E/ptFgHJOWrUWLV7vP v7VCh0DVS7Km8xlQxjQOxjRbtDxySCP8G/WCMKLZuvUf+mX2d2s6a/3R8rf9W6RhGER9h3SdW6lz aTuXWiws7f9c3z8PO8Wz1J24G4Vhkczp6GdSLktjKeqGIw6oNwiGPRxxdoMIiWYrqSUJ/CWl1jK3 2ZbygsxGJmqhEmFVkRtaFJpWIk95I5pL+yJlTncX55Sp/Kv55awVhkEcd8Ma1ag8kWRX0hxjV8Ay JWHo5uaiE3oM+q4CGQCJb0+KPJcJb51JY34EOES+bQIwtOYDzSVtpEZkawab4xPekC6FFXQDyArr RmylZoTMFG16WanMrUNQyvBJZZ7o7Yb3IrHZZBzZXGbFiwNDzl8KXUNlDEUlDrckZDsIw02bwmF3 HET0F9Y0XP871UQguhvTcBTzC/OtpJQe9wQJ9aJu0D+A/UJpIQ1tdPGsUklGghZlt7xHJ+qPeXWn ITL1REr9rBLpFeDyU0vCFsgEQAokStgqpYnISQqjQDToSUEFgx+Lo9qXnJo4zUJpelF2VZSWVP5c fOUMX99jISsi6gWjYTeqb/9T0lwrucAeKre6SEsvNXqWK5WUmdDQz3pd5lWoZBKZC60KA/Y5yOvp dPpWsp7QTiNqp1ucMA24SKAVxUnIoAxWyJYEpdIkWnnpFItKI6laLLBJzjlT+WEdEap4bdpNAfkt XR1B2hWAvyg+zj8uP+b0HR+4wxmxlgfg8nWjURwIRlXAuyC0/FYqLdcoOUeUKRb2hc+j1pvMXfbx 8KVMGetBfl7BfUh1ENMg7gXd3thpbbLZyDxVr3R+goT7wzgYH+IGP5xce+MRf9JptJHWbgaNJyUf kdOWs5WAfquFRc6YAqzYCI1sWnaSYuGr2gvOKfIdxe4TZbxspyx42MOv9CyyUjLQ7eyp7fCxp3Wp x8Ur3qqi5QpeJaxfo8usqip2MLc9m/xCQMzXKe5mk9TGL17LBOanzLoC4tsmacr80y2qkm9nofD1 R3ArO+ybzZJJaYsOglqoZakd87XRzhqHhpgSZSSKqlEbjsrd5fC8pxgdkzaiAZKLJuvYfLi6iPrD /ikS6cEl4wPQL4GXCMQTvZXIBJUNk3oVXArtqkchvVokyD+KQSXHskAODBSkliv7/xSCTubztCeV 28mFS63KstI4BTrjSBWqFs3NcebRNyL5Km3d/MTGlhprHZ7YR2Rj+oSQvRt5/5lXDrByhs7kVjg/ z1McB3E4HlN/EAW9ge8djx6bhidwFfYjZmQf1lM1wqTDyXzDFUqpBE3Mx6ZQXFLcYeauxAx6mPZz RO2LqC2RcRtZrjghW07/O2Tlha0t0uWu0Ck3ogITBoYIQdzymZ4jt0QQu2nrwK25awR1NVWBurEH UWIfb9i4nUliHgsMLh4T80iyqrBAKZzJVj0M4ewx//2utHxgB3HB/vJqGVHQ+eMjD0hXShvbrpB4 0W5aejOvYazBwevWhM9xblWUzorYBR/Qh6FyjzVJAWJhDa6btJEsKtgLXnBpL8IzQzMF0zhY7lfX XWmFAkKe/RS1hjGJJdJiymTFHHLMZ+eYHRJ6FAuJ8eDWLznDaOj1/fT4o4Iq/NxwdlFUqQRvE+5w ubPE4xunTz+aW/6c/HdaofA5meeDmM8+cR0VeeqtF+lo5pXGhh27FQgGVd5Ob9vV1MtpXkvBIxIP RlWKQC48QKErpo63LKs+qWdLENPxqan3+wR2zZpXijRVLBeR7YIRzJ/1AgJ6BWNgZG6CfW/C8MTV F70UlM/8RqtnkWx383cCtzeokszZli38nFY1lIVrZKzfXUremdSuq3ZbzjFkrACTKctswd3atBYY 6etevTOz6lzN1m8HNcSiyzxvrPnIdn+tznBCnxr3/TGiXhwMwpF/BOtcBn/LIl921OYFNtFpps1O 9ZCAgDqm1M9ye8rQPhjy4+P+zr6d/eRR8BwZhTjOwGOd8jwxGgZjfnDcx2PTkzy+FFmx9A8SA7eq /+5o9hWWjFSlhj7cPj3OPrT9K32+c+8fpn88XT9ML/n94++Tm5vmjV/xjpXj47unm+oOfrfDuri7 vZ1+vvRwt5P/4YVr4MPd/ez67vPk5oNvm03pNHMjOzdEBi0qHskwGdmqzew33BPGoGGMp8ZREPWG 9RCEpIbjU6agcBAMogNUFMDPy6YfjYL+cZCnxuiH+X3QelKrhvn+CKLH3MGKuZcWVpOUbcLMKbKg /jZj+rpB2zZ0Jee6hOtSGLf5u4346FuPv+7RAWjwpQl4GAzppQr74bfWKOSIoelwSOvWIBrs/pu1 HrH+Hz08DAYNZW5kc3RyZWFtDWVuZG9iag0xMTUgMCBvYmoNPDwvUjcgNyAwIFI+Pg1lbmRvYmoN MTE2IDAgb2JqDTw8L1I5IDkgMCBSPj4NZW5kb2JqDTExOCAwIG9iag08PC9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoIDEzNDU+PnN0cmVhbQ0KeJytVk1z2zYQvfNX7OSiZsZiRFmfzsmOndQzSepa SjudTA4QCcqISYAGQMnKLfnlfQBBfTntTJrK1kgUFg+7b9/u4oF6cUI99xc+0zJ6cTumpYkScn96 GQ2HIxr08J4MJjQeTiekeZRHztqvP0SJR6DwkZZ0MQfKlKbxlOZ51CAnNMb/+DRO+jQvo1/o+fxz dDWPfo+abT+KNEri/sAjXUvLteS2e6lZbmn/dX2zGnXViuvupNdPEpUu6Oh1Xi9rY6nfS8bOodNh PDpFiPO38JDodvbhjG4Vy2gmMk4fpLAx9lCqyqrGqcQfalFVPKO1sHfELBWcAU5JTtdXV1fPO1GS xJNJL2kR4UecJCSczzlLOamKa2aBICT99uqCSpVxnDG/E4YyngscKZQkVlWF4IasAqYDst5ApXXJ pXdKOm+pZBtacDgoJU8drFUwhTeBpBNiMgtWAekohizzJ7ICzxq/Ku2/FNwYAsBa6fud+4Z0LaWQ y4B1fbNz5d35X84VJvErSHR8xTDrn8bjUa/fEoKYzwiLxhHsPIXrlj+Cw5wYLZgRKRmuVwJcGW7p 68Vs9u0MOXBEwegpxQ2jjjRQur4TKYKi2fycQJhUFg8lLxdInj8BcJ6STHG/HAKprSjElyaLNLNZ mzhWw0dpRepPAJvGqFSEB1CVMcsCBALJERSMWSHs5juxN5hdUOD3hiM8I54C+N9muHEkbIBa++AK chPmafx5wZZLJG6xoWeZskkCwPPUipWT2bNWWyVn0pztw3LK4cRD7b0NMYCiQP7LYPUZp/cG3vSO FXk3LVR672TSsm5eej6/rp1/a2YC0r1Ua0mcachYg7ZvAa/yUAc5cyoYouLf/PoFAgCWewsZgHze EZLjc9s/frgTDZEKVLpvIKc/04pG8dQ1jH08UPxKlWUtg0polnLJtFAGcuSa75Pua/6tkPeGGFY+ GJ45b7pDDzug7lYymY9+fvd0+/umKhuEGgie0hWH9OuCadetds6YE4d/JBlmqPNnW+Tnaeo+kIg/ thBXciW0kk6JphMHN24OkUN+zDZY5wVyaTjxve2QzYqjMXCIm5tUi0XT/AxHn2ZFQGl1b1BipZLL UMhrjumTc4+LbyxzX5Xvt5rjYFtsqK4yp/QA9PG/y2Q6aKgfDPvx6XDSDJvuZVxxq+F53RXWdLfh djV/MD+hpP54gh/2z/qE2BdojXuUukrQrmFr7tnxWun3xtjZ3ea0UYpjHykCs673F4VYujYy1yj7 SmkblLkxlpcmPvD7h4tpkIzicdI4Pfgfimkfz80TU2GWOUVarbI6bXqbU0A7MJ0GmoL41+K5bnrL cf04BFBdFOj/kGTbgrZTD5QtMZeY/E7lZDBKnep2pcCbQcoZ9KoApP2zy+Ph8HgRFLo3QqjSCuHV kBfivtCC58Xm5B+dRikZtxiAclUUao1h7GDQUC0uDGdPp45qyheNwtHo3ZTNLMU47KxFkaVMZx03 Ga8v6auIeXzSmC2EH8vNiUdE4NVswGxxcxoZSb599/D36iCYC0Aj8lyz0t1vnD5LYXcF3Ow4pK6t gSObPSIl59nRMpep3lQtzStxsP4aQ5OeTMs2EqvrlmRH3Y5ouGwYxMEf0zuvkkywJSIhURS4V7qb HYrW3xdRwMY3ySPiFujerhnCeHvzai8bMttdGA9vh5w6l7hqdIA3GMfDZDr1eDehNSFhkFsRt9fc q8cKdBl6zRe6ZnpDyeTEXXonR9fhjzcumtGntmmO4hGtQyXfvonGiStilGkyojIa9oe7xyKawf5v mjl2yw1lbmRzdHJlYW0NZW5kb2JqDTEyNCAwIG9iag08PC9SNyA3IDAgUj4+DWVuZG9iag0xMjUg MCBvYmoNPDwvUjkgOSAwIFI+Pg1lbmRvYmoNMTI3IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29k ZS9MZW5ndGggMTMyMD4+c3RyZWFtDQp4nMVXXW/bNhR916+48EtWwNIsOZbkrRjgpO4aIGm9xNgw FH2gJdrmKpEOSSUxsBfnl++SohXZcZukLTA7gW3q6txzP3h5dA29IISeebvPrPR+vkxgobwQzFsu vMEghuMe/qfHKSSDYQqSenPPWNvr115oEcB9ZCWcTBFlCMNgCNO5VyOHkOBf0g/CCKal9xO8mv7j jafeH15920uR4jCIji3SGddUcqr9N5LMNbRfZ5Ob2Bc3VPppLwpDkc1g7zWqFpXSEPXCxBDqD4K4 jyFOz5EhQEmVIguqICMcZhTxHpZUlS2BKNBL+rBYKZoD43CliaYFroKQr468MAzStBduYe3VeVXA KM+lMRpVWvings/ZopJEM8G7eCMIxJZtpwHAB7OGkAYHgwrCEErC8WJJuQbCc8gE11IUMJcE74MN Fxwx7tFsbWLQknBVMq1p3kX+DkqtaMbmrGZvQnLYSiMkkTl6fouMGJ8LWTqGxoxbH2LuYHBJtdKB 6ckqKZFZsW65mK0PuQAiqYMpmNI1FVxomuRl7RYep0EUQRzHQd1xo9WK8pzdwZvvaL2olwRxGzUw YH7Yj82y3/RPbuPAUk9H+y1n226y+xvNwgNmuBwZ/L3+Afj3EOjj5S+ZuTTjt9e+fcEJJdg3UP/y H+Fszd4QTbZG/m8tnB/Fx3qZSIGNekmvA3COXszndRtHOZzHcT3J55lxPcnHXsVtvmyFdSCuJ/m8 buE0Yf3f9RopJb4e1/Pq5XC+EteTfJ4Z17P4HDB4MZ9n4nyZT9QPkrgXNVt/Q+63g/OM44hXWlaZ riROXZHTBnEza8w+nJ7Yawi2d7xNcQgXjH9uW97izN45DM7G4zGeWLkzWsFmenEPPp6Yvccn28dv n9fD4zrQ/jAKhoOhHa6MUurc1g6/fXCH6TBId8A/meMJz3U8wXhuT08t9qNtgu0l3XrQhynC+E3Y 9ZzXTBeYrc6ogYp/gb+YrCXAKMvMB+byT7pkWVUQCWN+w6TgxlZ1ggMz/orxjJpj0h60TLVoLpH3 jFKOiFlR5a0y1aQNZ5OuyLXhjyjKIAn6YbpXlNrJ99SkH6TxDvinbpNMVwonDlB3mIbfqg/QNFty UYjF2vddZSIDtl+aKdYgE2VZcZbZO5UVSS0hA/QuWxK+oJhUfWvyqtYoP0oF5yIjhTE/UJ+Sosha iYJp00KSEkAJeivkZ+X7V/X+yVApX1fYBbbKMCFSQxg+NIYrz/noPVzQnFXltlNOnYLbXIxO7y3d yXKtmCFzTtYoCTeTd3/fu9u3zurgOr/WglTkD2uGHuDvuVWneilFtViKSsMNkUxUjQSkWW2+ocEi sDBTVlIUqSigNVO1wnTaDnKqMslmjWB0IJTIgiHD9vZZtXoXG5mL2927nWM4emsUqwOqy6OOujZ+ Q0asaK2NAbkrltvdYdUuvdMoQYHAydXVDvRuZHB0cX4xProPHo/VMw65yCpLsdXb3e0oxNSjgiV8 jVuRL7Cucyolfns8ATs4REfo7gYlft6xMr7zRb4zglVFevKG4WZXVHcwQY40waluvTbOzHx60M2Y VUNOm8GC3ZJXmSmucFdRr78XmjaynGiT6d3qrJqY66cYfIwqLf8xJzPcgh17GJimcTCM474gueGu 6VbZ70Vskpvgs9k2JRPcJ1iRqgsUH0+KYHtAje9WuA0UvKUzWRG5xmHQNY9h6d7R+HFiui35tJ1h qLPh1s2ay9/RlRkzSRyECZTeIBo8/Cy8K7T/DyyjtxQNZW5kc3RyZWFtDWVuZG9iag0xMzMgMCBv YmoNPDwvUjcgNyAwIFI+Pg1lbmRvYmoNMTM0IDAgb2JqDTw8L1I5IDkgMCBSPj4NZW5kb2JqDTEz NiAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE3NjA+PnN0cmVhbQ0KeJytV8ty 27gS3esreqc7VRItStbDmZXj2BNXxRNf21WpW6ksIBKUMCEBBgAta3byl89pEHrZvotURn5IFIGD 7tPdp5s/aJCkNOCf+J5VnZO7KS1cJyX+sYvOeDyh0wH+Zqczmo7PZmRlp+jw6nD/RycNCBTfsore PwDljM6SM3ooOi1ySlP8TkdJOqSHqvMf+u3hr87lQ+e/nXbbzyJN0mR4GpCutZdWS9//YEXh6fB1 ffs46ZtHafuzwTBNTTanF6/zZtE4T8NBOmWDRuNkMoKLD59gIfZrMjaXlryhXJZKS+El+aUk4WqZ eUdKe2vyJpM5zdeEU5I0pc8X73lHe9X7rdtJ02Q2G6Rb2JUEh0ULy2BS2FLh8iuW7ij5OXKHo2ky GoKZUTJtCVZSytaCug/3Br/A92g0TEaTQ/BvCdED01BJnePPk3J8QH+IuGBpf+dxHjzOjM44SDmt lF/So1yqrCmFxY2qarTKhFdGux6tltK2DK+UlaV0jkD79wj/gkenKsUggUbhyRT0Zbvr0/mftGmc 0gsSdPvxf1SKNSjmsKlChXCBbUZpSRIn85PFiX7u0bzxMENlS9JS5o7RM1PL1nK2bKkWS6rMXJXK r6kQmTc2YinN9jMdmlwmtbDKOLbr2E+aS7+SUgPlkS0MfMDsHgmdR6jtku09vkWFeoLpShdWOG+b zDdgK5d1adb4XpQGYNaI3CUR5ctSlZK6dRcMgohSehQL/cU5X6rvuCPgcI8W3QDf1Xi3shc3RIx9 8CpjIw835xe4ykHlLnQMgBOU92VcBNojxNHS3wOLBv+s4+OoEkqXaxJzA+o5VkfLkWrXfm9NbZxT cxwBimsL8lUm2xhVcxQoTGDj2b5gg9DwsRtQdxFHNC2wwRUOdCpvEw5uevkUskjQ+/v7dv/nqw83 hNwaJ6d/fPybaR2iCiaD4TYJuQwO6p6ztfVqn2qwbs74VY1T2XThqGqQYMK9Foedf7t8m8uleFSm sWzaUba2OdGELFhIHbwyOnp5fXl5SV+4DoJNoPHKmiogXt8SKAgSph4lh+7QBeYuVMuWrqLgSEWy RYlQMYhD8bP+SYsSCCEALDzje1/UlQrGXXKUIc4RKsA6yg1tXjvC34ye36LYkGvq2lgPcORxrHuu PuehyEGANiz2nOXhDLBuNGyqmbNPny5e87y/feB6ROZkdMcA+6u3ZCNm///dE30jxYlMjZNFU+JW hBJalOu/2yxE4hcsIZncq8SBgVuecBnza1slu4LH7hiFKP8HKr3NSYcGVAoOPlzlxCzl04H26KaS 1jSOsqXQC+m2jWqXGbRhQ9BY19uCjyt2Svvci1hodtq0XRNZyoVhQrFTIVeMz1klrXJILRd1txJr LhhVcciF3iZPYSxnqmJr2ZvgOHkrtKtgBNdzyIFaZN+lD7F4WZhvJBd6PBtewgIcWppVr5UnNvJg e9HoXIRTS5Qo0j4a+zqxoM5lwwFsrRGxnzFIFB7T5jt/mw5v5sqfQA/Ek6qaagcaVLPlQRQFTyFh wmirl2HrujyM/QuvDNHn3WGfD1Tu4qXKbWDY87twbxMHkdc+7fK9fo4f+sdi13oW+zvLOMCFUxnd S/vICn2/0wC8Njj4OYwQqIZKIoBtA2cj0NoqZFxQr8j/eykgzj06d85k6lDj8LqTPxrp/MmddDW4 gJqdN8DRPrLzxgImP1Z6bw/EbiBTuTrzON7wRwJzACt4QANpgTL8u/7wTEvUmdgDLOWTyFFfFVLk USAH0JBXYu1o8FQcvGiDQbqbdgmBR9u0srbS4QiZH9jiQq2JPLc8zBTFu+PfHubStoOulGsD212p Ms+Ezbt7mNbOXhAm6KdrexFqSFgcbgXKNyyJ5jrp902SrcgrpVEXiCyO28hkAV66N+v+R1PJ/nkG jXK3XAvd50jYcZL391AaQY19o0R5MpPzENX+XLBZLhNah2ENsYkrDgw5jmi/ZR516Pnb0JFgJQ8/ EAfoSRDeNn58Ej7usW54cItFVFvjTWbKf2HyHqanyXQ8DdPx3dXFZDgd/8LEPZzO8MUh5rfATPRr a7cLmoi227brMIAPptj5cv7mYVlmTWiZX4/s+jln08kkGZzicWmYzKY7Z09Hg/RXnIXJk+ER6Lck OJOOJnynvxO3fCtuDyhfhPs8Rw/yKAFW5nftjKvRV6AgTix4NC6UDhPzgWz13niU4EYVek9uID4s A/KJO8JuY2z0e9FqD2i7eXyaOJ0m4/TsLGDeSo/SzZoeoahEmWwfOC+fajyiOLqSc9twAaazHj9+ zl48mH69ZfjZt21igghaRXLv/uhMU+Z1OknSCVWd8XC8vyw791j/Dyb5mmgNZW5kc3RyZWFtDWVu ZG9iag0xNDIgMCBvYmoNPDwvUjcgNyAwIFI+Pg1lbmRvYmoNMTQzIDAgb2JqDTw8L1I5IDkgMCBS Pj4NZW5kb2JqDTE0NSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE1ODI+PnN0 cmVhbQ0KeJyVV01v2zgQvftXDHrpduEoVhJ/pDmlqZsG6LbZ2MVisdgDLVE2G0l0SMqOe0t++b4h pUj2BgusksCxRL55M/NmhnqgQRTTgH/qz6ToHd+NaWl7MfGPWfaGwxGdDfA3OZvQeHg+ISN7WY9X ++cPvdgjUP2RFPRhDpRzOo/OaZ71AnJMY/yOT6P4hOZF7xd6N//Rm857v/fCtv+LNIqjkzOPdFM6 aUrpjj4akTnqXje3m9GR3khzNBmcxLFOFnRwXVbLyjo6GcRjJnQ6jEancHH+BQz9ZZ1wSpeWnCZV ZtoUpN1KmvaBWOjKEe7RRuSVJJ2RU4WMYN6Rsu/e9uI4mkwGcRdVFSoXhkF5I68nYSmVuQJbmdJi R4Kuv85mZHfWyYKerkWucqn7dH076wO0Roqi6Jm0CRsSmecV44ZNoDBfKUuFtFYsJciQXjNpkRM8 aUFUsc5lIcvgErZdBodS4bw/W6OcKpd9EiXJx7U0SpYJWBq5UXIrO0gJIqJSaRCvlXCUVMYANt9R qSlTMk/JSctYtIK/lQWI61CMWqTLMsT5hRuc7KJjUyaFq4xslwBNlSDZ8awEc7hbiLKUhnNSes+y inf2SXGKyK5lgrg5z0a4PUotViF2tJBMOqt8AAm52nEuYR6526hEWtquVLLya+EAvNxINqgM6W2H 10qYdCvA3erKJC+iOUhzm1Doe6vN/XM/5LoF2kjY80saAla5SjShMBJhZiKJfhGWrUCwBmyBnrDc VYhSbvtUlYjy0mh8wmLlUq0R9AV0blciDTCZzhWrqiukRaXyFNkFBOCMLDQE5En0SbokesbSk9No PBqcNNWgiT4Z+VBBUTsyolzK9yH++IWiESiRoMAVVJP4MCF7t5//pFzspOnTVrnVqyUm8kKjsqE7 5AcQTa0pbheZQMwXCIGUJf12eQXNpOgW0MdnvZUbBlauoyKkVRu3ehEgC7hWCrS0T59XG7ms9cR1 2QLhfig/UbmVRlXt6Ony7mp626fpfHbTp09XV3WkLrghrIVxtdN7IAwOIFobjZQjuKxglSFCYr3O VdK0JsNtxepEeS51rJoe1Gw54G/bKkmE9dJE94zi+Ojb1Yf+q1SgyRcznDUrPetDYC9em2tnPRXW Z0c6grVWJ6kKdvecwfdW7Ikuiqpsnnm1HWDRfYmK4yC+GUbn159/vmnaoX+q2vt1yeJOqrJMcsNq oTKjC0+Jd2HPSXTm98CTN0P/n29iSPMfysgcyaAvl187QmqhRHB7b6GPJ7qyNCGhe8FmrxqS+875 6pCPsli7wBCusiYFIV6ytCxzmn73Rf195m0EHF9VLVa9Og0xgXEWhTNVceH7m59NrHD16PtJZoTF 08R33W6bxVAAFJop9MvahrR/Bod8MTxUcDkNmBghulxo9L+6Y3X5vG0IHS12R6bK5VsuuUTCTa8F ad8T30ZjNI7FG4xgDU9mlNNezTaGUUurkA1Mn2TFssl5T6raMnlJPdd1xzOUadDif2kA6f7Gbkn0 da9irBV5Dptpi7TGV0M5aHCH9RosQtQwHnlHIR5VURXNTlDCGaNsG9VB08+5oJSvi9PT9EPho9sR D+d+WhloC1MD9YJewvNN47DTIjX7upqsQcTx4nh5XF6EbpxLkfpDkGh4dkAaoqFkjcZzdAK4Fd8X +7b3Hw8HhQ9dN9yyPl+FSL40qU66wDSMas13l3ye0B0IsdEqZTp9+iGKwpdFe4vjbkTq5yXE4OUj whlCcyHoAzJ1J/o4u7uqq+nZY+iy+7jpdBDo/smKD6d5rpYsrDm6oF1jjgTRzvwZzYY8fT/IUZOP FokT87SXmefo1Wl6a/RKLVTTTvgMzGytxvEC49RPeI6h3AiQ4uTfTKfTbo9/fZ7y4THECPw8Kp8r FpIDvK5t+gAiPrvGEn/17bV1ZM8HVHNp3//bD1y/Es32OHOajLTSbGCGeVuRSUzQ/Vlw4fPC/F51 gwtRJPcSM8iudIUDafACMwvRCFm1rVEO8RivGg3IrXSgkFQ8pFGoUYM5fVwjY5Y+yYWpBE6F8aTP bxUT2r/+uuUj0/nfgPUvP6NoRNv6FejuGqb47Wc8iuIRFb3hybD9mvdmWP8Pt4k2AQ1lbmRzdHJl YW0NZW5kb2JqDTE0OCAwIG9iag08PC9SNyA3IDAgUj4+DWVuZG9iag0xNDkgMCBvYmoNPDwvUjkg OSAwIFI+Pg1lbmRvYmoNMTUxIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTc0 OD4+c3RyZWFtDQp4nKVYy3LbRhbd8ytuZaPJlIghwAfAmZXjKBNVxYnGYuKacnnRBBpkj/Cguxui mJ385XNud4OvMAuHlF0y8bjPc8897c80imIa8U/4ndeDf7xPaWUGMfGPXg2m0xlNRvibTTJKp/OM tByUA37a3f88iJ0FCr/ymr5bwMqc5tGcFuXAW44pxZ90HMUJLerB3+jbxf8Gd4vBfwb+ta+1NIuj ZOIs3TdW6kba4fdalJaOP/cPz7Nh+yz1MBslcdzmSzr7vOlWnbGUjOKUAxpPo9kYKS5+QoTu83c8 Y8muJVlVS2pL2mplVbO6dRc3ul2rJS60DSlD8mVTqVxZEpbWarWW+tubQRxHWTaKj4ziU4md1Py6 bfO2MvyvZ1XALhmpn1UuDdnWuRAbtinYxb/4gpGweTDk3fzBntCSzEbmqlSyINXQ/d3dHcWz0ZyK Nu9q2VgTwVAyjtLZKDnN+GfnTVTUanR75f8drPlI4KAp+F5Xhe/+9o4j/LOcO+MKWKiylBoBUL4W TSMrE/I6sVdzX5aSyraq2q0sLgTbEt38KKpyqIWVNySbvOUK/pOEcZUrtfzc4eqOtGhWkjuGHm2E FrUEZtCwi5FqiRhQNNT/4cf/3rpM7boztIbdprUILV+Tqjcit4S+syvFICxFftSbpbRbKf3t+4fQ IG9L0rs3b/2Vy2ndN/Qs1ypHNTTlbV13zb7wnWGUANBRHA9/efsdVap5Mg6O6Dn6fjEpY3WL1zZa PQsuCCqjtHQwoK2ya1zhDlrOWhQFvrGbiOjDWlUydDXYOvJtLDISugCopC9OjwPR7FBuuAT2UHIb kmFfB0tHTrkiwbFENqoJmDDS8riZkJ98UQYhi5DQwVQj0bISgC12jahV7sC1coDzhvbG6RV9bDeb 1vgmcz+athkebB1qv/c+RKwYgq2oKjdliJpnfkhbF1apXmAMORyMHPwVratM3mlGfbUjdk2mreWh H8o8mS8o94Ih6oAZzJSd5sypkCbXaumH2QT3eGzPoV/Hxkma4cIUQAGnOx59DDbTK5h5PE6i8ezE LHJ6wyMlnwUmvuyaPJAluxkm4HG8MNwDtujzPsl3T17ReAiuntHHkyC/MvX5KEozmsznUZb6IJWU 0pu/Jvkp1uip3U+3lFeCeW8aTbFjefw5F597OufnL+TuQplcn2mcjaOMV3cazXmrHWc6uSLTZDKO klO7h0xnURq5/OI04aeGe3rz+f3i4Czc4JtjasAoHjHLFiO4dmtMVKY9fY7Nn1Gcf5NeZQTS4om+ WauiAP02bYHd0G6kdvz5hWqxA5M/wy5Q2JQVbwjQRBNGjt8Ni8pibZhagQkBWHxnOYFA8ieJwHHp KFroj22rn4yb4J4qTbfEdWaqLrcdMvE5cQBYbMIYrGEH7wuGDhzgiQ6ssQ+2oKXbs1S3S1Upu+Pg HGdV0i31vwgX6KrxPInmU9/S6TUSbRbNWUgd20NtfuKVx0uhryaLs+P0mZn50h2DBLW4AvyczQwT FgCK8bsinyyLsng+P7GIfN6JF1V3NS2OkfJrAwH4+m7x65cwBv7V8zkATkBypegqS3jY7S7ohMv4 wlKIp6MRtbnFTXi+t4FCz+aAYWGgb+hZACxcz3PU9qXtdYMwJ0IxoO7jX4fRfOLzHCdxNEtTV6v3 P7xNJrNrOCcez6Lx5MTop35f+lz9pne1DLrCy0AtWUFJ6BS3eexaOFgNZ1MYRJznBCwBwJ2rTlAh 1B8xvCj15EG1alzv2R9cx0nWt+dCW14hlKwf9isqC+KOeH+BduPjuo6u4fIRCpqdGP10u9epp7UL Ikw1t+QKrKCGdh7k4xFbOS/lubIstVix5vRUzDA+Z9WSjPpdQhvrFWgAvWouVNONwnJnZTjn8FkC nRWnI9NLcspZoCLyvRZHM/KnAPStgqLr44qc9M6FkQc5zS/0973MhtqTVUHfPPrjRU/3TVcvpf6m x2HYSN8LK2gtRSFZySN1wAYEGCLpDQeTe9JXTQ69aS4ee36GVj0iCsOnEQzxhze/3dHjutWgE+hO Ae37EI6D9Prh8d3DFyTWYPP88XxQyEoB9MDnKes4hkBNHk+PfntJ3YfgDx3u7NJZ18McC9c/p8z+ wOlhFdQwzk+sgnFMgJta7U9SGKd+8QEIeIWPf1wxxC40jtpaYDp9rdnDTSiq1OYmOi/OfhH7Et0t Hu/pZiVbzPLNPvpeDPSDPJknHlxc+0kaTZm9uVIP0gLLeQf044RfRf259u5lg7OUoR/kUnccXZzd 8lxlp//X8PGBexKPPvUEMItmtA0j+/7fgzTmacXmhOqrB9NkevhaDR7x/P8Bi/LiKA1lbmRzdHJl YW0NZW5kb2JqDTE2MSAwIG9iag08PC9SNyA3IDAgUj4+DWVuZG9iag0xNjIgMCBvYmoNPDwvUjkg OSAwIFI+Pg1lbmRvYmoNMTY0IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggOTY5 Pj5zdHJlYW0NCnic5VfJcts4EL3zK7pqDjOpERGCFLe5ObY85aqkxrGZUyoHiAQljLkZgCyrai72 l8ynToObFiuVxXEuA8qmiOV1473uJnQLDqHgmKu/p6X1+iqEhbIomEsuLN8PYOrgXzSNIPTjCCS3 csvMbsdvLdoiQH9LS3iTIEoMMYkhya0OmUKIn9Aj1IWktH6DV8nf1iyx3lvdsm9FCihxpy3SRaW5 rLi2zyTLNey2i8u7wK7vuLQjx6W0Tudw0E5Wi5XS4Do0NA55Pgk83GLyFj0ESJYcZrcrcccKXmlI JKtUKfCLKDnUFZwuWVXxAoQCBmldpbzRoJdMQ8k2MOewUjx79atFKYkihw6wDKdXwArjN9PijoOu cRmHd8mHAYagbyCZRjs56M6wUgKNdtCIaqBUw1ORC54Z0DUvCtJ7nSSnk249q7IWuHdJVJAJyVPd I0heoA91pZaiIdg3avLN6gZBQDpxfeI+Q94oIhGN4x083NS5ZMj5eS1Lpg22TcNulu16JAwcnJi1 +7m4hIalN1wjyZIP1GmNFJlIAIwEQqn91+kbQ5nSSA+TGcyQfxNFBvtArh7OKIIcC71E6YoeB3Lj l5oYQQcIYBlrdEsqFGyDNoXqyTbx0EHsuzEqh5E0wpxsYd4amB6j4TJHGkS1GEB0bY+LECDjKpVi jpZQ6+9X1AtcgnkfOAEJkWejwzWGjXEH9SX0GQpPvZi40R50F7etsl4QmVF7lKETdtxismk4pknG 4aHtM8+PgJy0+W4YcO6j4OwMHpb8nmWYICVDvbBnckRdXFYblLVQHH4xsx5NGoxRta0EXQjmbQi2 5sbYMlq0tpGbHWHR2XUtb5RxCU08LQTKAKL8R4HG/Q4wkzaVDwTug+L7ZR6yzcfa59NODNXp/K9n is/Hq/NTdxpMPz1DcJfGxN8z0dep/Iucdsk+jXD9YUQMed7m9W4GiKLAqm6qX4Ylr6jXfxwp7k+a c6SPPhXtyDrcIHgwBR8CCCGCeLevV+hJ+93+wvW5hf9sv55xhUR1NWI7/nmLx3rH9lUWd/Lwp1k8 yTLJldobf0lWsV3XK5nyr7R4rHds/3NW+/NlmxB07397f2kd22K6P/6yrC45vnHkz7TYvhUOxn+4 xde7Dw3bFDXLgBAyjv9wHR9mLF2CFikeXOUNHlMbjFY8hWO5rzjMhSaPuDTEnwFDbb7kGqekqwmY M1gx+ja7b/DAq+Ccz+WKyQ3QaGJO/NG+wY+XbMGB0k/DuzQgAaz7l93Vn2jKvOfCgNAQSst3/e1j YV3j/P8AYBfguQ1lbmRzdHJlYW0NZW5kb2JqDTE3MCAwIG9iag08PC9SNyA3IDAgUj4+DWVuZG9i ag0xNzEgMCBvYmoNPDwvUjkgOSAwIFI+Pg1lbmRvYmoNMTczIDAgb2JqDTw8L0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggOTk1Pj5zdHJlYW0NCnicrVZNk6M2EL3zK/o22RqDETMYnJsz9iRT5d04 u+wplVTJ0LaJAbFCeMYpH/LT0xJge7xmK5NE/qBA3a+7Xz9JfAHXYeDqT3uNc2v4MYB1ZTHQH7m2 fH8E9y79wvsQAn8cgkRrZWlrM//FYgYB2kucww8RoYxh7IwhWlkNMoOAvsGdwzyIcus7eBf9Yc0i 6xercXsr0og53r1BeioUygKVPZV8peB8PC12I1vsUNqh6zEm4iVcjEm9risFnssCndCd74zuqMRo ThkCzNTGQMPTEzymmCXV9+9uLO/OCUau1xlNsVJpwVUqipPDJEkkVhVZM+aEocs6axpkA+8nD5Cc OfLG3vka/pOoZYxvQ64an37QtuuGTfbq31yvgi8pV7mn7pcEioVqEhcrE9WkF+1LhB3PagT3JRxN p1ci65bABnmCEniRQMn3meBJbznGvuTxlkqPBUVNi7RY98HogEdRvVmevj92vGBsVOU7nsP+g0aZ 6zrBK0QHzpvIy5bAOd+j1IFsb0we9pGvpOGrgDUWKHk2oELhhh89byDTrpBWkBYVSoUJLFE9I5Kc jAyaeaJHw1/Qq7n9QNZCbjWfxpQyjDYaroK6IjQlQEleVCshc9JUjkSz5DnSetP60zBdQIJLJRhD fCkxNsns2w5CpaiBpk/6gbEqpdilibFqoTrxdqk8CklYPC8zNKXTEnaY79zDiYK2wpzvoUSpcVus leTr/KhRHVgiryrMl9keBNmaiQpER9XzRlRIQC9pXuewMHprsaZccfhcpAqq9E/U5FQ5zzKKqzbc VA45iVL7vY8+U6BYrAuyPCNgN2qxrjD+s9ZEV6hu5U5kO4QsLbZ228Djijc0dR0xJQy6tdGuhUYJ NDGUmItdo5qEmkelXlmNk6Jfk8TGlhLqmGdNc4TYal08Lb5esZfFASdvyIVEnXSSamienQJ2DEyU Jg1LU89RDMRzg6KaNDQ1Za0aRmezWZeVac9Pp52A5luMuVinMc/sOVHZlvRAO4gU2bk9CTGp46bQ 8/2+MXFaLMqR9ryEahuYDCTSqUKKOWpJ66LVIJpt6NVRcmtfGbe9N2d3589vLzk/XCPhAPP5w+nG 7JTHu0WzT8JBe0WSp6Tjg6nx/0uR+Prr8py9GMPemZPnsKUeriV2HN8M0xl1SBfj928iX45hD8rh 4nnTElsJu3+7/2dI3dj1N6i/KcbncEXS0C+KfxknpLc6v5X6AhVtVnE9AIrJM6erYfZSpjQBj7iU tX6PYOFAv3aFr0v9dcHXCMz7rTvIR84Intvz9+OPVsD00RuMHBZAbvmef7rNrE9k/zfp2c16DWVu ZHN0cmVhbQ1lbmRvYmoNMTc3IDAgb2JqDTw8L1I3IDcgMCBSPj4NZW5kb2JqDTE3OCAwIG9iag08 PC9SOSA5IDAgUj4+DWVuZG9iag0xODAgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCAxMTY1Pj5zdHJlYW0NCnicxVbNbts4EL7rKQa+7BaNWNE/kry31HHaACmaJt5T0AMtjRxuZNEh 6aQGctl9kn3UHVKSIzsu0DQF1k7iWBx+8//N3EHEOETu3Xxmy+DdZQILE3Bwb70IRqMYhhH9psMU ktE4BY1BEThpf34XcI8AzUe2hPczQhnDmI1hVgQ1MoeEfpIB432YLYPf4c3sr2A6C74E9bWXIsWc 9Yce6ayyqCu04YkWhYXu6+ziPg7VPeowjfqcq2wOe6/j9WJtLPQjnjiDBiMWD8jF2TlZCDC7QbjE DCVBgKhymGlRmaW0pBGO81yjMVBILHMDsgJL4qSIcQ4nwgr4iCJH/ea3gHOWphFvYTNVWdHIG7FE uBflGg0I4x+doLGyElaqyit1z67UWmfY6iRIh7OreUp/XBzg7KzRfESpMivMLNlfbljtj9cFqnB3 GpzZZoU1WIt1fj5pMECaJzsbA7sQ/nLXnu+bw0isP2BJHPW7Ae65eFFgZYm618bGgFElGQ0ChuF8 YxFOtbNgcoPZLVzh3RqrDFnrQFffcS5Wto7eudiQByvUhdJLA4r+8wc+ZhrLWsoqKpTnWSq0WCyx sk+J+DT7k4L4uWp9N7gDaWCuJRZkdI4m03KOeWMfaTMuDYRDT7ZV/7L+4aMh4zHEUcyS8diX/lUD OmL8Fe3U52M22sFlDi3kw5Seh9uU5d6Xswo+T97DUuV45BsMViK7RWsgExXMEey2R3JA6bLi6qZ3 Np1Om+5w6HvBdv3SA0WipetmUZfs/kX4oq5q0SN3JMuSmpfij67qmli72itUWaoHWS2oJBdrjX/Q Wbe134YHXm9/6Fv3+du9onk80P3w2G0m+uZDtj27EJtSiRweO03w6Dz5hSZ2e07pXwx+0P82TfAx 1/+//wdIPZeOYuvmmaN9QKxJyz4ocFwhrO/nBVUhCWyesd4BtvDc13Ns+O5qPbf02TvAuAflGsps CrhbQzdbDo6+RVE/+lHEJ97pzCSXlT3A9DucvBSrlWufNjZ3yoSeL6nTdqeOT2eD+jeyBXsemh7l tShkBpNSGEOt2zul7oRSzLHs/eOZdRezt1dGjTd10fRqNQTrjic0LrTyMBqhUhbcwJOE1wwi8jRX 2doReTstPqxlLmh6uEzTfFkpS4dSlFuv6c5Kq3uZd3nl+ueZezysA9xPYxYN0nprCU+YRFuE1tw/ LEKJiG5JCfmrmHw4Zrtqvh45Rr1R68UNSOs868Qoc6OPyLxm+ySlu+E2dzXbO5pnOxa9eOnrjyLm 24/MGbHBK9xLU5ZyGlFdRCqEc1ndhucqoww2+xGaxqVafn+EuQov3aXSXxLNIkf9RBOsrr3QzTjp NstCUKVQ3BwttEWFByaYX5CWoqrqeedXhqelZAvlO5jgGklXnu2y8FRrP19q2xCRF2mS+BA1q8e/ I+fh9eXppD+Mh19fvTB0VewsDCkt+W20L9BSbLP1EVAQRMnavXv6bSXpAE5xrtdCb4CnR24LT3fX 8+sLsUDggydrYxbDQ2Pz5Ycg4c7cJGY8gWUwosrYfi2DK5L/D0HcXqkNZW5kc3RyZWFtDWVuZG9i ag0xODcgMCBvYmoNPDwvUjcgNyAwIFI+Pg1lbmRvYmoNMTg4IDAgb2JqDTw8L1I5IDkgMCBSPj4N ZW5kb2JqDTE5MCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEwNTI+PnN0cmVh bQ0KeJy1Vk1z2zYQvfNX7OSSZioiBMQP0LfElTuesRPHUaeHjA8QCUqsSUIhoDie6aX95V2ApETZ cjOxxqBtmvh4WCz2vd2vEBAKgX36d1Z7b68TWGqPgn3apRdFMYQB/vKQQxKlHFrpFZ6d7ca/etQh QP/Kang/R5QUUpLCvPA6ZAoJ/iRTQhnMa+8XeDP/y5vNvU9et+xnkWJKWOiQzhsj20Ya/7dWFAbG 7fzqW+yrb7L1ecAoVdkCHrR3m+VGG2ABTfYM+vmjsYjEzp6IhEecjXPCaZqO8Ahameet1BouxXpd NksL79Okm+izKUniAL2ao1cBzlQLm6bMBB5LaCjws95UxnVMwKxkK6HU0CjIVqJZSihaVdv+3aom tztQSjgPKMwvHO4WBERvTd1ZY7eohQFVwMzC41VAae+kEJnUE2tELouykfmb1w5pcQ9aZqZUjQbs eqbPaWyDNk44CbjzU3yE12kckyAco1kvwBEhQdOIJHuIyRH2YXySmO/Zh+7+coR9bErJdA/x+uyU hfExscsSRtJ4jHlDjmNVHIVkygZaEXrMFQcBScaAj3kFvg9/dCRwFGMprnjIrzkyZd2qTOYbZJKj V7/aqs2ORB201JYLaseMqmxu/QP0qsS9bMerLGt01pYLmSME3vWzmcJ4SDiGIuUkTtLhrkMeH+PO KYtJyPZAb0jnnc9q02by7Vy0SzzwxXBgn0WRXeJvT56PTj5chVpbYYAVqobVpEJVlbobVAbuVrJx /c6N3cpSH3Dn4G+Cbpuikk4xb/VDB1pwoI/iygegB1eif2EKIUQQQwIc0nFfr3iP26/+D54nV/7t /s7v13L0fSGbpVl13y+259Pt//bc/b/lwK69+J7buHrxPX/s2wdx+LGL9KKUVa5PcHwrNN24veKD MUid6nQs6+i1Jx5kZyRzM8dEfDTzwaZdID2x7T+oQ6hvRtvkw0FlRhr97wGU7U333j+IZ6UCS8pF aXbzz2ezGWCtNlg4sdKXiUZZVa3cXNXmsiXPV0PMKixmhCV8m1bY0WlljHg4r1wO5dPTmcXlD0wt RmWqsj42KHa1uMXKTEvrcjfhUR3mUowVxQMyiCnElI3YBdoWZiUF+lGTrmCU30W9riQWaw2cn17a CV2i6kJJZ2qNaeiDLJerhbJijTW1KbWsZWNsqtL2jWnOSrODH2rEogjYyQntcXLZKINAr0RV+Y1C 615tYxHgTyfurWh0XRpj/YZwePK1yG6lDbqmh8EAIZT6H0/fOyvx/M6IRmK9qUV7by3BpPzYGuwX cPnutMcZ0SBKSeicdiUN9mWbCWA4iooMBJ99X5c4AGdy0W7sHpRPbFnG93Xgy5XAkpqGN0OAxljF 3/Vxdf27l1AbUklMaAK1F7Fo91l5n3H+f/1fKSUNZW5kc3RyZWFtDWVuZG9iag0yMDAgMCBvYmoN PDwvUjcgNyAwIFI+Pg1lbmRvYmoNMjAxIDAgb2JqDTw8L1I5IDkgMCBSPj4NZW5kb2JqDTIwMyAw IG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEzMjk+PnN0cmVhbQ0KeJy1V9ty2zYQ fedX7OTFzVRkBYqiqORJsZ3UM2ns2uqTx5OBSFBCTQIKAfoy04/pp3YXIHWxnEkTt5RlDS842MvZ s8svMIwYDOnT/eZ18MvlBJYmYECfZhmMxykkQ/xmSQaT8TSDRgRlQE+7+18C5hCg+8lreDdHlClM oynMy8AjM5jg32QUsRjmdfATvJ7/GZzOg98Dv+x7kVIWxYlDOlNWNErY8KThpYXd4+ziLg31nWjC bBgzpvMFPDlm7bI1FuIhm5BBo3GUjtDF+Ue0EGC+EmB4LaDm67VUS3T9SysbUQtlAS9VUhiwGiw+ V0l1G5pcr0UBdVtZmXNjXx8FjEVZNmQ9JC+KRhiD63QJGhc2zkpYN9rqXFcGuIF7UVURmq/g5Ndj vDugHRCLAF7NquozXf58JRp0zbzyAJs9+y2gLIfxmzfsTTwArgqQCs6vLt4/hcJLny91a7+NNB6A EugdOrzwIRFFh6QV8J11v82O+7URPhGPokk6jPsQzFTnMs9vhYV7aVd7qwthrFTcSkLtLDi5mg8g 18pIurc8jCtGk7Jg5IMVQoHOrbBu2TW7wTuNbpcrf5reDEBi2hquTC2t9R5to3J2enoKyJeIsfD8 +J1z5jAk9yttBJSywWv2Xvcb8kbsQN3xqhUwfBjh4XLgV1UEVOq2ebLq8IYuOyS0nCL5hJ+Hx8/h Nz6HkTs8/vJl1pcbOzjvjPqx7b+yp3fymo1u9s+T7vz/3HP8ZM/0v9jzSa5m8AFJuIazE5i/OyG+ VkItkfqMxQuJua75I9UVSQwWALKybHQNZ7NPs7dIDmkOM7cBNHKpZEliRCUNTuyIuk4aS57jjZnn 7SuUlXNVPXq6CS9RhDWKe5Sco7g5i1xNyX8BijWMTyx62ntpoKoizjs3+PNl9Iw6zPu6JL3d0Qkn tM+KBBqKOtiVrNPhZ2KF+nrnbVrxO9QJjaq+Rj90U3OVC1QEg2HvHLjG301v+r4uN028N6OMRcPJ 1Heo8CTCvW6lMqFUFqudhxtPQimEQNtf0A9HLInGyd6WN5HrXqZ3rGMXbRLGyYgeDzcRKpzT4gFz 2iw4UY96Baa61oVAoCtdtT7QGC5iDsJiPBeVqA2YlW6rgoCfRNypdSHcgg2a63oYC5e46MfDjCMA amo0HmfO3XE0fkH8sizK2HS6h0huW4xFRWI/a6k3q1IuW2+5iyOb+GXhhsHFZmrYFAmcFTgsUHE2 Lnpc7fYWuXlMuuDWGPvWUIM7jKfth5GmRaNoTLDf2OiUxgucjLbbvO0I7soa/7CK8kYufMZ/PBsx w8ClEGdpNBz5+BmRU6D+Tijj15fvj+MkTW5eQvIkoYlvdw/M0ScN+YqrpfBNlOYTUQw8zXHYjA9p vmitr/6cFtQ0/aHqWn6LU8P9Cv/1vCX9oQi3RvTTxdXH2ez4mdRgMeSiaBvxnJ7hOqemGGHCoO9O 2rdJc7qkNCyFws1zqAVXZANq6KGcOZTtWl+EzhEUF6pgpAcyQK85dhM/h0RbWzoWHP2hJE2QvDpy Sn3kGspRb+kOPvr/FeJ2UBTLnf4x8PT0JMOVbqZyE3LFHxGvl39vUiEsl1VvVd91tnAYJ8LfI+sL JHoUDyN8l2HTYTSdTjYKLYUtwxS7QdguX8DThKEYxXvoN5EjJDEY74QTfHXpCXkhMGEmbweAZcpp 6PfH6cMa3zMMvBeLpuXNI7BsQG8p2f4ccn3BlwJwftkYnEYp3HdmX34IJowsnqQRm0AdjOPx9rQK rvD5fwCD/rZ2DWVuZHN0cmVhbQ1lbmRvYmoNMjEwIDAgb2JqDTw8L1I3IDcgMCBSPj4NZW5kb2Jq DTIxMSAwIG9iag08PC9SOSA5IDAgUj4+DWVuZG9iag0yMTMgMCBvYmoNPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCAxNDk4Pj5zdHJlYW0NCnicpVdNc9pIEL3rV/TNmwpSECAhNid/ZZcqV8Vr s5VDKodBaoHWkkaZkcBs+ZL88u2ekUDGTm0lDKYw0uhNf7x+3XyFoefDkF/tZ1w47+6msNKOD/xS KycIQpgM6R1NIpgGswgUOqnDu839r45vEKD9iAu4WBDKDGbeDBapY5F9mNLfdOz5I1gUzm/wZvGP c71w/nLsYz+LFPreaGKQ5mWNqsTavVIiraG/5reb0JUbVG40HPm+jJdwtM6bVaNrGA39KRs0Drxw TC4ubshCuqthm9VrEHkO1/XaHAOiTIDgPN+HjI9ORYyQJVjWWZqh0vDt85uzg2s/F6TJyPcmIUxH ZIjx7u7D5XQ68k+I1iQce8NJD/LL9wHDuePZiG+4vu9F0dCHRWKcJj977oBMyePWYffj5UXP6ULs 6NtG5huESmUbEe9AZfpBe4y/h21jCRtcZ3GOgMVSqIesXDHwx9K9kEIl8HeZ1bBdS00bVgq17kdX U0QZpGcGH46PFe/Pao15CrUEFBvUiZJVZeET0M1S49eG3GkhYqkU5qLOZMm+JaIW78nnTBtEhRsU ublKO0tNgVCYWO9qhOWOw9Midf7IbYmKMWgrmQrCBIHBl8hm1ErED5i8B41ootvGam+QPcaYpCFB HatsSYdmJfw6kUZB4PkTCIOJN7YVd15VWCbZI1yeQKaxP/GCZ7Am1+5oMubr7mjsTcPhqOPSPAVd iyUFab5P5rxXKoIiViIm1lupKAycxlSqwhTvKzwSScLsQA3yGS3zrHzQA+ICp0BhLIuC3CVgg5fn cttL3f6+5QGdfULNknh4YQThMPSms5nVJPfKy7BO3bAQpZtgKpq8drMs0afEPghZPfvnfPGe4f20 IAcRacPYYpE8nGBcFHmRT1b1ET2A+2bJmnlfqyauG4WGLP7U7j1my4Jqo1VWemgr1QOLAJhql4nV myX261JoOBOJu5bx2StU6UA8C90yh0uS4XKmGelDvO6d9rz+WracwI3ZxHoYUGcJ/Fkn6UEUzU4I tj8OvfHkGejJTKDYUXc3WKfwYBp6M+6gfTyK//WjKCqWASpquGU9rCEWFVMiAe7QpJrz6+vr44o2 fAkM5Et1+YRUyEVGKl+vBTVmIgjRZSVJwEl8jaYnMm6ozo0okBAU4sFKcCw0mqdeoY2x0fIhzUq0 5vXs6tHqkqhou0u+G9gTNcasKS11uB2QvuQ5TRlq33TMRqJxjJWdJ+p1Qxdo5xrzynZgDhdbjqqF 2q6xZHkj5ULjjGrKksls7DVGHkWQDLzYwZaqRqYtCLZ52CLotZFECty+c5WSK4O0Od7rItuyRpGw WrMFLQ45U+oiq+sufa/EB1x+emdEvr8/zygJouz6n+Tju7rnYOwnrcrwhKaJM2ef+Zsu812dcnxp DkCVmTxTdC2v2vnCBMcCccMQ7MBRvo8oR1GblzZFB9yBbdwWxybVIN/J5pCh84QiUWfa5M2IDu08 PIOt/zREiPZBNomml54JHW+6dtlq1wHlUDU2OX9KTdY1RtZEF/sWpVKylrHMyVyR7/6l876htyLI Txkp4ZqmsO/v23IwoIxPHnP7tR2ZwFooYkVKLKEIs3bq3+kCNVH7zWTtrJA0wUl1Zi61Zteykrlc 7cg+TDokm5ujYxOssthEB6lVc8qPZvHeeuu26+3xOH+8up1vX2a9t55e/NOjxA1R4sXOp9aXbtER T11Kn9z/WU8mZy9BXrXkR+tHlsCvhofDPTlU2JXNkqZ5WJGedpmS1X5Q7eQnVbIg5qW4pcwz81mc Xsa7Q1rLRtGcxlJDzVisWMNz3AhiFmkas+Li/n5+xfJY4yOBbYl23ajccf8bPX6utYwzK1R3LMK6 fneHumJJHtAPO4KiOTPebzA3B4QUzLyJseoWayqDuBkA/6zLvS4s148V1wd8wKVqhNqBHw14youe R+/zLVvvh1+68SCkH1jbtmfe/eFMfW6X1BD9KRROMAoOX3Pnnvb/BxBMImYNZW5kc3RyZWFtDWVu ZG9iag0yMjIgMCBvYmoNPDwvUjcgNyAwIFI+Pg1lbmRvYmoNMjIzIDAgb2JqDTw8L1I5IDkgMCBS Pj4NZW5kb2JqDTIyNSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEwODU+PnN0 cmVhbQ0KeJzFVk1z2zYQvfNX7C3NVGJEWRKp3vyVWjNOokq6dDo9QCRIoQYJGgAla8aX+pd3FwRV fyjtZGK3oGWOwOXbt28fINzCIIxgQJe/p2XwYRFDYYII6NJFMB5PYDTATzJKIB5PE9A8yAOKds9v g8ghgL+lJZytEGUK03AKqzxokSOI8S8+CaMhrMrgB3i/+iO4XAW/BO1r34o0icLhyCHNKst1xW3/ QrPcwuMxm28nfbXlup8MhlGk0jU8G6dN0RgLw0EUE6GTcTg5wRJX18gQ4IyzVFUPIcBqIwyYjdoZ sBtm8R8HVXPNrFAVqBwwQRhF/S/nZ4CRqrFGZJzC3r8LoihMkkHUoSKk5XeW3mJwtlzOLkIMGp6E 8WQw7IK+IGsmZc9lSlltG80zKLkxrOCUAuErK1ImYSfsBpF8kIOtXOkvU9csveEWeCmsRTikzjzz NQjSMWcpd+XylmZlDTAErTVPheFyj5gEZEQpJNNE/NDEb7bDZDQMRydT18VJGH2HI5IkTKLp9Aki lnHuJREVfFKVsErjPeOUqB/F7Sv9g/CZq4xKJ/FgcdrJdZAfcUqPUyKOa4OUaCD0AT5ec6l2IaE/ k50wNcuEAstq2HCWcY2Sqi020SAUUswlvxNrIYXdQ474mtdKW1EV3kPOOBumWYpdEgY7b6jTuWbo Cd+xBaWgDFdtBqSHfat5lRG5PSIJ46FqhuBpgy0EY7FKtEzWGRpzmr2xvCR/kP2uFC6RkqUbUaGl lZtbnB6QnEboDy62mCfXqnQRuCR3St/An/Y4tUpZomfQYx7Kp2NCP/iKRFlLXmKEW2f9rC2mssfw GsPzRnookrAWRbFfIz2qaH71K7YPp8t2yR5oYlX1O4P8C1SVa7S7gYxZhtEei3U1Nphbo1xVxtaS k6KYU0uSjtW1xMVI0MSEMi4VveQxDovLtHq0dPwcGqxC8/Qca37HqOifoFY7LEzyLZem5yh5LDJb D9zWQxYwoqhwF8C+VAqX6MORzYSk9DV4xR9pTdqRLq1HZpeXl35LgAuSoRW493IvuVaF236uRXUD 57hZaCW76HYFnTHDuwaRSLPzTzTdzhDNURyOaQ16RHjR1u3gZV6AH/vfeXkhAe59ngXfCoO9u4cu 85xl9JyC/IzkVYEb7ZNxf0B6RU7Pf6MOY+57l0tWmK9GvQ0n54UFOu8Ix1arfxqvy+mZu+Frpn1j 7+C62tf8w7JZW7w7h3+k7RjOrZZPNLpo/EHh7ft0dCzazVnDaZahh0wYhm+QHFFfZHpcb3tbaVYZ d/74D+gcSfYvTv0/2tMOPAnCLHs7LVr847UCObeAz0259nv1kt92X19bi8e7/pxbbEra9AB/m5gM O0aXd7XAB/CRr3XD9B6ipEen9OQp8d/mdBqO4t+7c+gknMDOHyAXPwdxRGfHGA+XMZTBeDj++6sM lhj/F7DZLdUNZW5kc3RyZWFtDWVuZG9iag0yMjkgMCBvYmoNPDwvUjcgNyAwIFI+Pg1lbmRvYmoN MjMwIDAgb2JqDTw8L1I5IDkgMCBSPj4NZW5kb2JqDTIzMiAwIG9iag08PC9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoIDY5NT4+c3RyZWFtDQp4nO1XUW/aMBB+z6+4t61acQmUJDxSaNdKdGUh2su0 B5Mc4DWJqe1AO+XH75JAgVbbuhXQpO0cFJ19+fzl8xGf76DObKgXbXkPE+vEd2GiLRuKpiZWq+XA aZ1+3qkHbqvtgUJrbBXR5fidZZcIsLyFCZwFhNKGNmtDMLYqZBtcutwmsxsQJNZbOAq+WueB9dGq HvtdJMdmjdMS6So1qFI0tZ7iYwObdjWYOzU5R1Xz6g3bluEInlgnm2TaQKNuuwWhZos5TXrFoE8M C+vLiQh5XOuL9Ba6MjVKxnCJPEJ19MaybeZ5dXsd/q72ykagFVJe8esNO4PCu6r8YeVC3s0f2YwF xhHF36gJg1BGyBh7hNkdIUItpuCp+MaNkCmPiUGEKyHzLVmDhxludUC+U0qNJnOdemMtfLHScMY1 HmZxPqHSpEEOAeXcWITQjbnWWyJcxHIBfT7C+GnO7VqMrYQhG/CHWPII+phOzHRjgT7gvVnqU8Vf yhn0RSLM3jn9mW1weiXSYTkNZaZChE4UKaS0+Cs4vcz2wul/Pr2GUw+1EWn5zf15Rv0zOu0gn55t IL7MqIwggalaMEJjgqk5xA6/3ikrf72nbgjWnWJ4q7Nkj4KsOHUztbEt5Nf5DfHwUaOaY/TIaalW X4zRiAT3zOlH5iMPp3wUIwSbJPaaOL9MZh+N4qkuKalDc7qZFZ8JDS8pASngSbkbTBHmPM4Q5BgM OT1uOPjc4LLIFGnZ7fNISMNnMK1qCaFBowEjwXn+l7kenWhWYFOUSCOqpg3qEkYVwNzAYirCKfVQ gN+BBdd0wghRUL4VL+FSob+CG5C2qMPsGGg6HrOVnOf3M0EDcIEjlXH1ALZ3XNT03rbqnwd8gjT2 hWDLo4fDHFgsDyD+e5qqOHu4DrNdSKxWo7V2Y2tI8d8BInt1rA1lbmRzdHJlYW0NZW5kb2JqDTIz NSAwIG9iag08PC9SNyA3IDAgUj4+DWVuZG9iag0yMzYgMCBvYmoNPDwvUjkgOSAwIFI+Pg1lbmRv YmoNMjM4IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTQ4OT4+c3RyZWFtDQp4 nKVXTXPbNhC981fsuIc0MxJL6pPyzbGVRDP5cG11esjkAJIQhZoEFACUrNzsX95dENRHpLRNI8mj MQm8fXi7+5b6AlEYQ0Rv/51VwW93YyhMEAO9dREMhyMYRPiXDBIYDycJaB4sAlrt7n8JYocA/iur 4NUcUSYwCScwXwQNcgxj/Iz7YdyDeRX8Ci/nfwXTefB70Gz7UaRRHPYGDmkmLdeS2+6NZgsLh6/Z 7XrUVWuuu0nUi2OVpfDN66ouamOhF8VjItQfhqM+HnH+DhkCzJcc1qysOagFWPxnrpk0lbAYEVie a24MCOluzabTKWCYMI7hhlkGbznLuX75IojjMEmiuAUVBgy3YBUwFDUVtgkRngmXc2OFZFYouQ9n EJJw+v1L/ESR/8TwxMqyKxVugqourcgYnsxvez4H/+r+3mPNclgIXuZEbrG4PP50YLMU2ZLuaZ6p QoqvPId06zBQ+I3SDx5npZVVmSqBSVZuv5JKBlIuZAEXqVYsJ04XnstrzYqKSwuyrlJaKnMPY/iX msuMt3ccNwNMc5St4BhXtxpGj5PoehTixl4/HI+i3ndz91EXDKk3al6jTO2Rm/y9UwUqVnbfCfmA t6XVqjxNXpPUgxxGj1HnUBY878VUZmxl6pJZvDAltqiSP7U/4XFVbVd8r3/0mIxubuBpyR8xViYq VgJd6YDSoAhtI0yL8wvdeT5hQIV/cUaUK7hTNRXvVY5dYRHHJQCjrrgWKicFyi2eDS/6BOtmg1Wn YuyrrMBVq12JLhZR7/IyxgPPHDaTILJqBSuWPZBqdNy4PzgShBjDBy6KZYrHvBEmo77dvjDnGVcY hxUcMkwUE5JieKCkSy3VqIlsuF6jJgvENFiFJW/ulqwwHVIKmyXTIuWuDD4hxM6SfszcBoNh2OvB cDAO+5OJ86W719eDZBT/hM/h9jA5wvwcElx3EA/xRneX3HxX8U7GZVOkO20ojSWVdakwv7s0+epr Eky436T3yahaZ/yZgBaiqDWqtBYMpn/MuqMBsLJQWthl1aHOPetV2CM+K9gp+6q44xnlEPNpcLUj 4m3k1EAMPPGwCD3MnwJxl0w/PNPKtcAmxliCguLBhMQ8V46CcSnHwpvdtmw6IBbAPFDBlROj9YMc HTtlhrtWoLKRlsqXrAGvYCdWq5J3SK//AMBS2t/IQgpfvOFqdntxyG9v495Havkg1UY62il2OTTi f09a9Hi0e7tUdbFsJW7T/687yUfbsIYv6rKxIxwSHmpOh25ZZ6hiinDt2sNTIEKp1ANg81P4TNht x2NkqkYP3Xbg6t7beCOIc7AjkJNMfcfNWyc98svGvEtv3q7Ks8a82zbYefWpgZHV5nk73iTZn+XU L8w62IVmFY4cGvorpa1paKLEjZO5CjlU/+ARgOqh8w9D/NvxHcUeaDdrSU+lcflKITOcoHu7fX91 vdOq0QZHOQg3PtoK343bw34/me24/aamqeqomiWe0lmFB8lr3RBPsT85l9izSK+kGvK1TVEM9SFm VGM0XWcWncIdXfN9mUuFPd7Y7IFM3Y/Xryj4hpErYx24KlLUbC4sUmbGqEw4Fh6KQrMaV0qSw61D M8g4kuX0tIE4HFs2WzJZkG6UCkoVhm1nxD44lywtkVfz3IQl7ihsRIna6Zx0neEsZvuBjQMSYvN8 wKViODEtQ+WQeVVLRwrj4ngxipLuHHiLbafFGjHkgY0c7MDrRFnyMvz/cwgfjXvDCOfF2M2LUdj7 ifmTJGES4+Q5REQhr9mKUkyp/EBNXMJ7FM8Npnjc7Dg3mgz1kuuesxPdPxzsBzJL8QkAniolhVXn 5lOFUZ+p5LOGUO6lhbfKoPt6a/AUaXE7qFYiwyeztk94qTakeIK/TYb+2f+WW6ylrO4AUmJl2P5c mD6uaALBa57qmuktxEmHfjwkx78qPt3Ss0k8+dwmchSOYOMzcPcmGMck/ngUxmOogiHqu/u3DO5x /d9+YRMEDWVuZHN0cmVhbQ1lbmRvYmoNMjQzIDAgb2JqDTw8L1I3IDcgMCBSPj4NZW5kb2JqDTI0 NCAwIG9iag08PC9SOSA5IDAgUj4+DWVuZG9iag0yNDYgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVj b2RlL0xlbmd0aCA1ODI+PnN0cmVhbQ0KeJztl99v2jAQx9/9V9zbVq14cSA/eGwpXZFYy2i0l2kP JjkgW35Q26FF4o+fQwKEoq7taNCk7QyKnBxff3y+4PMdGJSBkbfy6sfk49CBiSQM8iYmxLJsaBn6 67ZccKy2CwLJmOTeq+d3hK0UoLz4MZx7WqUNbdoGb0wKZQaO/jhNykzwYvIeTrwfpOuRL6T42WuV bEbN1kqplygUCarGheBjBVXrDeZ2I52jaLiGyVjqj+CRnWWTTCowDebkQE2L2k09Ra+vCXPrqulK HHo9uEIeoDh5RxijrmuwrdeHxoFNixZKy8eApV2gVGHCVZgmlNKN+9sNrFUrY+yNX+W6TTPhY20Y hfwTcXjGljUgVabuLWb7YK8YU3uaTerYhrnNnTxH4ZxLPE5+fUUh9QIvwdNvyzj0oRNxKXfW9zJK 76HPRxgdO8ADvohSHkAfk4mabsYEuMYHVcan8L9KZ9AP41DVv+h/ZBWmA5WOy1S+fGdBIFCnxV/B 9DKrhel/Ph3CVN1QfptR/0yc3iCf9jaQYZrpAkgHWNc5KpQYY6KOUaRsN8Oi30mDnX5xc4r+T5nF NQZkzdTJRGVbWH5e3miOIUoUcww2TGW0+uEYVRhjzUxP2RC5P+WjCMGrQtSaOM8m8xCV4IlcIYlj M93M8r8JCS8pK7WDo8v/dXYPNDdKPzsFXafziK5Ruw+zUD+ASxyJjIsFMPc0r/Td3Rl9G/AJ6vvf tezqQGJTG+7LY8nwkx4qP5E4NmU2xMQyrW03Irfa/xfQLlm7DWVuZHN0cmVhbQ1lbmRvYmoNMjQ5 IDAgb2JqDTw8L1I3IDcgMCBSPj4NZW5kb2JqDTI1MCAwIG9iag08PC9SOSA5IDAgUj4+DWVuZG9i ag0yNTIgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMzg3Pj5zdHJlYW0NCnic pVZNU+NGEL3rV3Rx2WyVLSyDvyonFkjiKhII+JbKYSy15VmkGe3MCOPc4Jene2ZkjIGtbMXmw7J6 Xr/uft2tbzBIMxjwO/7P6+T4dgKlTTLgtymT0WgMpwP6nZ5OYTKaTcFgskrY2t//lmQeAeK/vIYv C0KZwSydwWKVBOQMJvQzOUmzISzq5Cf4vPiaXC6SP5Nw7EeRxlk6PPVIc+XQKHT9CyNWDvZf85uH cV8/oOlPB8Ms0/kSDl5nbdlaB8NBNmFCJ6N0fEIhLq6IIcC1QlDayRwtuLVw9AfhVhRSO9HAbygK NCAt20BjsEFVYNEDoYqd+edPSZal0+kg60Dnl5eXQHzSLIML4USHE04hXOlS5qLqX0l1D+daOaOr aGNBGM+IUBmKfFpULmWmdF7TcQNrAiIOoHAD6wCtRI0FXPJtShTM5y/cD5DocniSTsaDYUd3QZQu 0DqphJNaeZp3ujU5gigKOmYpOVJ56vseguu34ecUkYj2lnjBg6haghDWf7WSWBUWbjFHSYWDs+CD 3UaqCyOUraVze3cj/Y7HRykOtyPOUa2VdNocQa0LhFw0rjX4QQY8SdArD7/YNpHox4GzLAaP0/HF xdsUPBnMdankP1QUCvuIZXr0/DMh0aHgSdqDBHX56YjEIHYpC6Qine9IqDPZRR+B/kMO7pXeVFiU KJYVAj42aGSN3H2wkVVFuoRCt0sXWyYEIGtZCSPdNnA+yISP+B1dbqRbk4QjH+astKlFFWiyCqGh G5H7DiD3zCRTWon8vTjmDmqxhWW0It04jM0qFMmJHAaZV2IbiiiVRcNGcs/rd1r697NzaER+j27X FkKaHrlcaQqlwIp1LVUJTu+pUTRNRTVj35b6ea7Ikvqk6oUciUNmHAW1kpWWVR9BCLvu+jRqtZtW vY4f9+/V1XmUqW+sGGM4tSest6oOzDyjjdj2QHLOFafTErsuk6xnMK3qhgsxao2oqi1ZGSHLtQMe yp6G/8DOAr3+9fkXn0IfZY9Vb9d60wW43Hrb1r7uxdBoYfAKa9ua00u8DrMWUZ7892wTc0JEjtkp VeRtzM8so92m+uGddzIbprPR1K+qyf9ZeuN0xqtpH4/KcYd569vrnMVAdIOE2FF/5E+cQn/XBIWP /0xRJbpzNea0MaStIe63+U2UmKadtKT6hKLGtsmFMRILxj9oAt06IIl7jBIVManIOlTKK4IRRGX1 HszuEBvE6ujGB0HV8dp40cU77bwnmkJjt4j1AyWC6k8dYraN06URzVrmfMdhzvnhdswFy0i6t+0c GBAcseOc+pB4b+Gj42gEfLm7gyead2fW6lwGhd3iN9pj7jiGcYu2oUJgj+fi+Zrkj6pESre1okT7 nIY6COd4WBjfR6y9MCa+0lNJBLJyt9cUCgO0/kqf1AekoCq0PbBKrlbRwm20uYcnBqAiu70Rs5uL nP3ik4WVYcoq38ZRxAmi0IOHZ99NdEl86kiza2gez1w5hVjESdast5Z3DjX50qC49+nf0DVrtM15 mle8jcLkiDhV2N2+KmF4KMpzTauJYKg6hT9j4WkjTbxgVe5ORJiggud39HH2WtI9+kTC72aW98Dc Ax60iiKgtDEF/9m3Uu+tQPwzEP5x8QqIZVy3lXsPg+fmioXwIsGuKDacjpPthWnbcCn8hZ+BLe34 Jb7EnkaAaxbNRrLQGIAeQfsE6LvXbq3Deu/wRtBoK7ir25AYI+2uqHS95anNwKeTdJTNZj7eG3T0 dJW3PSA1Ca5neF0+NlQVC7/g0rTCbCGb9vhBevr6CfuvG5I7DLO/uyk6TsewiQPw9tdkkvHso+mW 0YRIRsPRy2WV3JH9v1gq0R4NZW5kc3RyZWFtDWVuZG9iag0yNTYgMCBvYmoNPDwvUjcgNyAwIFI+ Pg1lbmRvYmoNMjU3IDAgb2JqDTw8L1I5IDkgMCBSPj4NZW5kb2JqDTI1OSAwIG9iag08PC9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE1ODM+PnN0cmVhbQ0KeJytVktz2kgQvvMr+pZNFbAIm9dp C8eP+JWwho0PW3sYpAFNkGbIzAis3JJfvl+PJAc/9pDKYrsojPrrr19f9xfqdSPq8U/9Huet3+9G tHatiPjHrluDwZCOe/gbH49pNJiMycrWqsVPh++/tKKAQPVbnNPJAigTmnQntFi1KuSIRvgdHXWj Pi3y1m/0dvG5dbZo/dmqzH4WaRh1+8cB6VJ7abX0nVMrVp4OX5ez3bBjdtJ2xr1+FJl4Sc9e02Jd OE/9XjRiQkeD7vAIIS5uwBDfOtorn5LIMjrzaXBDQicEuG4UkWLXKxFLUonUXq2UtK5N/KSkXJRv 37SiqDse96IGUT4ouNtatRNxSVa5jQMKW1DhJJlVDd35+O7kdfguQBnp1ljJobXZ3hQ+McY62slU xUUmLDnpvdLris4zj4Lpwb6GUvnWWC+0x6NCM57SFVwD0iX6IPcH1nigiGVCy5Lha5ytcU4tVaZ8 yZEI70W8kaCi1WoF6pTIbWZKmInM6DVZ0JZIMSinlCExUtdIK2NRPNqyvXcMFgLL8PRWwAmMlyVI neM5nyqHnhTO6HadyxrlIJWV5xxZfKwPrAQ5b5mJlrEELHh7EwqxtcbL2CvTMPLGZMhHAaYCgZRa 5CpGX5QUI2drZnQ7fUciSSyQJGdswcTQBZTKbFvD5MqrtfDPCwKvgmKJIiCATO5kBvuPGr1mmCzB RYLgfN1UjJSKnSSuVo4s+aaJ9nDnyy1TC93fECJReNOJjV6pdWEFB4YENHVDlxmboy6c98dMf5vf TBHS3hRZggQjVBg9CZJEnlTfN6SkRre+yI4M3ASaIPbwgsrWEN/bT4g/Vi5Qn9Up+uFuz3VDeZAL nsIqNzLAhrl41JOfVqbBYNLtjyZBUMa/Ik3D7oQF5BAPpbycfpjSO6MdBrnKvnvi5Of5QqkGUYU/ +T/4HuCBL6h6q5boGRuIdgbhsWPq9I+6o2EPGp6EQt2ZnFv2utD+K8WNFWosHzDNTu24bcQSg17V lBuZVcvRUvq9xMAD/ZlGZkpjJGyhNU8VTDlroUnYAYCDuNDJfE7fDkY8mH3nNnjkWOEtVE43Uum8 kFmGhjmkyahAFwx5IMKBK/N8qeAHHnlaEshWAOOJgiUPMYQ6xoy7V7jcCquMw9uGZWyjoEZXBj7n UF9BN+YrJr5N02yJpM6hA1Zp6Fro9mkmH+QrK+WTgYSZHUvWDqEk5NRaBwoQ9JWUyRIqyqPL8ckH DLsKUwqyRVDSy1kjTpgyscacceRPFxF+oVwQFQQrslcjg4hzfukeO0PavYBo/FdDMJPbxV+cvLhA HqDcL+MyvDPqEp0t5pd0uZizVLktC/NOVhpg5U7JvWzEYCtstS9+aEli4oKF/9cE4uh40D0+GocB iXq/MHHjfhXlISAmbhpvtNlnMlnLsKXC1DUZeT51C1bTwqe8oit5ztRG8hbhBb6he+UN/nmdiSKR WZvuyuKzonuxURuxF+1XZu4sz4XGfNCJiGOUUXFfphhsqbUs6w84OdAvbTq3QscGy22ucl66p6LZ kiwHDo1XtOkaGsc3BatDKpQHC5FtUzq1JkfX36FdhE3ozamKN29gWPIDzXJ7X/Dp06aFyaEtVuFR 0Q4thhacm88bfLrC8oMuXGF/p22aF9gRKV1jn6ZahH5ioFOlDZ1j6DTiQlCfFFofczETdsMQMjWY jJkoMrqShoO7yBCloIt9icgbmPdCu86VEXEKLTlH16bM7g69S+9N4TJO0Z18oJMiwaW2lBZAZ1Zt 6IOxSc6+aqATs0Qa3cbgrvyKQddYbXv6dmpL2P2BdXghjcUpIUp2cIrR9mlJcyQSPrjha5x7hRqJ nO7T0stwa0iF1S2yQiwzFso8dBHFOAX5bkwerwvlXMGb+xFqLTV2Eu9qvlN44AwfFVCTSnQP5+fZ zM9wkGIjz1Z8u3FCjPPKZWJHN8qZXXmwplHyPd9UB7LycuQTbHzeDSyskPPiIdgn0sVQETBLzZ5Z jHD7N1Yz6VH4GA3HpzmfTdXr7GGr8AWdy6UthC0pGrf5zB8/vf//nkHwqN//pxGHYXdI+3qs7y7g iicaWzIaUt4a9Ac/PmatOZ7/F5Ar7KQNZW5kc3RyZWFtDWVuZG9iag0yNjUgMCBvYmoNPDwvUjcg NyAwIFI+Pg1lbmRvYmoNMjY2IDAgb2JqDTw8L1I5IDkgMCBSPj4NZW5kb2JqDTI2OCAwIG9iag08 PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE1MDg+PnN0cmVhbQ0KeJy1WN9zm0YQfuev2PFL mxk4c/ym0+lMbMuNEjdRJbUvGT+c4UDUEqcch1T3LfnLu4eQgn5YE4cJsi0kYG93v293v/MnsAkF W7/a92RhXI5DyCuDgn7J3PD9ADwbfyMvgtCPI5DcyAx9d3P9k0EbC9C+JQu4mqKVGGISwzQzNpYp hPgTuoQ6MF0YP8Or6T/GYGr8aWwee6mlgBLHaywNS8VlyZV1I1mmoHsMR6vAEisurch2KBXJAxwc r+u8rhQ4Ng21Q65PAhdDnN6hhwC3QoKacVjUc1UkDG9Miyqpq6oQpdlcYbWaCVnBWtTzFObFIwcl 8AorH+HDmpevfjIoJVFk063NG34nytyEt4LDVNTJDE95CXdF+ShWzISBLB7h3bwouQlXsmAlvGEP XC7whJUp2tNGlkyiQ8WSlarSC351q4KiBMzGWshH0H+KModcinpZEXzYcUkY2M7Wmek2hPqZGA4X 0jFfFTKtLJFZx8Ex65YzvEfChYZlPi9yXiqYSlZWSyEVU+giTJ4qxRfVBSw4V+hfBTOOKzMFw8H0 tg0Rw0BUAu30jiYvJlzg2sT344YnlPagXORs4uwaJABjnnHJy4RXe7Zf7qcdkDDe+kn6eBp7G4S7 JtHT9wIppIoVP/DZ2jJidzJNm/x/HFo3pOAqswLknpXyjGEVWEWRVvf6wQPkO8fvolQm3BITroVY cmnCazyfzthcn9/gORIZJgTuhn+ZLdqd42LME7FY8DLdsEUTRrGHOW/KGZpyz1iCH1PkVpEVXFYX J+x8P3Go7xEagO+FxG0zmOreYp1Oh0WDHni5bkTcvbXgc1O8WABLKXLJq+qLuYEqwJvA2mU+PQx5 wpdYWNgt2tLBhw4K/gDVOr8/LuLOcc3kkuuEYy8iW9jeYlPCBnYxKfIS058w5BKIrIHnGIZn8OoB jxMjsx0cSCGJda8+AU+dW3YfUDyHEi/YW2KHSgOF69v6hjNYfMUOW36yQ8U9j4qqVuscA+Fcjyw0 fx6fyX/YYFWB1YVV9YaX8gmnSVtgtwSu2KOG7uKmyLKKy5Xu4MPBYHCMEi5GKIU/2HKJDbkfPL5P qIcpjIh/DM9RgD2BcmPiRHuLHQAVRPqGbwOqowZOwjS+vaa259wDjASOsLlOdpNrfBvzp1LM00oX hsLvmEwha/WD0vNvUTQD+iyeTRUBNj6WS7aoQGuXBjEN0Has6+qZTG8w9j4weZ5PHAfciBI73GQO wwMdXx88YoeE3p7VTe/SFYUXzuBw82GI5gkNseou20zjGOEPsmbyCWgcRSb82mPOumGMa4MbxIS2 XJkptax+ubxcr9dEZonVT5S6PvZn2rJwfxZ9v9ftMOra5mmhhCRC5pdFmYlL9LwnbE5sE4Sru8hv ZDNzaKyvHKkDBAgVdYylcCVZWuo2M8HGc/GOP2nZmVYN+euK6zmGNzfqcVimOC4UP68fxvxTXUi+ 0Mrxjq/4vOe4CCP8wkX+BWHYhHZ1PQLq9ZnZ1CO+t2fT7IOx6wTEc/bs6VrUCe7jJe624gMvNz0R m338olrUnpg4HWQyw0KMw56FGDgEd5SujdSKwx9QiE6Mc5uGP6QQu7ZPFGJPzNpC7C7yDYXoBfa9 3llyWWhlNtkMpTGBN0WJosvc7Mb0JhlGUiiRCBxdf6MO0/o6OF+Nn7Ws+wKTJU8asac1eU/5tgkR SeB0yY5B9JbRXaPmMYtxiW9U0jvJhmzvOXYcDyUKqiIbBf5psp+iUb9seJFNomBv0ZZGHhYdXnmG Rh7S6FqyNfbuFOtdN/RpR7tsVT6MWPLIVatPBnrDj9w6z6P3X8VLD+5gEfj4F/e4/h51+nRzTQbM RNfqSe545gEtmoRS3I3o7fPzXOpDHhrof8052LCj8CXk6TXdYpRqwd6iLXlcx9ZXrMgltJHbGOuI K1TPSW0Cdhc2J9uoB/8ucYhXHQGHdYTKOtpPzscRyzk47v3O4YAEsG7dHv9uhFR7HAYIBSwMHym9 +zg3Jnj//93o170NZW5kc3RyZWFtDWVuZG9iag0yODcgMCBvYmoNPDwvUjcgNyAwIFI+Pg1lbmRv YmoNMjg4IDAgb2JqDTw8L1I5IDkgMCBSPj4NZW5kb2JqDTI5MCAwIG9iag08PC9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDE2MTM+PnN0cmVhbQ0KeJy9mN1T4zYQwN/zV+zw0t6MIyz5Q3an0xlI uOt9kEshU2Z6cw/GEcSNY+Vkh5S+wV/e3dgBB3IBqrtLyITY1kq7+u2XvoDLOLj0br7TWWf/RMJl 2eFAb3PZCYIQfBc/kR+BDOIIjOpcdOjp1f0vHb6SAM1XOoPDEUqJIWYxjC46tWQOEv+kx7iA0azz M7wa/d05GnX+6NTDXiop5Ez4K0lvi0qZQlXdvkkuKmi/3g6vwq6+UqYbuYJznZ7Dg9fB4nJRViBc LmlBXsBCD1UcfcAVAnw6ed3z4tD7DNBXV4lJ5kmeZw78yRw4S6bZNFkmDpzgr6GqjCrThQMH+Csp xjBkr37qcM6iyOVrea3XaLI4V6ZyYG+gqqU2UzjW51meVddwMzg6/ngLh0mZpXC6mM+1qWBodKVT ne85KPaBLLxyZ8mX7QkPfMZDkC6us7YmagykssX2oDFZGLWFOtD/+BbHMS79SO43VnXgXVIsEnON I9zAoRm73HNpbPfOcOOHyv66sbIXqhsS6GGEl8PVwiZVNS9/2d9fLpfMXKRdNc4qbZg2l/tZcaH3 8ZqlMbyYMxm25/yNrTT1hEs3usLDL1esNSXkfDcKEbmjpKzyZKrAM2O0IHJ1mk6yPFcGLddQdsqg Z3Q6xWsk9eu87Z3g43pWqLKEE/VlkRk1U0VVwoU2cKrShUH09hwLltaaIlJe7eOHvSGOCi2s53se 8/y2TAcs9t/3AyZEWxzhTua2WWMsmNxc42qDfcHp+g6UHzoFLQS3dlGo2iOsWPeCkGJt6Avme/FW 2u1CcIiuGgS15AfxyMJD64DUlr3FJy13TMToetHGJI1TCh7Tna1O6bkcnfI9Oo1Dbkfe956h62iM 4WsHggODLlqptFoYtXKtaqJ2O+Y6fbUivIUTCikozgSxz2Ie3yOOi7cJYhirMPu3pT4O6TRHTb7w Y3p8F/kqVTPMf9+Ac5pMQBB5zP0K5tsAsrOHH7ksCjcmbQDy3ZjubAXIFzECdKy1UQ4MMIDvfZxX 2SwrK8zz/cU8z9KkUnAwHhuK0n1FHGW6gJv+Qf92N0WEGlU7dvAg/QEEvmRe3GIH123jbKFkaIi2 1C3s4BxYOs1NlhMSYVMMxCEN/a7FQIAlX8CfD46dMZoc2Z70GeVAFFLkGSSmUoUDIyRnoM14lpip A0dUFmSzeanx1llTFfyOcUnn2SwpnqoKBiq7nJwjPP2sTKlSvm5QAvy/JPhCuCGwbq3I8oVkPmZK dA7ZIgsVs/FCieFIbEhtMq/r0Y2XZF5cCdpRzau7sCQt028UsAgXF0kWU0PxzdOvLzG/8+i7pN+2 7G1OYLdvTfptT/J0+g2iiKLnYZKmatWDEfhH4zoPHzMY6WVR5up6dRFDKxLcBNKsuNztBMd6rHLI ChwAv+sUmoastKuGuc8CRN7HzCmjO+RJDZv4EQpGvXhL6uNgSnM0iRjDDT6+wxHayHPXMhMHAeOo sohY8BXkt8BkaRFkkUUbc64zMUcH3IpSKGSAKA2VmWZF6UCPNdC805NiFUf7TRx9x7Cgm06pwlt3 57tRWnfrCJN9Ng5x8yJMGVjRBfcE0eptCHIjFm4IfQwQTUF9SH5dU+RJthMiRIfbocPjgHolL0KV 5bPRsTRFnZTac65zMbZO/nZ05Aqd04nKzzHU/LUmpzdJpiY5xwydUXPwMEETSz22G51DbTBfF87W nFwXiv8mq3JwXesB3Xt8GvRBL7tDvUSXPsMmP6dSElFHrpMcaVbJXXyDm/CDPhseDMrb73Kq5GED jAa7J1dabVdzrNSWugVdSegO0DLroCZ+3MGSh8W/jOWz8bWzR1NLtid9upaUUlAt2dN6TsdIdFj5 RlNH+7rBtI+pdJKszpjuu9rVeabJrpL0ifjX00WZjZVZgVrek7ruad6oorkJxyqdJEVWzsrvAp/A TCla8JHi9vC1pT6Gj+Zw4Dgx6YQGhD+OPBG42F09mzxLYzTktSetyfufOmA1K0TIQq+WhYYSFquL /Zr6tkhG5ywXFGGr7ErBibpQRhWpKpsEV4/ocjekxoF26P5AX1WQ5Gy9V0f/zDGqlvBanZvV2TWP HNrsaHNLPw2TSwXC/3ynCC4Glo06J286kpMmVAJLmHUCtOXdz7xzis//B5pTxM8NZW5kc3RyZWFt DWVuZG9iag0zMTUgMCBvYmoNPDwvUjcgNyAwIFI+Pg1lbmRvYmoNMzE2IDAgb2JqDTw8L1I5IDkg MCBSPj4NZW5kb2JqDTMxOCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEzOTE+ PnN0cmVhbQ0KeJy9mNty2zYQhu/5FDu6cTNDQATP6p3jOK2dOHEtN55pxpOBSUhiyoMMgJJ9mTx5 F6QkU4fITTWuZA9pCVgAu9/+u/Q9OJSBY96La1JY/asIxspiYN5ybAVBCL6Dv7EfQxQMYpDCGllm dPP9vcUaC7C4JAW8vkYrAxjQAVyPrNYygwh/Io8yF64L6xd4df3VOr22/rDaaT9rKWTU9RtLZ6UW shSavJF8pKH7OruchaSaCUlix2WsSu5g43Vcj2ulwXVYZDbkBTT08IjX73GHAJ9HSUKS5BZve0dX YlpJDbxM4aNMhbThtRhVUoCeCHgr8BOew0lVFHWZJVxnValeHVmM0Th22NJi52WGZkrhOLjhapKV Y12VNryhJxT3EwT+kQ1vT07A8Yjn+jZciVxwJVI0umEJLbwVd7Lm8hF9Z+NsB8enVVIXotTGCGmN HDM6TUdPX22bGkkh8kfgM57l/C4XwDX8efV+eyB+sorez3HAAp+yEMIopk7cRHCi9fTXfn8+n9NM K5pWmo6rWV88ZLqPEfgicL+KTnRxADPeIKJRd1F0wrzMK56KFB1oLKOHQhxDViFLNw/9MdHVnZDA Ij0xbmYe7VEz1fVoFDruBjeERS5hsX+7l4Pe0YUoKolc1QV8nGalIWIvZdvRWMfu36K1bccJiQFo iZoh67xGHtywoSrcoGq3AeZscvY/YhXEHnW8QZerieR1OaqUohiWliwD1JdpfZdnSZ9rzZNJwXUy 6R8mSkHEKAvatTeO1bX7387Vsd0kdMfRB+za9QfUXd/4Wl5g+EsBwQJ3f4E7gh3jNLLCvs2Uz2fk Df0qqnJMsumczwSZiUmW1DmXBAV6Xsm/EUWiajkTj7fG0I+z4tyYseGc2nAi1BTBVzYMqUmHkhcc 8+ID/vE7F1Jm7TCTMhd0G6kbobFAzHme2tAbNmubg51dkruG8U/LPcKH1R4BU27bkqk0eZ6NDdHX mLDKFIQm5WD4qLQoVM8+gGAPq+PAhwCdEi2CkZqSRtZcehii/mBA4+hlEO3a3hN4rEWH6LjnUm99 LfhmFoCshKmsxlIo9d1uuG1QdbFTwAl7VN0U/50qbnCeCrN3RbJScyk4Kepco84qTTIhBLYV+8X9 sp2OECOhQ83LXDwaIbbhXY0UI7o3C3TPKfyFEj7m9jZ4vYvlqijtpcpMFWiV3jQ3cHZ6egq4FbjJ JCq3UnAh0oz3dlg6WF99N6amCXyi81kPHRZw3/Fo6K+tuwp4W7WRCBywJ8BrWJhqtj/gGscmNcFW hKgE1UZmlSJS3KvnQt1OtOEYQ3rOSyRf8LoN/esqsVGd2lDfUHiX8zoV+a5YD5drNmOvxH2NUTVV VBlVQt0ypHekaNvES2iTg04OwQsi6rH16O9012Eq5fkB9b34RVSqa9sE9TA62SCgkb++4V1ytOwc m56xLaGub2Zu1VCTNCx0sCw/UyF7TdoPj4FAO56gcRS6Vg6M1qRcpg0zK104ThK8bBODm30qg6fl LJNV2SL37eb40+l3IASGIqllph/xRs4ytLO7SB5Pp/mqEW1qMi/5uAEYZUkpvFcU4PSBF1NsBF+m C3QjvARRtws0fn2Y5thKU3NLKznuL/vTfuS7YRj7h/R/Pgto4K6tDLxxd+cBw/fNmD1StXgeXT1g RD94wFhR4j3zcLEBiffCkHRaqCUmO1qyTvAPiLXrYtL56CUXW4GfiXUQMxYc2OuzgUMHg/BFJKpr e4nQIT2+w2gYr+8Yy8KPUCPMc8x4gg8F7pLSp+ImNPCcPkVyitiozv8f4sZYvO6Tz5eY9uAGt6tj hDSE+eIwV79ZETPniEJz/MIK3ODpz9wa4vh/ADf2h+QNZW5kc3RyZWFtDWVuZG9iag0zMzIgMCBv YmoNPDwvUjcgNyAwIFI+Pg1lbmRvYmoNMzMzIDAgb2JqDTw8L1I5IDkgMCBSPj4NZW5kb2JqDTMz NSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEyMzA+PnN0cmVhbQ0KeJy9V8ty 2zYU3fMr7mTTZkaECL7lrlRHaT1jJ66tJtPJZAGToMSWJBgQlOWl/eW9ACWZejR+aFLKMiUROLgX 95wD4Bs4hIKjX6t7UlrDqwhmjUVBv+TMCoIQfAffsR9DFIxikNzKLN3aPP9mUYMAq1tSwq9TRBnB iIxgmlkdMoUI/yKPUBempfUzvJ3+bU2m1h9W1+2lSCElrm+QzirFZcWV/U6yTEH/OrtchLZYcGnH jkupSG5g5xq3s7ZR4Do00gF5AQk9THF6jhECfMk55zR0RsT/+vYni1ISxw5dP+1db84mkwlcj8GG rrmNiCF+635XrEqZTCETEj7nkhe8aWCcJHhD2B2svIJPfJ4nbcEkTKpFLkVV8ko1cP95/GnyALYN F22hcvt0zqqKF/sQH2sumcpFRQAmS1bWBYc/r873G+Ivmxq8rJo08AlmGEYxcWJTh7lS9clwqKds WRdCcqI/EiFnw1QkrU5hGPle4Lrx8Iji+zQggdsfGJiZSZ6CqDSw7fm+bmJv6pXu5r0qO43UfGCK T94Q3dX1SBQ67lb9kTqEUl1Q9wkS9FoeLP1Zhf9LUxhQPJlXohCzO9ver8sUKZKIsmyrPDHtG0Ac pMYjAF8mWP4Zhxuubjmv9kGau0bxsoFzkbDC9C+5kqIWRY5RAZOcAermVsh/Gtu+rnmSZ3myjyP5 txZJ23HwkkmcN3ryyOPz8Qe44GnelitKw6mocJwDvLy/GJ8+mEgu53dNrsM6Z3dcwv3l7389wDqE LmPk7jtxWxWCpTzdx8Ip+JgocYO9N2X0BpBJUW5PfTOANf/2UTLJeXEHbMHygt2gTJj6QUoJ/Ih4 o1FfKs06wkelZHmVNiptjlEI2mOARhbQbrCdPPq4r0ukh73OYNijPpmrsjgifA+hwu1hkIJK5nxh JL5ddiN416O6y3cEr8nxpMZrHb/zLKdXKaz6wP304sF0HHxf8odUvvYAtIsXSH4faeUBG8nbzxI9 HHCetQa3VD94juz3sVY+8DLZD/ZxxhhEqgOB8GR3/fzv5fKXfaC1D/yPsvcdn8Re/ITsZ1ytaHik 8L2RS0ZB/EOE38dOV8487CuH1Gl2vPC3UtgS/jWvkd1a+q7zKum/Mn89rwG6N+2CGtc18jFfwviI ZKnnEH8LFte7UyPvczEzqQW4jwR7Y1ddYtM5h84FGi1mKHJUvLYJnCrc6Db6KSpAu4oRmpAplwMo BW53JE/0IojYO/62AcTMmMyrmdaDwpGUqEFk5qMeiKAcduzzvV5vj1AJjfVWzR1FZESjjlp6G2/n XGV2Xt+yBcfb7jbedrxjiBbgeSfeGhQzPUYhHh5sRv4TaRynbDcOieNFa2UfEWwck5jiTqSPeGiK /SMDDl3iRpuABcAVL4WWMoOM3z6ubAuOzMy45BUaOtQir5SmIFbk3RLMNJqF9QBv8dLHrY2vNwcI 2htXtCplnVoODo0jTqbXZ9twK4xxirtQSHAR7dZmbGtWe3PccwdAPLPArU5+vY4XeYX7AMWXqkU5 5k3TcoNr1K1jvESL403SDoArYAVZ+9ZkWeNS18B7fiNbJu+AxmaTG2/b25dLhocAN/y6FmFIQrhd lezqNyuiulpRqB28tAI3ePxaWNfY/l+HL/oIDWVuZHN0cmVhbQ1lbmRvYmoNMzQ3IDAgb2JqDTw8 L1I3IDcgMCBSPj4NZW5kb2JqDTM0OCAwIG9iag08PC9SOSA5IDAgUj4+DWVuZG9iag0zNTAgMCBv YmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTU1Pj5zdHJlYW0NCnicrVZNc+JGEL3r V3T54myVURgBQjpiL96iErME2OwhlcMgNWgSSSPPjMAcN788PSOw8Vp2lQuLD5U+pvt19+vXcw9d n0HXfg7npPB+nQ9hoz0G9qM23mAQQr9Lv6gfwXAQR6DQW3v2bff83mPOAhxOSQHXS7ISQ+zHsFx7 jWUGQ/oOez4LYFl4v8Cn5T/eeOn94TXL3mspZH7Qd5YmpUFVoul8Vnxt4PSYzLZhR25RdaJuwJhM VvDTMao3tTYQdNnQAuoN/LBHIS5/J4QAt0oW8OnyCef7ImYs8gcBDAOy6qCmFmFHoFl3RLXjW6TT zwg73eCM1PQGVMroxCUY+TzV7wuhRxWL+2+GcGYhWc8fHigB5yCNIj9icXxqsC25vfPghhHdC49w JcBviBWYDKFSuBWy1mDwwYAsoahzI6ocgaepQq1RX4GW1D0FQQLD83+Br2RtLCDG/CjqsiPv6Lib zMIrmI7vvm5D4GUKdzdy5BMXAwov7AbHVwnCTc6VWAtMCQc3wOHyGnkiy0sQmpbCZDweA2XAZwzW ihcIzXNrrcUEwlpsaoWgM7kT5QYmJa3SRtWJsbcLmaJD9PXmurnQIkWy9TKI1d49a4c9SlPyxykh a1RYJmipat1PZrDApFbC7GGkkkwYbDzPb29OMH9Gw0V+gOw6vaJKJxkvS8ypHDITK2EEVaLiim8U rzLYZSLJrMecTOpWzNZaKnRSa23XUkLtnZwSQIlc3pKn76M/x/D9CxSIhvLzVnSa3FgrF6OGA3DH q8rmtNOBb6VIyOrFSUjNIuvvwhZrqWyA6sImphIuBxrk+lkt9cvlln+OWbCYjmaQcKX21qe1O6Y/ ZfYVniyb4g7mi2+Q4lqUTcZ4nje1X0sFwsAKYSVNRtWak11Urv6lNK0ZLDGhUIlQ+f5pgZbEOyMO gF/m606U5Mpir3lOxNX1U2gfI8P9bt+PetE7hJidL8SnTj9Git8O4zx168WBHw+iD1TjU4sfPess 4DD2WRyd6PEcq5wnVljyQlLPEpNBJqQmVmFOuqeCnSBCNxcdkrIryJFvifPteixLYvMuwxLwgTyU 3PUJmcOtzGt3seP6kfv7dpYvMqkMlgSPpNFNAttkVp8KtF2SOk3T1NrEeH4iXKK07dvabrT/UTKt ndC80luU9OdK6+xPpSoojK0TXhL542W7ohACYT1B4mbFUVFIlmnKlBJId1NbXNAVJlY27di5akVs xcONKhZ2Yz+AVFJlSLC3wg6To/RrVFuRvKYXU8pYI5U0ySilRh9GF+apK/Oj2tHWcDKBDHlK4H6I Msnr1Jb5NfF/lEig8UFjj979rx3DpLCgCYbC3PFBZ6IirTQ7JJ6YnXwqoKbS6kTRRGrS1uqdsCnk Go/wF3hfu3JN62JF4KkEB+k/RFNXRLvJ7FAvOmgkbApKBj+SYRD7fedhhoamR1JfAdqm8I8b4PFD JexYucWVqom3wKIrux2Onu+T/5rxDUIw/PsowyHtB3eHpp1/8YbM9usw9FkIhTcIBk+Xubeg9/8H SkxIKg1lbmRzdHJlYW0NZW5kb2JqDTM1OSAwIG9iag08PC9SNyA3IDAgUj4+DWVuZG9iag0zNjAg MCBvYmoNPDwvUjkgOSAwIFI+Pg1lbmRvYmoNMzYyIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29k ZS9MZW5ndGggMTEzNj4+c3RyZWFtDQp4nKVWTW/jNhC961cMfEkXiFTRH5LcW5L1BgG6qZu46KHo gZZGNrsS6SUpJz62v7xDSnKcrDZFGjmxE5kzfPPmzaO+QhwxiN2r+8zr4Me7FDYmYOBeehPMZglM Y/rNphmks3kGGoMycKv9918D5jNA95HXcLmiLHOYR3NYlUGbmUFKP+kkYmNY1cEP8GH1V7BYBb8G bdhbMyUsGk99phtpUUu04UfNSwun181yn4RqjzrM4jFjKl/Di+ui2TTGwjhmqQM0mUXJhEpc/UwI ARQtKAosYK0FlpBXXItS5NwKJUGVMLKa51+E3IyiD2fBeBKlSTzugz9pVQPdPhb5NroYy6LZGNKY RVlbaOHqCwXaMhS7B75H+nhZXxjH7yB2MiMhZKd7glXPO/W2IibU8Pn09SLeJ4Qko3tJixXeAzXL oozN56cJh+hl74SbJNG4R0vyIvFqVTQ5aaxGY/gGAR/zLZf0RyH4RvMaRFWRRjWpTm7oZlmiRpmj cUgYEZvFrNccXWu0D4gSCHLEGHBZ9H8KCb9cXUKtChyQ63MwXALf7VAW4hEqYfzWpdKUg97rdgDs FsGgdYPQ7kBJv8XTlWVoObdQ8wMhBKpGmlpYS1v9J6w7rKkJxRMgg7kDYGC01GLP8wMt+doIjTVK a0bnMLpoCJy03agO4noW4mka3WPeaGEPcIXatoOOcI0StU8zNOSvwIPRLb3dLOFK1XUjOyzGZ3lB uFX6ALut5gYdHY7YJywUI4oOgumTnyapd9oDcGEFlkKKoz8RsUP7tYuVRsdQBcaSi9G9ih9QG+Br 1VjvnZ6Wm8Vi0X01SKSQedUUTiCL5cfXKXIIjzQVaHIt1i6wRW65qIyDTfVs6QsvOg/jOy3MqU2c +HLzIpFiNVa459I612olGRIDw5haY+edtWvspqrnf9cpy+Kj7RjhdBNzQT2ig6Ax+B02WsJYEs+j iScwmg4juGqPk8HOcbhTvIB76jz8RrdPmnhKZiFM3hjjglqMppcN5fj9/gL+XmPusIIwIJUMb5b/ DKRyQ0A5HN8U5xJfo7olI1H6S2s6/TYnwZ996JE440g3uXCpaHSA0wjlVXubE64d126czpyf7gU+ nA3S54+Hc0+bz6xdoQpaAv6ns5PtjtNpxGapN96LXoCX77ByNomj6bO0ETXU+7aBW0SnLdcUMKq0 D1xTq0hQqDtZclcUtUbVNBAORjibU77wSEjRE9JdT2ruErmgF5JaUd/adTvg1NLCtdX5qhOZgbWy W9/b7jjwU39myHcOxtsAkf5tTz5fXPW+sHYzUFU+h5DdoeWzd9YGOR0b5O5krNRp5EZUh14vazep 7knq0MYcnK5oOT52p0tPDC/CrcpbdANzQ3ZYiHY3dx7xY9yW68IT7Zk9JYxY3lWCbOEnSpfSc2Nf 3hKtJhNqzgFdZVFP9uJxRyeDgU+41g0na2bZuXtEzJ4/O/6xdMf1OPuzl2YSJfDQienumrZyOkqT iCVQB7Px7OnfKrin9f8CKTAhTw1lbmRzdHJlYW0NZW5kb2JqDTM2OSAwIG9iag08PC9SNyA3IDAg Uj4+DWVuZG9iag0zNzAgMCBvYmoNPDwvUjkgOSAwIFI+Pg1lbmRvYmoNMzcyIDAgb2JqDTw8L0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTE2MD4+c3RyZWFtDQp4nJVWTXPbNhC981fs5NKmIzGi bH25J3+2nolr11JPnR4gcCkhBgEaAKUoN/uXdxek5CiR8wFJIxEEHt7uvrfiI/TSDHr8ar9lmby7 H8HCJxnwyy2SwWAIxz36jI/HMBpMxuAwKRJeHe8/JllEgPZLlnA2I5QJTNIJzIqkQc5gRO/RUZr1 YVYmv8Lb2Yfkcpb8nTTbfhZpmKX944h0bQI6g6F74UQR4PNxfbcadu0KXXfc62eZlXP4YpzWi9oH 6PeyERM6GqTDIwpx9p4YAliA2RJBLlUFJa/zdVVZFyDQbOHwsUYjNzAXJvdgDayXSi7jTYeLWotg 3dtfkixLx+NetgWl4VDaskTexYtrj2ALuJ5Ngedro6QIyhrfgcI6wI+irDQvU2YB15eXlwTaIlFc aZZ1b8/PQIsNug4oA1dOGIknMBiPBjd/foJgYTDp88+UdvaP0tGw1/+hGJdCF10nAkJpc4QnnlMx 30KD1FY+HIzPL22tc5gjiDkRp/PpZ65WKkea3UBY2+fvUAkUgy8V0alQBleXUAr/0DAkMMpTpZUw gcGZ1ZtZu+Ewoc9B3lDpbBl3cTLbHFYguCL0CfA0rwOlvUKn+Frol4SjWSlnDU9T8azGmB1LYG6t PH4vrK8zswu0rvjy+DgdQ35WkpbQsDI4YQdjYv7/TGHB+o58uPRx0qhA26aBmJGESJwt9tFRRFbm JZzL2tkKf28CYNWS7Li01uQqShBEVenNgajOl8Is0INB5Kra5mzy4dq6B/BByAcmxMpk7Zy0Z1Iy 7pYbTwrXjWJPXsj89qUU2RiMeuvC0i4is6ud625qHRT74lRK9P5gjmg83V5d3DxT3aTN2T9M5kA4 h46nKnmMaY0+iBb4eTPQeGkVyv+AD15LBe3izkB7JSXfoPaxuK2mhNZ2ve0nrzGhNrNUC641lsp7 qjBUdo3Op3wgsSvFBpitcjFMVWx7EQnopVKt/HZdbgO5LYWiVa7WLDpVbLUbFz5wh9asQTTU0iTu QVHqKIPsUT6OUH1wSsZTida0pp66TyVmhJaxq78ixWi8rLsD1GLtD6f55vT8kApPtaZEGLHA6KvC UWvw1BVQyNiVP1hlOqBRrLDxV7SPf34t67tc81pq/lgxwZ3IcuW5G+TUcvhWbPrtmbbYi8/X87Cp WPJhCzdTJcv6NKc2EKgDNQ0sx0IZzj+SKF7X2F9cEOk2DZ8H3AAdXSK5Ld+x4zqme+m5I2+TL74T FXVPCqQkEsKzh0TeXVr5WorYUp32L46ruFY6l8LlcDadXl/AU1Gc7L+/bZyiNo2AiJiOliHtcdkY XzAoPJ16b6WKWoF7NqgP716jd09iIzR8jsFygURNNE1oNUlo+9dbwHuk9tnZKyJ1Tq2RmieBkcuM DSB5Jv9mRI34moazIruQV4Vei42PPYqi68HTJ3RNQxlM0uMIcYeBfCLrDtAiodMth8uPFTncwxXO XS3Iv9m4w09BY9gb/96RB6A/+Y8w48PaMB3Cun1ku/8jGWX8tDYaptkQymTQH7xc6mRK6/8HkHMM aA1lbmRzdHJlYW0NZW5kb2JqDTM3NSAwIG9iag08PC9SNyA3IDAgUj4+DWVuZG9iag0zNzYgMCBv YmoNPDwvUjkgOSAwIFI+Pg1lbmRvYmoNMzc4IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggMTM3NT4+c3RyZWFtDQp4nK1XTXPbNhC961fsrU1HYkTZ+joqtttoxvlorPbS6QEiIQkN CdAAaIf/vm9BkJJtTduMS9miSAIPu2/f7oL3NE5SGvMnnrNy8PbLnPZukBJ/7H4wnc7ocoz/xeWC 5tPlgqwc7AY8Ojy/H6QBgeIpK+ndBihLWiZL2uwGLXJKc/zNL5J0Qpty8CO92fw1uNkMfh20074X aZYmk8uAtNZeWi396NqKnafTY/35YTYyD9KOFuNJmppsS8+OVb2vnafJOJ2zQRfTZHYBFze3sDAc PxFtVKn0nlY5gLxyspTa086KUroh5XKntMxJafIHSbipcx4wJHcwdZG/+WGQpsliMU5PQHFsJbm6 qoz1Mk+wBubiUloqRIPvdjKPEttCkjfkrdrv+UmdHQB6RGotIVkq55TRJHTO463EDPkgYdnO2FJ4 fpYZ7UW09wmIlZlUD7h/zlmXYGwfq++O+mw2S9qgr+ChztU3unpF9NOLcXJ5Agr2rqVTe01XRjuV Sxt8dbzEaLrE2NHkIpnPxhieB5eZbAjm0divrg/gtiGIJEnT0aerdyQsE0el0A09isaRAy+FsMys QaAtoz8LbA9pdkELLRztBGY2sHIdJGJsMwyPpc5E5eqijQzmsFpjUFizp+ZknRpwvzm1hYFMFV3u QML0DomN/VfT3ptHSMW2hh3U/kCl2apC+WYYcZy3BroolP5KwjUl1NUEqbUWHSBkVpeWWbCkFF+h yeNS7EVEChAcL7VTmdC+aChXu520bVqZMtocbexMh5WrwplgYkQStTel8dAtiaoqgBYCTweBO66S Ga8Aad/XyrZCJqQCbhRKPPNOZrXFdfCosupBZIjS40FlB9rVNtgj8rxjvBLIjQyhC3NaTiPSSdDY 0ddlzhTCRT0KMr9K0lckzWKRLNLl8gkiGP1dwkXUl/V1yJZ03o56njCrI9G9kiKtgY9aq/ta4lZl pQPPvRqlAIFmdyZZME1BlyaXHNgsMzZH3SnAuoCkWqtKLs0QPXJae8SyzVLhqZDC+U7gul+/H2dj RUVQg6o6LbR2AeBmc7cOscbv9c3NTcRKZ+PlEcWdmIJ1FeTzYXXFOoCXLi4K9ZptrKks3oj0VPn0 cX3FSuhpbTlY/Qc82MAGPgN72VVUyQmgPAPspeaKAAfKuvCqKmTvx/racV3LhJMcn+75S/FikZBy VMrsILQqHYu/tzGS1BwpihAKjDPdLBaMiwlzTHDGZebfIhE9oLUpzJ65Vr2k8tclzcVsmaTcw0PS TP6HpDlFBCdfjvUDv4/F5R9TiOWYNxoFNxMFiGFS99xpvamYgmb4rIg+cHlqy7A8lz9WaFcq77ky QcixgVvekvRko7pKrQUh1/YHj0c8knvayJtRDFhocZkpS8Q2JohvKt7acA1/IT4uau5p+Y5AZ4v4 yfR2KmsKC4Y2FaXlyq6F6X2f1GcXpg+/3W26fdPZlgQWK3ai887LEmNF0Y66r0Wo+mh8qCxd4uHL FLXv904ts2EzdSZpn9vVWtE3MXemhbnGwY6QQK2j8mX+mtrz3qVr0LxRk988Xwp6Jxz62J20DyqT OPtQ3pAwpYSpx61cZQWEk3FNjnXt1NDcIMu08dz/GmY4AAMvlmtujZBmxHqxJgtF7IPS273MsQkO X6x19351exuRPn7aUI11tmgG6M7nBdCmPufD7QTdOKwaqTypz5HPiPRUDQIOFfwmIEKfihgcwAVe OqZxU/8ZIpEuq4cEj0SRdPvfm28V0tjRz3Jra4EdTboY8lvB4unrwh+fQQFdjP/sKtQsmdFjLC1f fhnMU64q81mSzqkcTCfT42UxuMP4vwFc4OwTDWVuZHN0cmVhbQ1lbmRvYmoNMzg0IDAgb2JqDTw8 L1I3IDcgMCBSPj4NZW5kb2JqDTM4NSAwIG9iag08PC9SOSA5IDAgUj4+DWVuZG9iag0zODcgMCBv YmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMzA1Pj5zdHJlYW0NCnicpVZNc9s2EL3z V+ytzYzFirL1dXQcp/FMPtxYPWVygMilhBoEaACUzN7aX95dEJRsSc7UE39Ilgks3nu7+xYPMEwz GPJ3fM+r5LevU1i5JAP+tqtkPJ7AxZB+ZxczmI7nM7CYlAmvDs8fkixEgPiWV/B2QVHmME/nsCiT LnIGU/qZnqfZCBZV8iu8WfyVXC+SP5Ju22sjTbJ0dBEi3WiPVqMfvLOi9PD06+Z2MxmYDdrBbDjK MpMv4eDrslk1zsNomE0Z0Pk4nZwTxcVHQghwtRZaowKX07vUK1givxbSiaXC4iwcAHwA3FxfXwOd kmbZ4MvVW/j0593izS9JlqWz2TDrA8qqVlih9iCgwpzCS1dBaSx4K7SrpCcuIHRBIucoObA3kBtN f62Q/xYUlCPlpqqMhrxDmNJ/R+fpdDIc9UddNn5NB8lceEkLtfERfW2ckwT/p9BrFsFbuWw8Fk+o MML9wfiUlmNeEX3PzsFW+rVpPNAecE1dG+vBlCTPuw9Xt+DQ0qoT7BayovWtztfWaPn3IUexEVKJ H5M85sesn6VoLVdr2qhES68H+ToBIJJbot8i6iPu/4f158VtjPIyddpzmC8l9X1P3bUVkvqvZx7L GiqhxaqTYMfZEfiHBp0PR+T32mypAbpVDozd5bVWEt1rUK/FJsQEt2YVisZ2yWSBDzkcAz+o2SfZ KwX1ddhemaVU0reniTHWnQ+92tEuZtN0zoZBRnSVnv+Eqc1m6Sybz59FTCkzjfKSOIFkmytFjo4P GWTTbvlgp3PR62wRBP2SazhZYCenC0U7okyRHPY4FbvoHPxA41zYwkFNOdjgWuYKCdZ7CoQiX/f/ Ai/ug7kIyqHUYI0ouAHKkivRaIwF8uK54RTC3KiCChnKRqkWhFKGbaQI6D9TVdzs2kOU6NtBbiU7 jQp+2OjodgTwUrdg/PqEt1Wi5RMah70bcfBurW9r5EaMyF+o48oUYZWpo7phyxodxjBbaVGhc0+S BtKxPx1XMIknLHEtsJSamLboCf4XjdGou9Kl3d0gCCntpA+KCbaWyEPqAmukFypwGohbY+/3CM6C 6XCf1ZhLIgefLq/gsigsA2V7okfoYygiFHpHdM+ppVnSjt0PcAU/Q/ayGKdT5ZQeDBwc1QwVzxFY +KfTqmOVq6bg4vInPGS/hRMKyzaWSSyQflqeLBP3b8oJlezHSgWHI6B7gZRZ0as3MQhq11jSkcsF HwU7zRlhEp6qPr9H8sEKBTsPPRe7xqBmKGlEeO7JGEjkvhFc344zRZCZmBWFNLyaP4QdZ9ytIX7V m0BuarLXZ/ISUZpEHYJ+wgQdqmPnCL7gLYaW4gT0zdSloQvCmvASVjzU2XH2YvKQup1CxSDHSawb R+mnAUdBpHM0PrhYGLOoaU7Em0mYri90Wm3lRuRtn5o4bUr49j04fdvJI/vu6ymfuLo814DmFJU1 RYtSCXKLEx3TF+huuummWqINymw4d3cfLj9+pEak2nv2lGc5VVSHan922rtgyZYYGpDH0IqzwQ0Y G8x5kqQIXeUF1wE+8hWXytcsu2uBi4G2vV+GwR060VKy+OZlVBdU4xY2QpH4Z+Gz38u6u69o8p5O WLqyFKbqL1S78Mo4z+DH8/QiSHqLVEYubwgbVbZK+/v09WNNeXLwHpe2EbaFbHbGt+vZ82v3t1sa xHCefe+H7ySdwDZOza+/J9OMB+Z0kmY0vpPxaLz/qJI7Wv8fxfrgag1lbmRzdHJlYW0NZW5kb2Jq DTM5MSAwIG9iag08PC9SNyA3IDAgUj4+DWVuZG9iag0zOTIgMCBvYmoNPDwvUjkgOSAwIFI+Pg1l bmRvYmoNMzk0IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTE0OT4+c3RyZWFt DQp4nKVWTXPaSBC961d0ccmmSowRH5LYPWEbe1NlZx2jrT2kchikEcxG0sgzIzD59ds9EjZgDsla QCFpel5/vNctPcGABTCgT/eflt7FYwQr4wVAH73yJpMQxgP8xeMYosk0Bi283CNrt/7kBQ4Bur+0 hMsEUaYwZVNIcq9FDiDCbzRiwRCS0vsNPib/evPE++K1234VKQzYcOyQPlVW6ErY/rXmuYXD49PD JuyrjdD9eDAMApUu4eSYNavGWBgOgogCGk1YOMIUkzuMECBZC6i13PB0h1k/NVKLUlTWgMrhs6oQ HwzPhd31Uy2tTHkBqSrLpsJTK1VlPn7wgoDF8SDYQ8qyLnZg19yCzIFDuubVShBgbUSTqWpX4lWa Ntr46LNqyqXQslqRBS8KUHYtNMI6LMo856kwsPhzdneHBka1mxmavFT3l3kKo5gNYlfdKzZ+B1Nx zOJgOj0EZAD3syuYZZkWxsCtqIR2xSI3/SBqN/SHIxaFA9RK5lL9Zy0qyISRq4qKgUVw5AKRC0gu C4L+X1eXwDvYktc1GvqwFbCVRUHgJ0xwYxqstaOC8A6iwoLSpj05WeMY2Aq8lYlcViLrGOgdMiQ2 pI0ea3WD3bKUKBXNq0yV8ofInAd+7GHNN6LDohhyVRRqS2DoWvMU+ZUGhWV+R6OXkrTxK4BLaaF3 p1B3F7eFWvKiB0ZgNgp6Bd1FpfGsxIohiNAi67HO137v36RUYy/um8K6s1eAbulwyzhERZZcOgpc cp0x77KEDS8a4UNjyOLlbluit72Ax6qlX+mWh1IIRKVKnLbb1/8v6NEkpKkzweaeBFMnwsebq/Eg Dt+h7NE0YtER5jfmFDwahrhwql9SxJbvqFiUY5tipwyn/uOEpSFLLSwWm8pOxT4j4VxjdQlKNbZu rJsRYKxWWP01N2vImyoldB9Mk65R8jQohpPQB8u/O47MyywhAA64SN7A6Qf5TTEI3/noVRhsRRo7 7F90iYunA8kHzI0EIGq0wpTaHFtjyLgVzsDKUhwjvOmn9w2y8XjAxlE7eGZ1LapMPsP1O2gPRgh4 BIvt/mk+n3dDCO6xKHyF7Z0gvaaU1mLjI4k0nEqVCaeRyRRBTiVyg00gq1zpkreUdXNpX6QtPWJo pNm1bBWCiwV2Ni1SCGcE0gVV7oNqmwx1uETc8wH6IJlgsMWB23GSKRsEuDxDKW24M0ck3QjaxmGR zM5PJ9I8Ljp/qIEMTyqMghSOyuUYFEVumqXd1QJmTqgkC5+ejK0k3g6MFhCFhj+D3pPFDSRYIe2/ IOElyWeW4bPBSuMc/vFzEaaqwu4puvB8EM+pqIkGZcRhsA+L/gOOav9siFc3/TllQQpvz6EuGoPn s/T7TwaCLcLPFOkab/vwuUHX8EUtumt0dDYQsiBbduJz1mBC2nx4fdzR9vGQYe/T+oOweDttMH8c CQXbvyzNn2ucUAZuxFI3XO8giH16dYqP36m+PiDLMBp+27duyELYds32eOtFAfVZhEM5gtKbDCev l4W3QPv/AFIi7f0NZW5kc3RyZWFtDWVuZG9iag00MDAgMCBvYmoNPDwvUjcgNyAwIFI+Pg1lbmRv YmoNNDAxIDAgb2JqDTw8L1I5IDkgMCBSPj4NZW5kb2JqDTQwMyAwIG9iag08PC9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDY2ND4+c3RyZWFtDQp4nJVU23KbMBB95yv2rc3UqAjMLU92Eid2k3Tc mEwn0+mDjNdYCSBXQBr/fRcDvQR72nIZzd6Ozu5K+w0sxsGq33aNM+P9nQ9JYXCoX50YruvB0KI/ GAbgu2EAGo21UXvv7d8MvkeAdokzOIsIJYSQhRCtjQaZg0+f7zBuQ5QZb+EkejQmkfHJaML+F8nj zB7ukWZ5iTrH0rzQYl3C789s/uyZ6hm1GVg25ypewqtnXCVVUYJtcb8m5LjMcyjF6IYYkjXFF5Gv NMIcS41FXJ28MThnQWDxzud8Mh7AzWwRkamVYSHiVOxaxZVcm0WlzYdnLEuEAcxSNFdoXmqRx0gO Ieeh1To3ShJsh/meZXe7zDcqx1N45zjcC60gtG2nT2WSCZme/mLNOtajGAVba4p4leBHsZQpnGEu MqH7gLeqojxgVtTAcJ9LKmUhyy6zW6VVHKvjbG1ue74VOMTWO0p32ezuO6OkVrBYZX2iH1CrDGEq UGt5AKrS2MTV0kJtN1KY47yUW5XKglQWVW34zzUeho5lBdwZHiXd8GENnxE22x8s8flGy6KUIodp JUvMRB/zUssVlXkq9FLpAXwe05kIbLc7E/dswcasz7elsmlgR+3K6CocqJ/KE3O6U9UT3CD2KSxE nmS7Kk/6XXb4oDUjgawEmolMB3BBAjXOTKru4G/ITmnWEZbntdo73FbLVMag1nCtNIqjeTwS4KZm OCqyiomYPR2oZrSRVPEdTHRelP00HtSVulZ/6XO7X9lAMayhRjuVqCfVdHDoM5eH4d6/u0IDwBJE yrrBMXnZSjLAJS51JYgRDwb1GAn+nC9f5iJBcJyvBLufdh7z4Hs78+6uDJ/X4873GAVmhktN/ymm xoL8fwBjZWrDDWVuZHN0cmVhbQ1lbmRvYmoNNDA2IDAgb2JqDTw8L1I3IDcgMCBSPj4NZW5kb2Jq DTQwNyAwIG9iag08PC9SOSA5IDAgUj4+DWVuZG9iag00MDkgMCBvYmoNPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCAzNTI+PnN0cmVhbQ0KeJyVUU1PAjEUvPdXzE2JUNv9Xk6iYmKCCejqxXgo S1lrllZLF+Xf24XF+HHyvTYv6cybTl/fwCgHa7Or5Yqc3qao1oSjTVuROE4QMb+zKEMa5xmsJEvS snf4G+E7BXSlXOG88Co5cpqjWJK9MkfqVxpSHqBYkWP0ihcyLsiM7Nv+q5RwGkQ7pWvtpNXSDS6t WDp8j+vpJhmYjbSDjAWcm3KOXzFqqmbtEDCetobCmCahf2Ix8Q6BwugtJqp3RDinWcb4AZjK2jij UcjyWZvaVFvPaQHOEoaJwGgjtVoI3DnaITem0U4ojQcl3/u4ELVaGquV8FgesSjsePdaObnwjcLJ tT8LQpomLPi6+dloOcQJT2IW5nEaxslfe+OVUPUQ3uGW1uqsq54XBwFN91pT6axcl00f0kHU9DCR 8cer8gCu5Nw2wm7Bs347n+zn4B6nopIIoyevuvvGGfkE2nKLtw1lbmRzdHJlYW0NZW5kb2JqDTQx MiAwIG9iag08PC9SNyA3IDAgUj4+DWVuZG9iag00MTMgMCBvYmoNPDwvUjkgOSAwIFI+Pg1lbmRv YmoNNDE0IDAgb2JqDTw8L0RpZmZlcmVuY2VzWzEyOC9iYWNrc2xhc2gvcGFyZW5sZWZ0L3BhcmVu cmlnaHQgMTYwL3NwYWNlXS9UeXBlL0VuY29kaW5nPj4NZW5kb2JqDTQxNSAwIG9iag08PC9MZW5n dGggMzgxMS9TdWJ0eXBlL1hNTC9UeXBlL01ldGFkYXRhPj5zdHJlYW0NCjw/eHBhY2tldCBiZWdp bj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+Cjx4OnhtcG1ldGEgeG1sbnM6 eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuNi1jMDE1IDg0LjE1 OTgxMCwgMjAxNi8wOS8xMC0wMjo0MTozMCAgICAgICAgIj4KICAgPHJkZjpSREYgeG1sbnM6cmRm PSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJk ZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6cGRmPSJodHRwOi8v bnMuYWRvYmUuY29tL3BkZi8xLjMvIgogICAgICAgICAgICB4bWxuczp4bXA9Imh0dHA6Ly9ucy5h ZG9iZS5jb20veGFwLzEuMC8iCiAgICAgICAgICAgIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvbW0vIgogICAgICAgICAgICB4bWxuczpkYz0iaHR0cDovL3B1cmwub3Jn L2RjL2VsZW1lbnRzLzEuMS8iPgogICAgICAgICA8cGRmOlByb2R1Y2VyPkdQTCBHaG9zdHNjcmlw dCA5LjA2PC9wZGY6UHJvZHVjZXI+CiAgICAgICAgIDxwZGY6S2V5d29yZHMvPgogICAgICAgICA8 eG1wOk1vZGlmeURhdGU+MjAxNy0wOS0wN1QxNjo0MToyMCswMjowMDwveG1wOk1vZGlmeURhdGU+ CiAgICAgICAgIDx4bXA6Q3JlYXRlRGF0ZT4yMDE3LTA4LTIxVDEzOjAwOjUwLTA3OjAwPC94bXA6 Q3JlYXRlRGF0ZT4KICAgICAgICAgPHhtcDpDcmVhdG9yVG9vbD5odG1sMnBzIHZlcnNpb24gMS4w IGJldGE3PC94bXA6Q3JlYXRvclRvb2w+CiAgICAgICAgIDx4bXA6TWV0YWRhdGFEYXRlPjIwMTct MDktMDdUMTY6NDE6MjArMDI6MDA8L3htcDpNZXRhZGF0YURhdGU+CiAgICAgICAgIDx4bXBNTTpE b2N1bWVudElEPnV1aWQ6ZmFhOGE5NzAtYmVjNy0xMWYyLTAwMDAtOTkzMjQzNjI2MjBiPC94bXBN TTpEb2N1bWVudElEPgogICAgICAgICA8eG1wTU06SW5zdGFuY2VJRD51dWlkOmUyZDU5M2M0LTNk OGQtYzI0NS1iMGZhLTkwYThiNDM4YjY1NzwveG1wTU06SW5zdGFuY2VJRD4KICAgICAgICAgPGRj OmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgog ICAgICAgICAgICA8cmRmOkFsdD4KICAgICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1k ZWZhdWx0Ij5kcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMDQgLSBUcmFuc21p c3Npb24gb2YgSVB2NiBQYWNrZXRzIG92ZXIgSUVFRSA4MDIuMTEgTmV0d29ya3MgaW4gbW9kZSBP dXRzaWRlIHRoZSBDb250ZXh0IG9mIGEgQmFzaWMgU2VydmljZSBTZXQg4oCgSVB2Ni1vdmVyLTgw MjExb2Ni4oChPC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOkFsdD4KICAgICAgICAgPC9kYzp0 aXRsZT4KICAgICAgICAgPGRjOmNyZWF0b3I+CiAgICAgICAgICAgIDxyZGY6U2VxPgogICAgICAg ICAgICAgICA8cmRmOmxpLz4KICAgICAgICAgICAgPC9yZGY6U2VxPgogICAgICAgICA8L2RjOmNy ZWF0b3I+CiAgICAgICAgIDxkYzpkZXNjcmlwdGlvbj4KICAgICAgICAgICAgPHJkZjpBbHQ+CiAg ICAgICAgICAgICAgIDxyZGY6bGkgeG1sOmxhbmc9IngtZGVmYXVsdCIvPgogICAgICAgICAgICAg ICA8cmRmOmxpIHhtbDpsYW5nPSJ4LXJlcGFpciIvPgogICAgICAgICAgICA8L3JkZjpBbHQ+CiAg ICAgICAgIDwvZGM6ZGVzY3JpcHRpb24+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3Jk ZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9InciPz4NZW5kc3RyZWFtDWVuZG9iag00MTgg MCBvYmoNPDwvQkJveFs0MzAuMjI5IDQ5Ni43NjIgNDU0LjI2IDUwOC40NzhdL0ZpbHRlci9GbGF0 ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA3NC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIC00MzAu MjI5IC00OTYuNzYyXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5 cGUvWE9iamVjdD4+c3RyZWFtDQpIiUTIsRGAQAhE0ZwqqIBZbgG5Csy9NjS2fTXyR28+rGcjXGHO tw/Ds5p67AKrxNRbgjQyShNuvdXQSyLdPIP/O2XJI8AAhYMPww1lbmRzdHJlYW0NZW5kb2JqDTQx OSAwIG9iag08PC9EQSgvSGVsdiAwIFRmIDAgZyApL0RSPDwvRW5jb2Rpbmc8PC9QREZEb2NFbmNv ZGluZyA0MzQgMCBSPj4vRm9udDw8L0hlbHYgNDMyIDAgUi9aYURiIDQzMyAwIFI+Pj4+L0ZpZWxk c1tdPj4NZW5kb2JqDTQyOCAwIG9iag08PC9CQm94Wy0wLjU3MjgxNSAtMC41NzI4MTUgNy44NjMx OSA2LjMwMDldL0ZpbHRlci9GbGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA4MS9NYXRyaXhb MS4wIDAuMCAwLjAgMS4wIDAuNTcyODE1IDAuNTcyODE1XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiTJQMFAwVAhy5zLQMzU3 slAo5zIAixSlgxm5XMZ6ZiamRkAmlGGkZ2FmAuOY6gH1GCokc2GTNFAw1zOyNDABMpK5MrjSuIK5 AAIMAIefFOUNZW5kc3RyZWFtDWVuZG9iag00MjkgMCBvYmoNPDwvQkJveFsxMzMuMjMzIDM2Ni4w ODEgMjQwLjQyMyAzNzcuNzk3XS9Gb3JtVHlwZSAxL0xlbmd0aCA1OS9NYXRyaXhbMS4wIDAuMCAw LjAgMS4wIC0xMzMuMjMzIC0zNjYuMDgxXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3Vi dHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQowIDAgMSBSRwowLjY1MDkgdwoxMzYuMzM5 IDM3MS4xOTUxIG0KMjM3LjMxNzUgMzcxLjE5NTEgbApTCg1lbmRzdHJlYW0NZW5kb2JqDTQzMCAw IG9iag08PC9CQm94Wy0wLjU3MjgxNSAtMC41NzI4MTUgNy44NjMxNiA2LjMwMDldL0ZpbHRlci9G bGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA4MS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAu NTcyODE1IDAuNTcyODE1XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3Jt L1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiTJQMFAwVAhy5zLQMzU3slAo5zIAixSlgxm5XMZ6Ziam RkAmlGGkZ2FmAuOY6gH1GCokc2GTNFAw1zOyNDAGMpK5MrjSuIK5AAIMAIeTFOQNZW5kc3RyZWFt DWVuZG9iag00MzEgMCBvYmoNPDwvQkJveFsyNDAuMTUyIDM4OS44NDEgMzQxLjQwMiA0MDEuNTU3 XS9Gb3JtVHlwZSAxL0xlbmd0aCA1OS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIC0yNDAuMTUyIC0z ODkuODQxXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9i amVjdD4+c3RyZWFtDQowIDAgMSBSRwowLjY1MDkgdwoyNDMuMjU3NCAzOTQuOTU1MyBtCjMzOC4y OTYgMzk0Ljk1NTMgbApTCg1lbmRzdHJlYW0NZW5kb2JqDTQzNCAwIG9iag08PC9EaWZmZXJlbmNl c1syNC9icmV2ZS9jYXJvbi9jaXJjdW1mbGV4L2RvdGFjY2VudC9odW5nYXJ1bWxhdXQvb2dvbmVr L3JpbmcvdGlsZGUgMzkvcXVvdGVzaW5nbGUgOTYvZ3JhdmUgMTI4L2J1bGxldC9kYWdnZXIvZGFn Z2VyZGJsL2VsbGlwc2lzL2VtZGFzaC9lbmRhc2gvZmxvcmluL2ZyYWN0aW9uL2d1aWxzaW5nbGxl ZnQvZ3VpbHNpbmdscmlnaHQvbWludXMvcGVydGhvdXNhbmQvcXVvdGVkYmxiYXNlL3F1b3RlZGJs bGVmdC9xdW90ZWRibHJpZ2h0L3F1b3RlbGVmdC9xdW90ZXJpZ2h0L3F1b3Rlc2luZ2xiYXNlL3Ry YWRlbWFyay9maS9mbC9Mc2xhc2gvT0UvU2Nhcm9uL1lkaWVyZXNpcy9aY2Fyb24vZG90bGVzc2kv bHNsYXNoL29lL3NjYXJvbi96Y2Fyb24gMTYwL0V1cm8gMTY0L2N1cnJlbmN5IDE2Ni9icm9rZW5i YXIgMTY4L2RpZXJlc2lzL2NvcHlyaWdodC9vcmRmZW1pbmluZSAxNzIvbG9naWNhbG5vdC8ubm90 ZGVmL3JlZ2lzdGVyZWQvbWFjcm9uL2RlZ3JlZS9wbHVzbWludXMvdHdvc3VwZXJpb3IvdGhyZWVz dXBlcmlvci9hY3V0ZS9tdSAxODMvcGVyaW9kY2VudGVyZWQvY2VkaWxsYS9vbmVzdXBlcmlvci9v cmRtYXNjdWxpbmUgMTg4L29uZXF1YXJ0ZXIvb25laGFsZi90aHJlZXF1YXJ0ZXJzIDE5Mi9BZ3Jh dmUvQWFjdXRlL0FjaXJjdW1mbGV4L0F0aWxkZS9BZGllcmVzaXMvQXJpbmcvQUUvQ2NlZGlsbGEv RWdyYXZlL0VhY3V0ZS9FY2lyY3VtZmxleC9FZGllcmVzaXMvSWdyYXZlL0lhY3V0ZS9JY2lyY3Vt ZmxleC9JZGllcmVzaXMvRXRoL050aWxkZS9PZ3JhdmUvT2FjdXRlL09jaXJjdW1mbGV4L090aWxk ZS9PZGllcmVzaXMvbXVsdGlwbHkvT3NsYXNoL1VncmF2ZS9VYWN1dGUvVWNpcmN1bWZsZXgvVWRp ZXJlc2lzL1lhY3V0ZS9UaG9ybi9nZXJtYW5kYmxzL2FncmF2ZS9hYWN1dGUvYWNpcmN1bWZsZXgv YXRpbGRlL2FkaWVyZXNpcy9hcmluZy9hZS9jY2VkaWxsYS9lZ3JhdmUvZWFjdXRlL2VjaXJjdW1m bGV4L2VkaWVyZXNpcy9pZ3JhdmUvaWFjdXRlL2ljaXJjdW1mbGV4L2lkaWVyZXNpcy9ldGgvbnRp bGRlL29ncmF2ZS9vYWN1dGUvb2NpcmN1bWZsZXgvb3RpbGRlL29kaWVyZXNpcy9kaXZpZGUvb3Ns YXNoL3VncmF2ZS91YWN1dGUvdWNpcmN1bWZsZXgvdWRpZXJlc2lzL3lhY3V0ZS90aG9ybi95ZGll cmVzaXNdL1R5cGUvRW5jb2Rpbmc+Pg1lbmRvYmoNNDM1IDAgb2JqDTw8L0FQIDQ0MiAwIFI+Pg1l bmRvYmoNNDQwIDAgb2JqDTw8L0JCb3hbMC4wIDAuMCAxOC4wIDE4LjBdL0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGggMzAwL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L0dTMDw8L0FJUyBmYWxzZS9C TS9Ob3JtYWwvQ0EgMC42L1R5cGUvRXh0R1N0YXRlL2NhIDAuNj4+Pj4+Pi9TdWJ0eXBlL0Zvcm0v VHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJ5JJNTsQwDIWv8i5QY6f5PcFISCwQS8SGIAZQZzGw4Pq8 9AcaMZwARar9ufFL/NozbF7vRyhemXzC44bxjXyN+wfFE64Od4rjB6vKZSgIokUz6glJkoc5iRZx wrDHCUMW98OkpKmRZf9NJtEX1I2HUfJoS+/MXsYYNiVSKnk9ZoWKPU3odnYi3QkV3QUmdLfrLr4f quIFz7ilD4fmh2Qr0Zoxq4MqUS+aeGH3Ye0I5c+OX363Cn1WMe+YMnGZEsq3zL3NYKEZyklKwWBS IkOQEEIrOjbSkNiCCZ+1oTrfBHJ0zaDCSXkEr9ogeEKZh6dMDBlGcykWJSWHUZxzG3iaO3/OBZME LU2EDhaJfOoaK3bF/eZeZyGOEtPSoPOq//DHe8SXAAMAXqW4ig1lbmRzdHJlYW0NZW5kb2JqDTQ0 MSAwIG9iag08PC9CQm94WzI2My45MTEgNjk4LjcyNCAyNzYuMDYzIDcxMC40NDFdL0ZpbHRlci9G bGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA3My9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIC0y NjMuOTExIC02OTguNzI0XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3Jt L1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiUTIuxGAUAgF0ZwqqIC5wONXgbm2obHtq5EbnVlIT2Mp Q9TfPphGtvO+ESQDwzdZlkBLueDS3osvsjKZqH+ddNAjwAB21A+iDWVuZHN0cmVhbQ1lbmRvYmoN NDQyIDAgb2JqDTw8L05hbWVzWyj+/wB+AGkAYwBvAG4AKwBDAG8AbQBtAGUAbgB0ACsAMgA1ADUA OgAyADAAOQA6ADAALQBFAFMAUAAtADApNDQwIDAgUl0+Pg1lbmRvYmoNNDQ1IDAgb2JqDTw8L0JC b3hbLTAuNTU4ODY4IC0wLjU1ODg2OCA3LjY3MTkxIDYuMTQ3NjRdL0ZpbHRlci9GbGF0ZURlY29k ZS9Gb3JtVHlwZSAxL0xlbmd0aCA4MS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuNTU4ODY4IDAu NTU4ODY4XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9i amVjdD4+c3RyZWFtDQpIiTJQMFAwVAhy5zLQMzW1sFQo5zIAixSlgxm5XMZAcTNTIBPKMNIztzQx gfFM9UwtLCwUkrmwyhoomOsZGhoD6WSuDK40rmAugAADAKWuFTsNZW5kc3RyZWFtDWVuZG9iag00 NDggMCBvYmoNPDwvQkJveFswLjAgMC4wIDM5Ny41OTUgMzQuODI0Ml0vRm9ybVR5cGUgMS9MZW5n dGggMjAvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8PC9FeHRHU3Rh dGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4vUHJvY1Nl dFsvUERGXS9YT2JqZWN0PDwvTVdGT0Zvcm0gNDQ5IDAgUj4+Pj4vU3VidHlwZS9Gb3JtL1R5cGUv WE9iamVjdD4+c3RyZWFtDQovUjAgZ3MKL01XRk9Gb3JtIERvCg1lbmRzdHJlYW0NZW5kb2JqDTQ0 OSAwIG9iag08PC9CQm94WzAuMCAwLjAgMzk3LjU5NSAzNC44MjQyXS9Gb3JtVHlwZSAxL0dyb3Vw PDwvUy9UcmFuc3BhcmVuY3k+Pi9MZW5ndGggOS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAw LjBdL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERl0vWE9iamVjdDw8L0Zvcm0gNDUwIDAgUj4+Pj4v U3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQovRm9ybSBEbwoNZW5kc3RyZWFtDWVu ZG9iag00NTAgMCBvYmoNPDwvQkJveFsxMDMuODU5IDIwMC4wODYgNTAxLjQ1NCAyMzQuOTExXS9G aWx0ZXJbL0ZsYXRlRGVjb2RlXS9Gb3JtVHlwZSAxL0xlbmd0aCAyMTEvTWF0cml4WzEuMCAwLjAg MC4wIDEuMCAtMTAzLjg1OSAtMjAwLjA4Nl0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGXT4+L1N1 YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlckTGSwzAIAHu9ghcwgADBezKTNE5z zX3/sM8OnrQrLVpJDITB6cxA8PMahG6U8DuEFjoHiCjyIod3IUP2KcUcXWxCkynIkww+2lS0MIHH 0Az0Nb3ZNowYWWK22OQa3t6V8BjPwVTLM+skFpQs812sNoSuYopL64QmQihGCu2J4CLjvSwcV3qe zL3KNLIE9tPkhCbHdF/Q3tEgX2FEqFziPYwEw0u9kcC56qVuF6qvEN+vKZyomdFsGyKMaeqXuVd/ yDm9vaPhP+xPgAEAlYxdqQ1lbmRzdHJlYW0NZW5kb2JqDTQ1OCAwIG9iag08PC9CQm94WzMyOS4y NSA0NzMuMDAyIDQzNi40NCA0ODQuNzE4XS9GaWx0ZXIvRmxhdGVEZWNvZGUvRm9ybVR5cGUgMS9M ZW5ndGggNzQvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAtMzI5LjI1IC00NzMuMDAyXS9SZXNvdXJj ZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpI iUTIsRGAQAhE0ZwqqIBhbwG5Csy1DY1t3zPyR2++W8/2gLqBqw8DWU09dnGr9KmPkMOYBY2tDVi4 JUgjo/53ySmvAAMAhWsPwQ1lbmRzdHJlYW0NZW5kb2JqDTQ2NyAwIG9iag08PC9CQm94WzAuMCAw LjAgMzY3Ljg5NSAzNC44MjU5XS9Gb3JtVHlwZSAxL0xlbmd0aCAyMC9NYXRyaXhbMS4wIDAuMCAw LjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JN L011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pi9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9NV0ZP Rm9ybSA0NjggMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9SMCBn cwovTVdGT0Zvcm0gRG8KDWVuZHN0cmVhbQ1lbmRvYmoNNDY4IDAgb2JqDTw8L0JCb3hbMC4wIDAu MCAzNjcuODk1IDM0LjgyNTldL0Zvcm1UeXBlIDEvR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L0xl bmd0aCA5L01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgMC4wIDAuMF0vUmVzb3VyY2VzPDwvUHJvY1Nl dFsvUERGXS9YT2JqZWN0PDwvRm9ybSA0NjkgMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2Jq ZWN0Pj5zdHJlYW0NCi9Gb3JtIERvCg1lbmRzdHJlYW0NZW5kb2JqDTQ2OSAwIG9iag08PC9CQm94 WzEyMS42NzkgNjk5LjA0OSA0ODkuNTc0IDczMy44NzVdL0ZpbHRlclsvRmxhdGVEZWNvZGVdL0Zv cm1UeXBlIDEvTGVuZ3RoIDE4NS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIC0xMjEuNjc5IC02OTku MDQ5XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVj dD4+c3RyZWFtDQpIiVSPuW0EMRAE/Y2CETTmJdnxHKBzJEeO0hdPul3OmiygeoraBFPZVZu07+ch 6ClsP4daIJLWhjnU09rXYgaRiMUSybbfrhCmtm25I4NsjyNmx6DPzT4XIyxmbnOT/+1tnfcfx0ep UoXl8mqVOoZwli5do5olyxS9c/xlrZ+nc7NXlsNl9kss4L29tbPg1tVJ+AjeukQxbR0oZMA9WMKE GJP9FnayGnaahbzXL+9qeJX9CjAAcmld/Q1lbmRzdHJlYW0NZW5kb2JqDTQ3NCAwIG9iag08PC9C Qm94WzE1Ni45OTMgMjM1LjQwMiAxODEuMDI0IDI0Ny4xMThdL0ZpbHRlci9GbGF0ZURlY29kZS9G b3JtVHlwZSAxL0xlbmd0aCA3NC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIC0xNTYuOTkzIC0yMzUu NDAyXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVj dD4+c3RyZWFtDQpIiTzIuxGAMAwE0VxVqALNnW39KiCHNiCmfSBhozcLqy4sKozz7cOgR03dN4GF o/UWBgxdqWPBnKGXMNOatf51yiGPAAMAZnQPYA1lbmRzdHJlYW0NZW5kb2JqDTQ3NyAwIG9iag08 PC9CQm94WzAuMCAwLjAgNDAzLjUzNCAzNC44MjU5XS9Gb3JtVHlwZSAxL0xlbmd0aCAyMC9NYXRy aXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwv QUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pi9Qcm9jU2V0Wy9QREZdL1hP YmplY3Q8PC9NV0ZPRm9ybSA0NzggMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5z dHJlYW0NCi9SMCBncwovTVdGT0Zvcm0gRG8KDWVuZHN0cmVhbQ1lbmRvYmoNNDc4IDAgb2JqDTw8 L0JCb3hbMC4wIDAuMCA0MDMuNTM0IDM0LjgyNTldL0Zvcm1UeXBlIDEvR3JvdXA8PC9TL1RyYW5z cGFyZW5jeT4+L0xlbmd0aCA5L01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgMC4wIDAuMF0vUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGXS9YT2JqZWN0PDwvRm9ybSA0NzkgMCBSPj4+Pi9TdWJ0eXBlL0Zv cm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9Gb3JtIERvCg1lbmRzdHJlYW0NZW5kb2JqDTQ3OSAw IG9iag08PC9CQm94Wzg2LjAzOTUgNTU2LjQ4OCA0ODkuNTc0IDU5MS4zMTRdL0ZpbHRlclsvRmxh dGVEZWNvZGVdL0Zvcm1UeXBlIDEvTGVuZ3RoIDE4NS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIC04 Ni4wMzk1IC01NTYuNDg4XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3Jt L1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiVSPOw4DMQgFe5/CJ0BgzMfnWSlpNk2aXD+stDbezh7x HgNVBKehRBXr910QVHDUX3G/uFVxBDH2+imuwCpBGLC51PV3EGarKzIQhsfAUXrM2Ij0YmewAa37 FtzIXZ25uf4or3RSBx0RTCcjoO59OZnGIazpZAMInR9Ok+1OM7iRuzpzc/3DSTQeLJuTRING/fxr B7OYyDMMWvMWPY0YJHySncEUkJpmMMmsztxcfzn9BRgAdd5csQ1lbmRzdHJlYW0NZW5kb2JqDTQ4 NCAwIG9iag08PC9CQm94WzAuMCAwLjAgNDcuMTM5OCAxMS4wNjU2XS9Gb3JtVHlwZSAxL0xlbmd0 aCAyMC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L0V4dEdTdGF0 ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pi9Qcm9jU2V0 Wy9QREZdL1hPYmplY3Q8PC9NV0ZPRm9ybSA0ODUgMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9Y T2JqZWN0Pj5zdHJlYW0NCi9SMCBncwovTVdGT0Zvcm0gRG8KDWVuZHN0cmVhbQ1lbmRvYmoNNDg1 IDAgb2JqDTw8L0JCb3hbMC4wIDAuMCA0Ny4xMzk4IDExLjA2NTZdL0Zvcm1UeXBlIDEvR3JvdXA8 PC9TL1RyYW5zcGFyZW5jeT4+L0xlbmd0aCA5L01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgMC4wIDAu MF0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGXS9YT2JqZWN0PDwvRm9ybSA0ODYgMCBSPj4+Pi9T dWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9Gb3JtIERvCg1lbmRzdHJlYW0NZW5k b2JqDTQ4NiAwIG9iag08PC9CQm94WzE2OS4xOTggMTY0LjQ0NSAyMTYuMzM4IDE3NS41MTFdL0Zp bHRlci9GbGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCAxMDYvTWF0cml4WzEuMCAwLjAgMC4w IDEuMCAtMTY5LjE5OCAtMTY0LjQ0NV0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGXT4+L1N1YnR5 cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlEzjEOAzEIRNGeU3CCEYMD2OdZKdskTZpc P05h0aEn/RFUw+RKUk0/txgybOlXWMSqGcp8oGrbW5gL4aO2FdzjfxwpRw2b2l0FOCP1EudARK22 17aE0bPLlrPe3fnhkqf8BBgAaasjEw1lbmRzdHJlYW0NZW5kb2JqDTQ4NyAwIG9iag08PC9CQm94 WzAuMCAwLjAgNDA5LjQ3NCAzNC44MjU4XS9Gb3JtVHlwZSAxL0xlbmd0aCAyMC9NYXRyaXhbMS4w IDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZh bHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pi9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8 PC9NV0ZPRm9ybSA0ODggMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0N Ci9SMCBncwovTVdGT0Zvcm0gRG8KDWVuZHN0cmVhbQ1lbmRvYmoNNDg4IDAgb2JqDTw8L0JCb3hb MC4wIDAuMCA0MDkuNDc0IDM0LjgyNThdL0Zvcm1UeXBlIDEvR3JvdXA8PC9TL1RyYW5zcGFyZW5j eT4+L0xlbmd0aCA5L01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgMC4wIDAuMF0vUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGXS9YT2JqZWN0PDwvRm9ybSA0ODkgMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlw ZS9YT2JqZWN0Pj5zdHJlYW0NCi9Gb3JtIERvCg1lbmRzdHJlYW0NZW5kb2JqDTQ4OSAwIG9iag08 PC9CQm94Wzg2LjAzOTUgNDEzLjkyNyA0OTUuNTE0IDQ0OC43NTNdL0ZpbHRlclsvRmxhdGVEZWNv ZGVdL0Zvcm1UeXBlIDEvTGVuZ3RoIDIwMi9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIC04Ni4wMzk1 IC00MTMuOTI3XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5cGUv WE9iamVjdD4+c3RyZWFtDQpIiWyQO24DMQwFe52CJ3gQvyLPYyBu7CZNrh9tAC1dpNxZzONATBPJ Fcw06fs5JsJn0c+wZSjWItPEZAl6byYwLyGzCYul9EEctcSpPUuYLKHHsBIs1dXstZmDM+3DbHLW b+80PMZXJ2Ze6fuvBFj3wntkQGNPScJz3znfapglRreiAbfFV1wopho323HhsMxqscmZbu+c/z+O DeJ7oeM4sOa+c8cKhEU7TgwRf3EaC1XuzV5D134en9pikzPd3jl/xf0KMAB9I2CFDWVuZHN0cmVh bQ1lbmRvYmoNNDk2IDAgb2JqDTw8L0JCb3hbLTAuNTc5NTkgLTAuNTc5NTkgNy45NTYwNSA2LjM3 NTM0XS9GaWx0ZXIvRmxhdGVEZWNvZGUvRm9ybVR5cGUgMS9MZW5ndGggODMvTWF0cml4WzEuMCAw LjAgMC4wIDEuMCAwLjU3OTU5IDAuNTc5NTldL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERl0+Pi9T dWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJMlAwUDBUCHLnMtAzNbc0UyjnMgCL FKWDGblcxnpmFhZGQCaUYaRnYWluCeOZ6plbmporJHNhlTVQMNczNjczBTKSuTK40riCuQACDADB 6xWbDWVuZHN0cmVhbQ1lbmRvYmoNNDk3IDAgb2JqDTw8L0JCb3hbMC4wIDAuMCAzOTEuNjU1IDM0 LjgyNTldL0Zvcm1UeXBlIDEvTGVuZ3RoIDIwL01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgMC4wIDAu MF0vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlw ZS9FeHRHU3RhdGU+Pj4+L1Byb2NTZXRbL1BERl0vWE9iamVjdDw8L01XRk9Gb3JtIDQ5OCAwIFI+ Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KL1IwIGdzCi9NV0ZPRm9ybSBE bwoNZW5kc3RyZWFtDWVuZG9iag00OTggMCBvYmoNPDwvQkJveFswLjAgMC4wIDM5MS42NTUgMzQu ODI1OV0vRm9ybVR5cGUgMS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vTGVuZ3RoIDkvTWF0cml4 WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdL1hPYmpl Y3Q8PC9Gb3JtIDQ5OSAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0K L0Zvcm0gRG8KDWVuZHN0cmVhbQ1lbmRvYmoNNDk5IDAgb2JqDTw8L0JCb3hbODYuMDM5NSA1MzIu NzI4IDQ3Ny42OTQgNTY3LjU1NF0vRmlsdGVyWy9GbGF0ZURlY29kZV0vRm9ybVR5cGUgMS9MZW5n dGggMjM0L01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgLTg2LjAzOTUgLTUzMi43MjhdL1Jlc291cmNl czw8L1Byb2NTZXRbL1BERl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJ VJJLjgMhDAX3nMInsDD+cp5IySbZzGauP+4egckOSv2eC6sJOgZNI4IOP6/W0bRP+G0RF3dQtTxw wKeFIZsmmTgsFNbdBN3ZYUfMcYz84NFECUmFi72TMVqfVMEiq7pya/yjPctJBCdnsJzEkSNkO+nA mGzlpIoswdlDMnB4zGLvZKlyNe5gkVVduTX+ckrLNI04pSjtvcsRXWC371R5iWcB8ZeXeDZYHF5F VnnlTq/9cGbsynrsihW1Z/3eHWEnltqVMIrFuHcVOGjGYnbtSvMncbEVnFDkv9qhcvd4uZX+BBgA KSt5wQ1lbmRzdHJlYW0NZW5kb2JqDTUwOCAwIG9iag08PC9CQm94WzMyOS4yNSA0ODQuODgzIDM2 NS4xNjEgNDk2LjU5OV0vRmlsdGVyL0ZsYXRlRGVjb2RlL0Zvcm1UeXBlIDEvTGVuZ3RoIDc0L01h dHJpeFsxLjAgMC4wIDAuMCAxLjAgLTMyOS4yNSAtNDg0Ljg4M10vUmVzb3VyY2VzPDwvUHJvY1Nl dFsvUERGXT4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlEyLERgFAIBNGc KqiAObgPAxWYaxsa274audGbhfU0livM+fYhPKup+yawSozeQoYxy3X12EyNXsIKQ2b975RDHgEG AIkiD/YNZW5kc3RyZWFtDWVuZG9iag01MDkgMCBvYmoNPDwvQkJveFstMC41NzI4MTUgLTAuNTcy ODE1IDcuODYzMjIgNi4zMDA5XS9GaWx0ZXIvRmxhdGVEZWNvZGUvRm9ybVR5cGUgMS9MZW5ndGgg ODEvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjU3MjgxNSAwLjU3MjgxNV0vUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGXT4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIkyUDBQ MFQIcucy0DM1N7JQKOcyAIsUpYMZuVzGemYmpkZAJpRhpGdhZgLjmOoB9RgqJHNhkzRQMNczsjQw ATKSuTK40riCuQACDACHnxTlDWVuZHN0cmVhbQ1lbmRvYmoNNTEwIDAgb2JqDTw8L0JCb3hbMzQx LjEzIDU2OC4wNDMgMzcxLjEwMSA1NzkuNzU5XS9Gb3JtVHlwZSAxL0xlbmd0aCA2MC9NYXRyaXhb MS4wIDAuMCAwLjAgMS4wIC0zNDEuMTMgLTU2OC4wNDNdL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE Rl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCjAgMCAxIFJHCjAuNjUwOSB3 CjM0NC4yMzU5IDU3My4xNTcxIG0KMzY3Ljk5NTUgNTczLjE1NzEgbApTCg1lbmRzdHJlYW0NZW5k b2JqDTUxNyAwIG9iag08PC9CQm94WzI1Ny45NzEgNDI1LjQ4MiAzMjkuNTIyIDQzNy4xOTldL0Zp bHRlci9GbGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA3NC9NYXRyaXhbMS4wIDAuMCAwLjAg MS4wIC0yNTcuOTcxIC00MjUuNDgyXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlw ZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiUTIuxGAUAgF0ZwqqIC5fB9UYK5taGz7auRG ZxbS0whliPrbB9Osdt43glRi+CYrFaylHA7JqeCL3EpCy/530kGPAAMAhY0Pxg1lbmRzdHJlYW0N ZW5kb2JqDTUxOCAwIG9iag08PC9CQm94WzIwNC41MTIgNDI1LjQ4MiAyMTYuNjY0IDQzNy4xOTld L0ZpbHRlci9GbGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA3My9NYXRyaXhbMS4wIDAuMCAw LjAgMS4wIC0yMDQuNTEyIC00MjUuNDgyXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3Vi dHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiUTIuxGAUAgF0ZwqqIC5fB9UYK5taGz7 auRGZxbS0whliPrbB9Osdt43glRi+CbDktLmcEhOBV9k6pK55n8nHfQIMAB2ag+eDWVuZHN0cmVh bQ1lbmRvYmoNNTMxIDAgb2JqDTw8L0JCb3hbLTAuNTcyODE1IC0wLjU3MjgxNSA3Ljg2MzE5IDYu MzAwOV0vRmlsdGVyL0ZsYXRlRGVjb2RlL0Zvcm1UeXBlIDEvTGVuZ3RoIDgxL01hdHJpeFsxLjAg MC4wIDAuMCAxLjAgMC41NzI4MTUgMC41NzI4MTVdL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERl0+ Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJMlAwUDBUCHLnMtAzNTeyUCjn MgCLFKWDGblcxnpmJqZGQCaUYaRnYWYC45jqAfUYKiRzYZM0UDDXM7I0MAEykrkyuNK4grkAAgwA h58U5Q1lbmRzdHJlYW0NZW5kb2JqDTUzMiAwIG9iag08PC9CQm94WzE5Mi42MzIgMzQyLjMyMSAy MTAuNzI0IDM1NC4wMzhdL0Zvcm1UeXBlIDEvTGVuZ3RoIDU5L01hdHJpeFsxLjAgMC4wIDAuMCAx LjAgLTE5Mi42MzIgLTM0Mi4zMjFdL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERl0+Pi9TdWJ0eXBl L0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCjAgMCAxIFJHCjAuNjUwOSB3CjE5NS43MzgxIDM0 Ny40MzU3IG0KMjA3LjYxOCAzNDcuNDM1NyBsClMKDWVuZHN0cmVhbQ1lbmRvYmoNNTMzIDAgb2Jq DTw8L0JCb3hbLTAuNTU4ODY4IC0wLjU1ODg2OCA3LjY3MTkxIDYuMTQ3NjFdL0ZpbHRlci9GbGF0 ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA4MS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuNTU4 ODY4IDAuNTU4ODY4XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5 cGUvWE9iamVjdD4+c3RyZWFtDQpIiTJQMFAwVAhy5zLQMzW1sFQo5zIAixSlgxm5XMZAcTNTIBPK MNIztzQxgfFM9UwtLMwVkrmwyhoomOsZGhoD6WSuDK40rmAugAADAKWDFToNZW5kc3RyZWFtDWVu ZG9iag01MzQgMCBvYmoNPDwvQkJveFstMC41Nzk1OSAtMC41Nzk1OSA3Ljk1NjEyIDYuMzc1MzRd L0ZpbHRlci9GbGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA4My9NYXRyaXhbMS4wIDAuMCAw LjAgMS4wIDAuNTc5NTkgMC41Nzk1OV0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGXT4+L1N1YnR5 cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIkyUDBQMFQIcucy0DM1tzRTKOcyAIsUpYMZ uVzGemYWFsZAJpRhpGdhaW4J45nqmVuamiskc2GVNVAw1zM2NzMFMpK5MrjSuIK5AAIMAMLhFaAN ZW5kc3RyZWFtDWVuZG9iag01MzUgMCBvYmoNPDwvQkJveFstMC41NTg4NjggLTAuNTU4ODY4IDcu NjcxOTIgNi4xNDc2NF0vRmlsdGVyL0ZsYXRlRGVjb2RlL0Zvcm1UeXBlIDEvTGVuZ3RoIDgyL01h dHJpeFsxLjAgMC4wIDAuMCAxLjAgMC41NTg4NjggMC41NTg4NjhdL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJMlAwUDBUCHLn MtAzNbWwVCjnMgCLFKWDGblcxkBxM1MgE8ow0jO3NDGB8Uz1TC0sLBSSubDKGiiY6xkaGhsCGclc GVxpXMFcAAEGALsZFWwNZW5kc3RyZWFtDWVuZG9iag01NDYgMCBvYmoNPDwvQkJveFstMC41NzI4 MTUgLTAuNTcyODE1IDcuODYzMTkgNi4zMDA5XS9GaWx0ZXIvRmxhdGVEZWNvZGUvRm9ybVR5cGUg MS9MZW5ndGggODEvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjU3MjgxNSAwLjU3MjgxNV0vUmVz b3VyY2VzPDwvUHJvY1NldFsvUERGXT4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVh bQ0KSIkyUDBQMFQIcucy0DM1N7JQKOcyAIsUpYMZuVzGemYmpkZAJpRhpGdhZgLjmOoB9RgqJHNh kzRQMNczsjQwATKSuTK40riCuQACDACHnxTlDWVuZHN0cmVhbQ1lbmRvYmoNNTQ3IDAgb2JqDTw8 L0JCb3hbMTYyLjkzMyA2OTguNzI0IDIxMC43MjQgNzEwLjQ0MV0vRm9ybVR5cGUgMS9MZW5ndGgg NTkvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAtMTYyLjkzMyAtNjk4LjcyNF0vUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGXT4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KMCAwIDEg UkcKMC42NTA5IHcKMTY2LjAzODYgNzAzLjgzODQgbQoyMDcuNjE4IDcwMy44Mzg0IGwKUwoNZW5k c3RyZWFtDWVuZG9iag01NDggMCBvYmoNPDwvQkJveFs0MTIuNDA5IDcyMi40ODQgNDcyLjA4IDcz NC4yMDFdL0ZpbHRlci9GbGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA3NC9NYXRyaXhbMS4w IDAuMCAwLjAgMS4wIC00MTIuNDA5IC03MjIuNDg0XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZd Pj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiUTIsRGAQAhE0ZwqqGAH7oBb KjDXNjS2fTXyR2++gU0LV4PPtw/Dszh138RQaa23hCfSg7rGQjZLL4kiesW/TjnkEWAAeWQPwg1l bmRzdHJlYW0NZW5kb2JqDTU0OSAwIG9iag08PC9CQm94WzMwNS40OTEgNzIyLjQ4NCA0MDYuNzQx IDczNC4yMDFdL0ZpbHRlci9GbGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA3NC9NYXRyaXhb MS4wIDAuMCAwLjAgMS4wIC0zMDUuNDkxIC03MjIuNDg0XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiUTIuRGAMAwF0VxVqALN l3VYqoActwEx7WMiNnqzkOqCK0PUdh+GRpbxeRAkA80PGUqi03mOuVHJNzlM0uJfFy16BRgAeSsP uA1lbmRzdHJlYW0NZW5kb2JqDTU3MSAwIG9iag08PC9CQm94Wy0wLjU1ODg2OCAtMC41NTg4Njgg Ny42NzE5MSA2LjE0NzY0XS9GaWx0ZXIvRmxhdGVEZWNvZGUvRm9ybVR5cGUgMS9MZW5ndGggODEv TWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjU1ODg2OCAwLjU1ODg2OF0vUmVzb3VyY2VzPDwvUHJv Y1NldFsvUERGXT4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIkyUDBQMFQI cucy0DM1tbBUKOcyAIsUpYMZuVzGQHEzUyATyjDSM7c0MYHxTPVMLSwsFJK5sMoaKJjrGRoaA+lk rgyuNK5gLoAAAwClrhU7DWVuZHN0cmVhbQ1lbmRvYmoNNTcyIDAgb2JqDTw8L0JCb3hbLTAuNTcy ODE1IC0wLjU3MjgxNSA3Ljg2MzIyIDYuMzAwOV0vRmlsdGVyL0ZsYXRlRGVjb2RlL0Zvcm1UeXBl IDEvTGVuZ3RoIDgxL01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgMC41NzI4MTUgMC41NzI4MTVdL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJl YW0NCkiJMlAwUDBUCHLnMtAzNTeyUCjnMgCLFKWDGblcxnpmJqZGQCaUYaRnYWYC45jqAfUYKiRz YZM0UDDXM7I0MAEykrkyuNK4grkAAgwAh58U5Q1lbmRzdHJlYW0NZW5kb2JqDTU3MyAwIG9iag08 PC9CQm94WzE4MC43NTMgNDg0Ljg4MiAyOTkuODIyIDQ5Ni41OThdL0Zvcm1UeXBlIDEvTGVuZ3Ro IDYwL01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgLTE4MC43NTMgLTQ4NC44ODJdL1Jlc291cmNlczw8 L1Byb2NTZXRbL1BERl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCjAgMCAx IFJHCjAuNjUwOSB3CjE4My44NTgzIDQ4OS45OTYzIG0KMjk2LjcxNjYgNDg5Ljk5NjMgbApTCg1l bmRzdHJlYW0NZW5kb2JqDTU3NCAwIG9iag08PC9CQm94Wy0wLjU3MjgxNSAtMC41NzI4MTUgNy44 NjMyMiA2LjMwMDldL0ZpbHRlci9GbGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA4MS9NYXRy aXhbMS4wIDAuMCAwLjAgMS4wIDAuNTcyODE1IDAuNTcyODE1XS9SZXNvdXJjZXM8PC9Qcm9jU2V0 Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiTJQMFAwVAhy5zLQ MzU3slAo5zIAixSlgxm5XMZ6ZiamRkAmlGGkZ2FmAuOY6gH1GCokc2GTNFAw1zOyNDABMpK5MrjS uIK5AAIMAIefFOUNZW5kc3RyZWFtDWVuZG9iag01NzUgMCBvYmoNPDwvQkJveFs0MzYuMTY5IDQ5 Ni43NjIgNDY2LjE0IDUwOC40NzldL0Zvcm1UeXBlIDEvTGVuZ3RoIDYwL01hdHJpeFsxLjAgMC4w IDAuMCAxLjAgLTQzNi4xNjkgLTQ5Ni43NjJdL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERl0+Pi9T dWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCjAgMCAxIFJHCjAuNjUwOSB3CjQzOS4y NzQ1IDUwMS44NzY1IG0KNDYzLjAzNDEgNTAxLjg3NjUgbApTCg1lbmRzdHJlYW0NZW5kb2JqDTU3 NiAwIG9iag08PC9CQm94Wy0wLjU3MjgxNSAtMC41NzI4MTUgNy44NjMxNiA2LjMwMDldL0ZpbHRl ci9GbGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA4MS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4w IDAuNTcyODE1IDAuNTcyODE1XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9G b3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiTJQMFAwVAhy5zLQMzU3slAo5zIAixSlgxm5XMZ6 ZiamRkAmlGGkZ2FmAuOY6gH1GCokc2GTNFAw1zOyNDAGMpK5MrjSuIK5AAIMAIeTFOQNZW5kc3Ry ZWFtDWVuZG9iag01NzcgMCBvYmoNPDwvQkJveFszNjQuODkgNTkxLjgwMyA0OTUuODM5IDYwMy41 Ml0vRm9ybVR5cGUgMS9MZW5ndGggNjAvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAtMzY0Ljg5IC01 OTEuODAzXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9i amVjdD4+c3RyZWFtDQowIDAgMSBSRwowLjY1MDkgdwozNjcuOTk1NSA1OTYuOTE3NCBtCjQ5Mi43 MzM3IDU5Ni45MTc0IGwKUwoNZW5kc3RyZWFtDWVuZG9iag01ODUgMCBvYmoNPDwvRGVjb2RlUGFy bXM8PC9Db2x1bW5zIDUvUHJlZGljdG9yIDEyPj4vRmlsdGVyL0ZsYXRlRGVjb2RlL0lEWzw2QUFG QTE4NTRDMkNFMURDOTAxQjQ3QTlBMTJCNjNBMT48REJEOEJCQkE5MkQ4NEM5NEJCRjQ1MzkzOTI3 M0I1RTk+XS9JbmZvIDIgMCBSL0xlbmd0aCAxMTcwL1Jvb3QgMSAwIFIvU2l6ZSA1ODYvVHlwZS9Y UmVmL1dbMSAzIDFdPj5zdHJlYW0NCmje5FdtUFRlFH7vRVDkIz6UD9mA1XIlYNAxIWgHKZrcanT6 QEZFEzRDJHJWBHfEYIycIcUYInGcTCIcJWM0KpOhxHJoQtTSPmYKjYgF5UPYRFFxxds5BzjRzo2E H40z/nnm7LPP85zzvve9d+/KQsi+QpZExG4hCyGlYF33ANbwSVZE5DwF8JsNEvAxBxTA46QU/YTS 38roAgVrf0w4/pwMzNzTtwGPXZdkWcjR0qDyXkZFPBn3I+9Sdb4dMm/3A1bpaZceDr3L55+/qorn /zRrHDJltwArl9L8dgYb/fPaw1gHoP5gjT0ySVbAihrSm58ZwwxLTlZw5r5JDsg43QTcq6HMc3Gq ruWF5ewqXTAemMSzfYB7XiLX6UWqrlXRe9n1bukEZLJvAO76ily1S1Vdr5S9j3cTuYr0jsCkma8D Fg70+iIR6vT4Ek7e/uZEZIqvAW6rJs0nSaPak42HdnLHLTOdgMmy9ALmJlNaRYqqK+dWEc+w2eyM jP4qoo5cJWmszF1ZyMrXNrkgU3YFu5wgZfHaEWbLy8hnr2mNKzKHewAzB85AwfpRrXS71xucln7i PmTiLwMaB2besmkEb9GpHPameboh4/wnYGo2eU2b73CGXcEmzkn+zB2ZVAuejSDKeTWPlXu6Mlm5 oscDmdBuPHvppFyxFerSGRmsWX7EE5nVXYDL5pImYZtN9/3Z61i/OGkSMOU1lwDjLaRf+BbUBwxG 1sTvnIxMXidgXChp5hdw2sePrGXls/u9kDF1AC6IJeW8QtUdOHIplV1PXfFGJqQd0FCMLilmx//w LDq6cAnPELvVB5kdbYCPh9MMEfvukmdmrS6W59RX+SKTfBHw0Y00p/bo2POlSO5SP0XhLuG1U5BJ uAA45wPq4jD2+b9P6+XkWUY/ZA62As5MpORepzvM+Smjm3NCUjTIfN4CGEzPKOmCxwjeX9e0s1e3 /n5kPjIDTqc7V2rAE9i4oY01U5P9kalqBtRmkeaMj2pyS0ILuzS5Acjs/gPQ7z1y1WtY2dHXzEqv 1kBkopoAJ08g5df+qvkWayO73M1aZPS/A7q5kKt6KtQ93r+xxvVbYhY1ArrcJE3lNKivWs8Pahhf RL1zyoNDvaRxdQ1DvwKK1Vc3mqss2a/+Ab0P0XvgbTFYS8qNJ2TSwHug5FiNZ8z+Q+R7SsJUc1xf /w5quU/wJJaXZ/O3Hv2ngOm2m8OM54x6VGpI3ylkRemYTmlBw94wGWE3csLZ632uDvQXm8h7Uk3P LlMQr8Ln2i82HVvzSelASqOWlX4FTTBtq3EaM5pDeDVl8opOXF3z07rBb4ejIgUazv+jC+BjwqZv A+2S8KS+ywJUc3RReD6lIFvvz1HkdSTvC34qXsQ23quQUGQk/6ErqyhnIylhIiUYZNWrGbbOivpA 1J/RkX486kWMw1ifJ9Ksysu4h8NPWrAYXKOi1L9DXdyoS5jbqJIjFrfbnuEAzKz1Hfif8l8Iv3cG l3/ZybGiIumPDVvjwGyKULnXhPLlSqwdMolpRHQrR3SejWjXheiKp0hy14u/BBgAXLjilA1lbmRz dHJlYW0NZW5kb2JqDXN0YXJ0eHJlZg04MzM2OQ0lJUVPRg0yIDAgb2JqDTw8L0F1dGhvcigpL0Ny ZWF0aW9uRGF0ZShEOjIwMTcwODIxMTMwMDUwLTA3JzAwJykvQ3JlYXRvcihodG1sMnBzIHZlcnNp b24gMS4wIGJldGE3KS9LZXl3b3JkcygpL01vZERhdGUoRDoyMDE3MDkwNzE2NDIxOSswMicwMCcp L1Byb2R1Y2VyKEdQTCBHaG9zdHNjcmlwdCA5LjA2KS9TdWJqZWN0KCkvVGl0bGUoZHJhZnQtaWV0 Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTA0IC0gVHJhbnNtaXNzaW9uIG9mIElQdjYgUGFj a2V0cyBvdmVyIElFRUUgODAyLjExIE5ldHdvcmtzIGluIG1vZGUgT3V0c2lkZSB0aGUgQ29udGV4 dCBvZiBhIEJhc2ljIFNlcnZpY2UgU2V0IIFJUHY2LW92ZXItODAyMTFvY2KCKT4+DWVuZG9iag00 MTUgMCBvYmoNPDwvTGVuZ3RoIDM4MTEvU3VidHlwZS9YTUwvVHlwZS9NZXRhZGF0YT4+c3RyZWFt DQo8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pgo8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29y ZSA1LjYtYzAxNSA4NC4xNTk4MTAsIDIwMTYvMDkvMTAtMDI6NDE6MzAgICAgICAgICI+CiAgIDxy ZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4 LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHht bG5zOnBkZj0iaHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLyIKICAgICAgICAgICAgeG1sbnM6 eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIgogICAgICAgICAgICB4bWxuczp4bXBN TT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIKICAgICAgICAgICAgeG1sbnM6ZGM9 Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj4KICAgICAgICAgPHBkZjpQcm9kdWNl cj5HUEwgR2hvc3RzY3JpcHQgOS4wNjwvcGRmOlByb2R1Y2VyPgogICAgICAgICA8cGRmOktleXdv cmRzLz4KICAgICAgICAgPHhtcDpNb2RpZnlEYXRlPjIwMTctMDktMDdUMTY6NDI6MTkrMDI6MDA8 L3htcDpNb2RpZnlEYXRlPgogICAgICAgICA8eG1wOkNyZWF0ZURhdGU+MjAxNy0wOC0yMVQxMzow MDo1MC0wNzowMDwveG1wOkNyZWF0ZURhdGU+CiAgICAgICAgIDx4bXA6Q3JlYXRvclRvb2w+aHRt bDJwcyB2ZXJzaW9uIDEuMCBiZXRhNzwveG1wOkNyZWF0b3JUb29sPgogICAgICAgICA8eG1wOk1l dGFkYXRhRGF0ZT4yMDE3LTA5LTA3VDE2OjQyOjE5KzAyOjAwPC94bXA6TWV0YWRhdGFEYXRlPgog ICAgICAgICA8eG1wTU06RG9jdW1lbnRJRD51dWlkOmZhYThhOTcwLWJlYzctMTFmMi0wMDAwLTk5 MzI0MzYyNjIwYjwveG1wTU06RG9jdW1lbnRJRD4KICAgICAgICAgPHhtcE1NOkluc3RhbmNlSUQ+ dXVpZDo3M2I3ZGM4Mi1iZTJlLTI5NDMtOWY0OC0yMTk3MjkwYmExNjg8L3htcE1NOkluc3RhbmNl SUQ+CiAgICAgICAgIDxkYzpmb3JtYXQ+YXBwbGljYXRpb24vcGRmPC9kYzpmb3JtYXQ+CiAgICAg ICAgIDxkYzp0aXRsZT4KICAgICAgICAgICAgPHJkZjpBbHQ+CiAgICAgICAgICAgICAgIDxyZGY6 bGkgeG1sOmxhbmc9IngtZGVmYXVsdCI+ZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjEx b2NiLTA0IC0gVHJhbnNtaXNzaW9uIG9mIElQdjYgUGFja2V0cyBvdmVyIElFRUUgODAyLjExIE5l dHdvcmtzIGluIG1vZGUgT3V0c2lkZSB0aGUgQ29udGV4dCBvZiBhIEJhc2ljIFNlcnZpY2UgU2V0 IOKAoElQdjYtb3Zlci04MDIxMW9jYuKAoTwvcmRmOmxpPgogICAgICAgICAgICA8L3JkZjpBbHQ+ CiAgICAgICAgIDwvZGM6dGl0bGU+CiAgICAgICAgIDxkYzpjcmVhdG9yPgogICAgICAgICAgICA8 cmRmOlNlcT4KICAgICAgICAgICAgICAgPHJkZjpsaS8+CiAgICAgICAgICAgIDwvcmRmOlNlcT4K ICAgICAgICAgPC9kYzpjcmVhdG9yPgogICAgICAgICA8ZGM6ZGVzY3JpcHRpb24+CiAgICAgICAg ICAgIDxyZGY6QWx0PgogICAgICAgICAgICAgICA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQi Lz4KICAgICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1yZXBhaXIiLz4KICAgICAgICAg ICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOmRlc2NyaXB0aW9uPgogICAgICA8L3JkZjpEZXNj cmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSJ3Ij8+DWVuZHN0 cmVhbQ1lbmRvYmoNNTg2IDAgb2JqDTw8L0FQPDwvTiA1ODggMCBSPj4vQ1swLjAgMC4wIDEuMF0v Q29udGVudHMoLCkvQ3JlYXRpb25EYXRlKEQ6MjAxNzA5MDcxNjQxNTArMDInMDAnKS9GIDQvTShE OjIwMTcwOTA3MTY0MTUzKzAyJzAwJykvTk0oMDY5Nzc1YTItOTg5OS0xNzQyLTg0MzEtNTQ5NTgx NjE4ZDBkKS9QIDI1MSAwIFIvUG9wdXAgNTg3IDAgUi9SQyg8P3htbCB2ZXJzaW9uPSIxLjAiPz48 Ym9keSB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCIgeG1sbnM6eGZhPSJodHRw Oi8vd3d3LnhmYS5vcmcvc2NoZW1hL3hmYS1kYXRhLzEuMC8iIHhmYTpBUElWZXJzaW9uPSJBY3Jv YmF0OjE3LjEyLjAiIHhmYTpzcGVjPSIyLjAuMiIgPjxwIGRpcj0ibHRyIj48c3BhbiBkaXI9Imx0 ciIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7dGV4dC1hbGlnbjpsZWZ0O2NvbG9yOiMwMDAwMDA7 Zm9udC1cDXdlaWdodDpub3JtYWw7Zm9udC1zdHlsZTpub3JtYWwiPiw8L3NwYW4+PC9wPjwvYm9k eT4pL1JEWzAuNTU4ODY4IDAuNTU4ODY4IDAuNTU4ODY4IDAuNTU4ODY4XS9SZWN0WzM4Ny42NiA0 NjEuMzMyIDM5NS44OTEgNDY4LjAzOV0vU3ViaihUZXh0byBpbnNlcnRhZG8pL1N1YnR5cGUvQ2Fy ZXQvVChKb3NlKS9UeXBlL0Fubm90Pj4NZW5kb2JqDTU4NyAwIG9iag08PC9GIDI4L09wZW4gZmFs c2UvUGFyZW50IDU4NiAwIFIvUmVjdFs1OTUuMCAzMjUuNDggNzc1LjAgNDY3LjQ4XS9TdWJ0eXBl L1BvcHVwL1R5cGUvQW5ub3Q+Pg1lbmRvYmoNNTg4IDAgb2JqDTw8L0JCb3hbLTAuNTU4ODY4IC0w LjU1ODg2OCA3LjY3MTkxIDYuMTQ3NjFdL0Zvcm1UeXBlIDEvTGVuZ3RoIDExMS9NYXRyaXhbMS4w IDAuMCAwLjAgMS4wIDAuNTU4ODY4IDAuNTU4ODY4XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZd Pj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQowIDAgMSBSRwowLjU1ODkgdwow IDAgMSByZwowIDAgbQozLjU1NjUgMCAzLjU1NjUgMi43OTQ0IDMuNTU2NSA1LjU4ODcgYwozLjU1 NjUgMi43OTQ0IDMuNTU2NSAwIDcuMTEzIDAgYwpoCmYKUwoNZW5kc3RyZWFtDWVuZG9iag01ODkg MCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDE5NC9OIDEvVHlwZS9P YmpTdG0+PnN0cmVhbQ0KaN4s0E0KgzAQhuGr5Aaj0ZlaEKH/q4JYd+JC7FC6MUVTsLdvmn6rl8DM ExLLqUlMWdJumpxfOst5ODfGMsdyVqDbf/METVGLZmiOYp83KByGI3AEjsAROAJH4Iig8ASewNvA KzBXxLmeDm7yOvklvCjeQFe9P4e9W7vfAm/ZFLntqR7mMGXi5dTo4t7zqEv4l9PqLzc/eA1ApOkc xHCIPtWzG2/qO6qPZ2p19X1VUePiQkLt56WBfmhVfQUYABEnVR0NZW5kc3RyZWFtDWVuZG9iag01 OTAgMCBvYmoNPDwvRGVjb2RlUGFybXM8PC9Db2x1bW5zIDUvUHJlZGljdG9yIDEyPj4vRmlsdGVy L0ZsYXRlRGVjb2RlL0lEWzw2QUFGQTE4NTRDMkNFMURDOTAxQjQ3QTlBMTJCNjNBMT48NjhBQ0RE MTIwQTU1NEEwOTk4MTg3NkVGNDg5OTk5M0M+XS9JbmRleFsyIDEgMjUxIDEgNDE1IDEgNTUwIDcg NTg2IDVdL0luZm8gMiAwIFIvTGVuZ3RoIDY1L1ByZXYgODMzNjkvUm9vdCAxIDAgUi9TaXplIDU5 MS9UeXBlL1hSZWYvV1sxIDMgMV0+PnN0cmVhbQ0KaN5iYmT0tmJgYvy/XZiB6T+jVwSQ/L8lmpGJ gYFJjQFIMjDiJhkZI1f/B7KZ28AieSCSyRxEMiowAAQYAGhUCqMNZW5kc3RyZWFtDWVuZG9iag1z dGFydHhyZWYNOTA0MDENJSVFT0YNMiAwIG9iag08PC9BdXRob3IoKS9DcmVhdGlvbkRhdGUoRDoy MDE3MDgyMTEzMDA1MC0wNycwMCcpL0NyZWF0b3IoaHRtbDJwcyB2ZXJzaW9uIDEuMCBiZXRhNykv S2V5d29yZHMoKS9Nb2REYXRlKEQ6MjAxNzA5MDcxNjQzNTUrMDInMDAnKS9Qcm9kdWNlcihHUEwg R2hvc3RzY3JpcHQgOS4wNikvU3ViamVjdCgpL1RpdGxlKGRyYWZ0LWlldGYtaXB3YXZlLWlwdjYt b3Zlci04MDIxMW9jYi0wNCAtIFRyYW5zbWlzc2lvbiBvZiBJUHY2IFBhY2tldHMgb3ZlciBJRUVF IDgwMi4xMSBOZXR3b3JrcyBpbiBtb2RlIE91dHNpZGUgdGhlIENvbnRleHQgb2YgYSBCYXNpYyBT ZXJ2aWNlIFNldCCBSVB2Ni1vdmVyLTgwMjExb2Nigik+Pg1lbmRvYmoNNDE1IDAgb2JqDTw8L0xl bmd0aCAzODExL1N1YnR5cGUvWE1ML1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFja2V0IGJl Z2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxu czp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS42LWMwMTUgODQu MTU5ODEwLCAyMDE2LzA5LzEwLTAyOjQxOjMwICAgICAgICAiPgogICA8cmRmOlJERiB4bWxuczpy ZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpwZGY9Imh0dHA6 Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8iCiAgICAgICAgICAgIHhtbG5zOnhtcD0iaHR0cDovL25z LmFkb2JlLmNvbS94YXAvMS4wLyIKICAgICAgICAgICAgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5h ZG9iZS5jb20veGFwLzEuMC9tbS8iCiAgICAgICAgICAgIHhtbG5zOmRjPSJodHRwOi8vcHVybC5v cmcvZGMvZWxlbWVudHMvMS4xLyI+CiAgICAgICAgIDxwZGY6UHJvZHVjZXI+R1BMIEdob3N0c2Ny aXB0IDkuMDY8L3BkZjpQcm9kdWNlcj4KICAgICAgICAgPHBkZjpLZXl3b3Jkcy8+CiAgICAgICAg IDx4bXA6TW9kaWZ5RGF0ZT4yMDE3LTA5LTA3VDE2OjQzOjU1KzAyOjAwPC94bXA6TW9kaWZ5RGF0 ZT4KICAgICAgICAgPHhtcDpDcmVhdGVEYXRlPjIwMTctMDgtMjFUMTM6MDA6NTAtMDc6MDA8L3ht cDpDcmVhdGVEYXRlPgogICAgICAgICA8eG1wOkNyZWF0b3JUb29sPmh0bWwycHMgdmVyc2lvbiAx LjAgYmV0YTc8L3htcDpDcmVhdG9yVG9vbD4KICAgICAgICAgPHhtcDpNZXRhZGF0YURhdGU+MjAx Ny0wOS0wN1QxNjo0Mzo1NSswMjowMDwveG1wOk1ldGFkYXRhRGF0ZT4KICAgICAgICAgPHhtcE1N OkRvY3VtZW50SUQ+dXVpZDpmYWE4YTk3MC1iZWM3LTExZjItMDAwMC05OTMyNDM2MjYyMGI8L3ht cE1NOkRvY3VtZW50SUQ+CiAgICAgICAgIDx4bXBNTTpJbnN0YW5jZUlEPnV1aWQ6ZmM3MDY0NDEt M2ZmMi01YzRlLWEyNzItMGMwZjNjNWNhNDFiPC94bXBNTTpJbnN0YW5jZUlEPgogICAgICAgICA8 ZGM6Zm9ybWF0PmFwcGxpY2F0aW9uL3BkZjwvZGM6Zm9ybWF0PgogICAgICAgICA8ZGM6dGl0bGU+ CiAgICAgICAgICAgIDxyZGY6QWx0PgogICAgICAgICAgICAgICA8cmRmOmxpIHhtbDpsYW5nPSJ4 LWRlZmF1bHQiPmRyYWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYi0wNCAtIFRyYW5z bWlzc2lvbiBvZiBJUHY2IFBhY2tldHMgb3ZlciBJRUVFIDgwMi4xMSBOZXR3b3JrcyBpbiBtb2Rl IE91dHNpZGUgdGhlIENvbnRleHQgb2YgYSBCYXNpYyBTZXJ2aWNlIFNldCDigKBJUHY2LW92ZXIt ODAyMTFvY2LigKE8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2Rj OnRpdGxlPgogICAgICAgICA8ZGM6Y3JlYXRvcj4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAg ICAgICAgICAgIDxyZGY6bGkvPgogICAgICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAgIDwvZGM6 Y3JlYXRvcj4KICAgICAgICAgPGRjOmRlc2NyaXB0aW9uPgogICAgICAgICAgICA8cmRmOkFsdD4K ICAgICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ii8+CiAgICAgICAgICAg ICAgIDxyZGY6bGkgeG1sOmxhbmc9IngtcmVwYWlyIi8+CiAgICAgICAgICAgIDwvcmRmOkFsdD4K ICAgICAgICAgPC9kYzpkZXNjcmlwdGlvbj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwv cmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0idyI/Pg1lbmRzdHJlYW0NZW5kb2JqDTU5 MSAwIG9iag08PC9BUDw8L04gNTk2IDAgUj4+L0NbMC4wIDAuMCAxLjBdL0NyZWF0aW9uRGF0ZShE OjIwMTcwOTA3MTY0MzQwKzAyJzAwJykvRiA0L0lSVCA1OTMgMCBSL0lUL1N0cmlrZU91dFRleHRF ZGl0L00oRDoyMDE3MDkwNzE2NDM0MCswMicwMCcpL05NKDNjYzZkZWZlLTA1YTEtZDI0My05YTZk LTk3MGFkNjA0M2YxMykvUCAyNTEgMCBSL1BvcHVwIDU5MiAwIFIvUXVhZFBvaW50c1s0NTcuMDk0 IDI3MC4yMjcgNDc0LjkxNCAyNzAuMjI3IDQ1Ny4wOTQgMjU5LjgxMiA0NzQuOTE0IDI1OS44MTJd L1JUL0dyb3VwL1JlY3RbNDUzLjk4OSAyNTkuMTYxIDQ3OC4wMiAyNzAuODc3XS9TdWJqKFRhY2hh ZG8pL1N1YnR5cGUvU3RyaWtlT3V0L1QoSm9zZSkvVHlwZS9Bbm5vdD4+DWVuZG9iag01OTIgMCBv YmoNPDwvRiAyOC9PcGVuIGZhbHNlL1BhcmVudCA1OTEgMCBSL1JlY3RbNTk1LjAgMTI4LjIyNyA3 NzUuMCAyNzAuMjI3XS9TdWJ0eXBlL1BvcHVwL1R5cGUvQW5ub3Q+Pg1lbmRvYmoNNTkzIDAgb2Jq DTw8L0FQPDwvTiA1OTUgMCBSPj4vQ1swLjAgMC4wIDEuMF0vQ29udGVudHModGhlbikvQ3JlYXRp b25EYXRlKEQ6MjAxNzA5MDcxNjQzNDArMDInMDAnKS9GIDQvSVQvUmVwbGFjZS9NKEQ6MjAxNzA5 MDcxNjQzNDMrMDInMDAnKS9OTSg0YjQ0NmQzMy02MGRjLTMzNGUtYjViYi01NmQyOWZhZmFhMTIp L1AgMjUxIDAgUi9Qb3B1cCA1OTQgMCBSL1JDKDw/eG1sIHZlcnNpb249IjEuMCI/Pjxib2R5IHht bG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWxuczp4ZmE9Imh0dHA6Ly93d3cu eGZhLm9yZy9zY2hlbWEveGZhLWRhdGEvMS4wLyIgeGZhOkFQSVZlcnNpb249IkFjcm9iYXQ6MTcu MTIuMCIgeGZhOnNwZWM9IjIuMC4yIiA+PHAgZGlyPSJsdHIiPjxzcGFuIGRpcj0ibHRyIiBzdHls ZT0iZm9udC1zaXplOjE0LjBwdDt0ZXh0LWFsaWduOmxlZnQ7Y29sb3I6IzAwMDAwMDtmb250LVwN d2VpZ2h0Om5vcm1hbDtmb250LXN0eWxlOm5vcm1hbCI+dGhlbjwvc3Bhbj48L3A+PC9ib2R5Pikv UkRbMC41NzI4MTUgMC41NzI4MTUgMC41NzI4MTUgMC41NzI4MTVdL1JlY3RbNDcwLjY5NiAyNTku MjM5IDQ3OS4xMzIgMjY2LjExM10vU3ViaihUZXh0byBpbnNlcnRhZG8pL1N1YnR5cGUvQ2FyZXQv VChKb3NlKS9UeXBlL0Fubm90Pj4NZW5kb2JqDTU5NCAwIG9iag08PC9GIDI4L09wZW4gZmFsc2Uv UGFyZW50IDU5MyAwIFIvUmVjdFs1OTUuMCAxMjMuNTQgNzc1LjAgMjY1LjU0XS9TdWJ0eXBlL1Bv cHVwL1R5cGUvQW5ub3Q+Pg1lbmRvYmoNNTk1IDAgb2JqDTw8L0JCb3hbLTAuNTcyODE1IC0wLjU3 MjgxNSA3Ljg2MzE5IDYuMzAwOV0vRm9ybVR5cGUgMS9MZW5ndGggMTEwL01hdHJpeFsxLjAgMC4w IDAuMCAxLjAgMC41NzI4MTUgMC41NzI4MTVdL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERl0+Pi9T dWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCjAgMCAxIFJHCjAuNTcyOCB3CjAgMCAx IHJnCjAgMCBtCjMuNjQ1MiAwIDMuNjQ1MiAyLjg2NCAzLjY0NTIgNS43MjgxIGMKMy42NDUyIDIu ODY0IDMuNjQ1MiAwIDcuMjkwNCAwIGMKaApmClMKDWVuZHN0cmVhbQ1lbmRvYmoNNTk2IDAgb2Jq DTw8L0JCb3hbNDUzLjk4OSAyNTkuMTYxIDQ3OC4wMiAyNzAuODc3XS9Gb3JtVHlwZSAxL0xlbmd0 aCA2MC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIC00NTMuOTg5IC0yNTkuMTYxXS9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQowIDAg MSBSRwowLjY1MDkgdwo0NTcuMDk0MiAyNjQuMjc1MyBtCjQ3NC45MTM5IDI2NC4yNzUzIGwKUwoN ZW5kc3RyZWFtDWVuZG9iag01OTcgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYv TGVuZ3RoIDIwMi9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4s0E0KwjAQhuGr5AZTY2fagBT8 XwmldVe6KDqIm0baCPX2xvitXgIzT0gsr0xmNhvajqMPc2c5j+fGWOZUXpeo+zfP0BVq0TWao9jn AoXDcASOwBE4AkfgCBwRFJ7AE3gFvBJzJeYcfAffwXfJ72nvx6BjmOOL0wRd9P4cdn7pfiA7NmVu e6qHKU6ZtEyNzv493XSO/3ZcwrkNQ9AIpKvpFMV4SPdTPflbq6Gj+nCiqy6hrypqfFrI6Pp5aaQf WlVfAQYAI2BbJw1lbmRzdHJlYW0NZW5kb2JqDTU5OCAwIG9iag08PC9EZWNvZGVQYXJtczw8L0Nv bHVtbnMgNC9QcmVkaWN0b3IgMTI+Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvSURbPDZBQUZBMTg1NEMy Q0UxREM5MDFCNDdBOUExMkI2M0ExPjxEQTFFNkM0MzQwNkQ0OEVDQTJGRTE4MzBGOEVGMEQwND5d L0luZGV4WzIgMSAyNTEgMSA0MTUgMSA1OTEgOF0vSW5mbyAyIDAgUi9MZW5ndGggNTIvUHJldiA5 MDQwMS9Sb290IDEgMCBSL1NpemUgNTk5L1R5cGUvWFJlZi9XWzEgMyAwXT4+c3RyZWFtDQpo3mJi ZEzqZWL8v+AE03/GxMVMDAwChkCCsQtEFAAJphkgVh6IMAUR/0CEBkCAAQA8KwkYDWVuZHN0cmVh bQ1lbmRvYmoNc3RhcnR4cmVmDTk3MTU2DSUlRU9GDTIgMCBvYmoNPDwvQXV0aG9yKCkvQ3JlYXRp b25EYXRlKEQ6MjAxNzA4MjExMzAwNTAtMDcnMDAnKS9DcmVhdG9yKGh0bWwycHMgdmVyc2lvbiAx LjAgYmV0YTcpL0tleXdvcmRzKCkvTW9kRGF0ZShEOjIwMTcwOTA3MTY0NzA1KzAyJzAwJykvUHJv ZHVjZXIoR1BMIEdob3N0c2NyaXB0IDkuMDYpL1N1YmplY3QoKS9UaXRsZShkcmFmdC1pZXRmLWlw d2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMDQgLSBUcmFuc21pc3Npb24gb2YgSVB2NiBQYWNrZXRz IG92ZXIgSUVFRSA4MDIuMTEgTmV0d29ya3MgaW4gbW9kZSBPdXRzaWRlIHRoZSBDb250ZXh0IG9m IGEgQmFzaWMgU2VydmljZSBTZXQggUlQdjYtb3Zlci04MDIxMW9jYoIpPj4NZW5kb2JqDTQxNSAw IG9iag08PC9MZW5ndGggMzgxMS9TdWJ0eXBlL1hNTC9UeXBlL01ldGFkYXRhPj5zdHJlYW0NCjw/ eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+Cjx4Onht cG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUu Ni1jMDE1IDg0LjE1OTgxMCwgMjAxNi8wOS8xMC0wMjo0MTozMCAgICAgICAgIj4KICAgPHJkZjpS REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMj Ij4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6 cGRmPSJodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvIgogICAgICAgICAgICB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iCiAgICAgICAgICAgIHhtbG5zOnhtcE1NPSJo dHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIgogICAgICAgICAgICB4bWxuczpkYz0iaHR0 cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iPgogICAgICAgICA8cGRmOlByb2R1Y2VyPkdQ TCBHaG9zdHNjcmlwdCA5LjA2PC9wZGY6UHJvZHVjZXI+CiAgICAgICAgIDxwZGY6S2V5d29yZHMv PgogICAgICAgICA8eG1wOk1vZGlmeURhdGU+MjAxNy0wOS0wN1QxNjo0NzowNSswMjowMDwveG1w Ok1vZGlmeURhdGU+CiAgICAgICAgIDx4bXA6Q3JlYXRlRGF0ZT4yMDE3LTA4LTIxVDEzOjAwOjUw LTA3OjAwPC94bXA6Q3JlYXRlRGF0ZT4KICAgICAgICAgPHhtcDpDcmVhdG9yVG9vbD5odG1sMnBz IHZlcnNpb24gMS4wIGJldGE3PC94bXA6Q3JlYXRvclRvb2w+CiAgICAgICAgIDx4bXA6TWV0YWRh dGFEYXRlPjIwMTctMDktMDdUMTY6NDc6MDUrMDI6MDA8L3htcDpNZXRhZGF0YURhdGU+CiAgICAg ICAgIDx4bXBNTTpEb2N1bWVudElEPnV1aWQ6ZmFhOGE5NzAtYmVjNy0xMWYyLTAwMDAtOTkzMjQz NjI2MjBiPC94bXBNTTpEb2N1bWVudElEPgogICAgICAgICA8eG1wTU06SW5zdGFuY2VJRD51dWlk OmQ3YjkwYWIxLWYzZDUtMTA0NC1iOTU1LTRhYTMzYzRkZDEzNzwveG1wTU06SW5zdGFuY2VJRD4K ICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1hdD4KICAgICAgICAg PGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAgICAgICAgICAgPHJkZjpsaSB4 bWw6bGFuZz0ieC1kZWZhdWx0Ij5kcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2It MDQgLSBUcmFuc21pc3Npb24gb2YgSVB2NiBQYWNrZXRzIG92ZXIgSUVFRSA4MDIuMTEgTmV0d29y a3MgaW4gbW9kZSBPdXRzaWRlIHRoZSBDb250ZXh0IG9mIGEgQmFzaWMgU2VydmljZSBTZXQg4oCg SVB2Ni1vdmVyLTgwMjExb2Ni4oChPC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOkFsdD4KICAg ICAgICAgPC9kYzp0aXRsZT4KICAgICAgICAgPGRjOmNyZWF0b3I+CiAgICAgICAgICAgIDxyZGY6 U2VxPgogICAgICAgICAgICAgICA8cmRmOmxpLz4KICAgICAgICAgICAgPC9yZGY6U2VxPgogICAg ICAgICA8L2RjOmNyZWF0b3I+CiAgICAgICAgIDxkYzpkZXNjcmlwdGlvbj4KICAgICAgICAgICAg PHJkZjpBbHQ+CiAgICAgICAgICAgICAgIDxyZGY6bGkgeG1sOmxhbmc9IngtZGVmYXVsdCIvPgog ICAgICAgICAgICAgICA8cmRmOmxpIHhtbDpsYW5nPSJ4LXJlcGFpciIvPgogICAgICAgICAgICA8 L3JkZjpBbHQ+CiAgICAgICAgIDwvZGM6ZGVzY3JpcHRpb24+CiAgICAgIDwvcmRmOkRlc2NyaXB0 aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9InciPz4NZW5kc3RyZWFt DWVuZG9iag01OTkgMCBvYmoNPDwvQVA8PC9OIDYwNCAwIFI+Pi9DWzAuMCAwLjAgMS4wXS9DcmVh dGlvbkRhdGUoRDoyMDE3MDkwNzE2NDY1NyswMicwMCcpL0YgNC9JUlQgNjAxIDAgUi9JVC9TdHJp a2VPdXRUZXh0RWRpdC9NKEQ6MjAxNzA5MDcxNjQ2NTcrMDInMDAnKS9OTSg2MmM5MmYzNy03ZThk LTE2NDQtOTk4NS03ZWQ2Y2FhZjUxYjMpL1AgMjU4IDAgUi9Qb3B1cCA2MDAgMCBSL1F1YWRQb2lu dHNbNDMzLjMzNSA2MTQuNzQ5IDQ1MS4xNTQgNjE0Ljc0OSA0MzMuMzM1IDYwNC4zMzQgNDUxLjE1 NCA2MDQuMzM0XS9SVC9Hcm91cC9SZWN0WzQzMC4yMjkgNjAzLjY4MyA0NTQuMjYgNjE1LjRdL1N1 YmooVGFjaGFkbykvU3VidHlwZS9TdHJpa2VPdXQvVChKb3NlKS9UeXBlL0Fubm90Pj4NZW5kb2Jq DTYwMCAwIG9iag08PC9GIDI4L09wZW4gZmFsc2UvUGFyZW50IDU5OSAwIFIvUmVjdFs1OTUuMCA0 NzIuNzQ5IDc3NS4wIDYxNC43NDldL1N1YnR5cGUvUG9wdXAvVHlwZS9Bbm5vdD4+DWVuZG9iag02 MDEgMCBvYmoNPDwvQVA8PC9OIDYwMyAwIFI+Pi9DWzAuMCAwLjAgMS4wXS9Db250ZW50cyhhbmQp L0NyZWF0aW9uRGF0ZShEOjIwMTcwOTA3MTY0NjU3KzAyJzAwJykvRiA0L0lUL1JlcGxhY2UvTShE OjIwMTcwOTA3MTY0NjU5KzAyJzAwJykvTk0oNjZkODcyOTAtOTE0Zi04MzQ4LWE0YmQtZjFkYTY5 NDI0ZDBjKS9QIDI1OCAwIFIvUG9wdXAgNjAyIDAgUi9SQyg8P3htbCB2ZXJzaW9uPSIxLjAiPz48 Ym9keSB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCIgeG1sbnM6eGZhPSJodHRw Oi8vd3d3LnhmYS5vcmcvc2NoZW1hL3hmYS1kYXRhLzEuMC8iIHhmYTpBUElWZXJzaW9uPSJBY3Jv YmF0OjE3LjEyLjAiIHhmYTpzcGVjPSIyLjAuMiIgPjxwIGRpcj0ibHRyIj48c3BhbiBkaXI9Imx0 ciIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7dGV4dC1hbGlnbjpsZWZ0O2NvbG9yOiMwMDAwMDA7 Zm9udC1cDXdlaWdodDpub3JtYWw7Zm9udC1zdHlsZTpub3JtYWwiPmFuZDwvc3Bhbj48L3A+PC9i b2R5PikvUkRbMC41NzI4MTUgMC41NzI4MTUgMC41NzI4MTUgMC41NzI4MTVdL1JlY3RbNDQ2Ljkz NiA2MDMuNzYxIDQ1NS4zNzIgNjEwLjYzNV0vU3ViaihUZXh0byBpbnNlcnRhZG8pL1N1YnR5cGUv Q2FyZXQvVChKb3NlKS9UeXBlL0Fubm90Pj4NZW5kb2JqDTYwMiAwIG9iag08PC9GIDI4L09wZW4g ZmFsc2UvUGFyZW50IDYwMSAwIFIvUmVjdFs1OTUuMCA0NjguMDYyIDc3NS4wIDYxMC4wNjJdL1N1 YnR5cGUvUG9wdXAvVHlwZS9Bbm5vdD4+DWVuZG9iag02MDMgMCBvYmoNPDwvQkJveFstMC41NzI4 MTUgLTAuNTcyODE1IDcuODYzMjIgNi4zMDA5XS9Gb3JtVHlwZSAxL0xlbmd0aCAxMTAvTWF0cml4 WzEuMCAwLjAgMC4wIDEuMCAwLjU3MjgxNSAwLjU3MjgxNV0vUmVzb3VyY2VzPDwvUHJvY1NldFsv UERGXT4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KMCAwIDEgUkcKMC41NzI4 IHcKMCAwIDEgcmcKMCAwIG0KMy42NDUyIDAgMy42NDUyIDIuODY0IDMuNjQ1MiA1LjcyODEgYwoz LjY0NTIgMi44NjQgMy42NDUyIDAgNy4yOTA0IDAgYwpoCmYKUwoNZW5kc3RyZWFtDWVuZG9iag02 MDQgMCBvYmoNPDwvQkJveFs0MzAuMjI5IDYwMy42ODMgNDU0LjI2IDYxNS40XS9Gb3JtVHlwZSAx L0xlbmd0aCA2MC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIC00MzAuMjI5IC02MDMuNjgzXS9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFt DQowIDAgMSBSRwowLjY1MDkgdwo0MzMuMzM0NiA2MDguNzk3NCBtCjQ1MS4xNTQzIDYwOC43OTc0 IGwKUwoNZW5kc3RyZWFtDWVuZG9iag02MDUgMCBvYmoNPDwvQVA8PC9OIDYwNyAwIFI+Pi9DWzAu MCAwLjAgMS4wXS9Db250ZW50cygiLCBmb3IgZXhhbXBsZSB1c2luZyBhIHByb3BlciBQS0kgdG8g c2VjdXJlIG1lc3NhZ2VzLiJcblxuQW5kIGhlcmUgaXQgd291bGQgYmUgcG9zc2libGUgdG8gY2l0 ZSBjdXJyZW50IEVUU0kgZG9jdW1lbnRzIHJlZ2FyZGluZyBzZWN1cml0eSB1c2luZyBQS0kuKS9D cmVhdGlvbkRhdGUoRDoyMDE3MDkwNzE2NDQ0NCswMicwMCcpL0YgNC9NKEQ6MjAxNzA5MDcxNjQ1 NTMrMDInMDAnKS9OTShjODlkNmFhZS0wZjdkLTFhNGQtODMxMC1lZGU0YTVjOTdlNjgpL1AgMjUx IDAgUi9Qb3B1cCA2MDYgMCBSL1JDKDw/eG1sIHZlcnNpb249IjEuMCI/Pjxib2R5IHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWxuczp4ZmE9Imh0dHA6Ly93d3cueGZhLm9y Zy9zY2hlbWEveGZhLWRhdGEvMS4wLyIgeGZhOkFQSVZlcnNpb249IkFjcm9iYXQ6MTcuMTIuMCIg eGZhOnNwZWM9IjIuMC4yIiA+PHAgZGlyPSJsdHIiPjxzcGFuIGRpcj0ibHRyIiBzdHlsZT0iZm9u dC1zaXplOjE0LjBwdDt0ZXh0LWFsaWduOmxlZnQ7Y29sb3I6IzAwMDAwMDtmb250LVwNd2VpZ2h0 Om5vcm1hbDtmb250LXN0eWxlOm5vcm1hbCI+JnF1b3Q7LCBmb3IgZXhhbXBsZSB1c2luZyBhIHBy b3BlciBQS0kgdG8gc2VjdXJlIG1lc3NhZ2VzLiZxdW90OyYjMTA7JiMxMDtBbmQgaGVyZSBpdCB3 b3VsZCBiZSBwb3NzaWJsZSB0byBjaXRlIGN1cnJlbnQgRVRTSSBkb2N1bWVudHMgcmVnYXJkaW5n IHNlY3VyaXR5IHVzaW5nIFBLSS48L3NwYW4+PC9wPjwvYm9keT4pL1JEWzAuNTU4ODY4IDAuNTU4 ODY4IDAuNTU4ODY4IDAuNTU4ODY4XS9SZWN0WzQyMy40MTMgMTg4LjEwNiA0MzEuNjQ0IDE5NC44 MTJdL1N1YmooVGV4dG8gaW5zZXJ0YWRvKS9TdWJ0eXBlL0NhcmV0L1QoSm9zZSkvVHlwZS9Bbm5v dD4+DWVuZG9iag02MDYgMCBvYmoNPDwvRiAyOC9PcGVuIGZhbHNlL1BhcmVudCA2MDUgMCBSL1Jl Y3RbNTk1LjAgNTIuMjUzNCA3NzUuMCAxOTQuMjUzXS9TdWJ0eXBlL1BvcHVwL1R5cGUvQW5ub3Q+ Pg1lbmRvYmoNNjA3IDAgb2JqDTw8L0JCb3hbLTAuNTU4ODY4IC0wLjU1ODg2OCA3LjY3MTkxIDYu MTQ3NjRdL0Zvcm1UeXBlIDEvTGVuZ3RoIDExMS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuNTU4 ODY4IDAuNTU4ODY4XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5 cGUvWE9iamVjdD4+c3RyZWFtDQowIDAgMSBSRwowLjU1ODkgdwowIDAgMSByZwowIDAgbQozLjU1 NjUgMCAzLjU1NjUgMi43OTQ0IDMuNTU2NSA1LjU4ODggYwozLjU1NjUgMi43OTQ0IDMuNTU2NSAw IDcuMTEzIDAgYwpoCmYKUwoNZW5kc3RyZWFtDWVuZG9iag02MDggMCBvYmoNPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0ZpcnN0IDE0L0xlbmd0aCAyNTQvTiAyL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmje pJHLasMwEEV/RX8wsqyZSBAMfaWrgHGyM16YVJRurGKr4P59FPkGCt0UujpInjny3DFcKa0MO2V1 rfZ7epimmJbesM33Xf7ChVw70G+0GqxAA9agBdHPOxAehkfgEXgEHoFH4BF4RED4BD6BbwefQ51D nYffw+/h95tfNIOlb6CnOKUwpSUnUDroGN4+xse49rcH2LNy1gzUjnOuUkVGXVji13wJS87xZU2v pzSmkAVFSYdszIfyP9TO8XIKqaf2+UDnsKahaaiLpUHT+fszZPV7aJofK0FEBhEZRGTuEXmPETRY gebXSP6fI23bwEjbSv4+0lWAAQDUKZiEDWVuZHN0cmVhbQ1lbmRvYmoNNjA5IDAgb2JqDTw8L0Rl Y29kZVBhcm1zPDwvQ29sdW1ucyA1L1ByZWRpY3RvciAxMj4+L0ZpbHRlci9GbGF0ZURlY29kZS9J RFs8NkFBRkExODU0QzJDRTFEQzkwMUI0N0E5QTEyQjYzQTE+PEM4OEQxRDczNDAzQzQ5QTA5NzRD NTBFRjY4NTJGNTFDPl0vSW5kZXhbMiAxIDI1MSAxIDI1OCAxIDQxNSAxIDU5OSAxMV0vSW5mbyAy IDAgUi9MZW5ndGggNjYvUHJldiA5NzE1Ni9Sb290IDEgMCBSL1NpemUgNjEwL1R5cGUvWFJlZi9X WzEgMyAxXT4+c3RyZWFtDQpo3mJiZKy5y8DE+L+tmYGJAQgYmf4z1rz4D2TzG4JEmDrA4gUgknka gs1oCib/gEiWvQhxJnOweCwDQIABALBWDCUNZW5kc3RyZWFtDWVuZG9iag1zdGFydHhyZWYNMTA1 MzIxDSUlRU9GDTIgMCBvYmoNPDwvQXV0aG9yKCkvQ3JlYXRpb25EYXRlKEQ6MjAxNzA4MjExMzAw NTAtMDcnMDAnKS9DcmVhdG9yKGh0bWwycHMgdmVyc2lvbiAxLjAgYmV0YTcpL0tleXdvcmRzKCkv TW9kRGF0ZShEOjIwMTcwOTA3MTcxNjExKzAyJzAwJykvUHJvZHVjZXIoR1BMIEdob3N0c2NyaXB0 IDkuMDYpL1N1YmplY3QoKS9UaXRsZShkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFv Y2ItMDQgLSBUcmFuc21pc3Npb24gb2YgSVB2NiBQYWNrZXRzIG92ZXIgSUVFRSA4MDIuMTEgTmV0 d29ya3MgaW4gbW9kZSBPdXRzaWRlIHRoZSBDb250ZXh0IG9mIGEgQmFzaWMgU2VydmljZSBTZXQg gUlQdjYtb3Zlci04MDIxMW9jYoIpPj4NZW5kb2JqDTQxNSAwIG9iag08PC9MZW5ndGggMzgxMS9T dWJ0eXBlL1hNTC9UeXBlL01ldGFkYXRhPj5zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0i77u/IiBp ZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+Cjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6 bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuNi1jMDE1IDg0LjE1OTgxMCwgMjAx Ni8wOS8xMC0wMjo0MTozMCAgICAgICAgIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8v d3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6cGRmPSJodHRwOi8vbnMuYWRvYmUu Y29tL3BkZi8xLjMvIgogICAgICAgICAgICB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8iCiAgICAgICAgICAgIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hh cC8xLjAvbW0vIgogICAgICAgICAgICB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1l bnRzLzEuMS8iPgogICAgICAgICA8cGRmOlByb2R1Y2VyPkdQTCBHaG9zdHNjcmlwdCA5LjA2PC9w ZGY6UHJvZHVjZXI+CiAgICAgICAgIDxwZGY6S2V5d29yZHMvPgogICAgICAgICA8eG1wOk1vZGlm eURhdGU+MjAxNy0wOS0wN1QxNzoxNjoxMSswMjowMDwveG1wOk1vZGlmeURhdGU+CiAgICAgICAg IDx4bXA6Q3JlYXRlRGF0ZT4yMDE3LTA4LTIxVDEzOjAwOjUwLTA3OjAwPC94bXA6Q3JlYXRlRGF0 ZT4KICAgICAgICAgPHhtcDpDcmVhdG9yVG9vbD5odG1sMnBzIHZlcnNpb24gMS4wIGJldGE3PC94 bXA6Q3JlYXRvclRvb2w+CiAgICAgICAgIDx4bXA6TWV0YWRhdGFEYXRlPjIwMTctMDktMDdUMTc6 MTY6MTErMDI6MDA8L3htcDpNZXRhZGF0YURhdGU+CiAgICAgICAgIDx4bXBNTTpEb2N1bWVudElE PnV1aWQ6ZmFhOGE5NzAtYmVjNy0xMWYyLTAwMDAtOTkzMjQzNjI2MjBiPC94bXBNTTpEb2N1bWVu dElEPgogICAgICAgICA8eG1wTU06SW5zdGFuY2VJRD51dWlkOmY5Y2NjM2E1LWJhZmMtZGE0Mi04 YmQ3LTNiYTFmZGZkZmUzNjwveG1wTU06SW5zdGFuY2VJRD4KICAgICAgICAgPGRjOmZvcm1hdD5h cHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAg ICA8cmRmOkFsdD4KICAgICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5k cmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMDQgLSBUcmFuc21pc3Npb24gb2Yg SVB2NiBQYWNrZXRzIG92ZXIgSUVFRSA4MDIuMTEgTmV0d29ya3MgaW4gbW9kZSBPdXRzaWRlIHRo ZSBDb250ZXh0IG9mIGEgQmFzaWMgU2VydmljZSBTZXQg4oCgSVB2Ni1vdmVyLTgwMjExb2Ni4oCh PC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOkFsdD4KICAgICAgICAgPC9kYzp0aXRsZT4KICAg ICAgICAgPGRjOmNyZWF0b3I+CiAgICAgICAgICAgIDxyZGY6U2VxPgogICAgICAgICAgICAgICA8 cmRmOmxpLz4KICAgICAgICAgICAgPC9yZGY6U2VxPgogICAgICAgICA8L2RjOmNyZWF0b3I+CiAg ICAgICAgIDxkYzpkZXNjcmlwdGlvbj4KICAgICAgICAgICAgPHJkZjpBbHQ+CiAgICAgICAgICAg ICAgIDxyZGY6bGkgeG1sOmxhbmc9IngtZGVmYXVsdCIvPgogICAgICAgICAgICAgICA8cmRmOmxp IHhtbDpsYW5nPSJ4LXJlcGFpciIvPgogICAgICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAgIDwv ZGM6ZGVzY3JpcHRpb24+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+Cjwv eDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgCjw/eHBhY2tldCBlbmQ9InciPz4NZW5kc3RyZWFtDWVuZG9iag02MDUgMCBvYmoNPDwv QVA8PC9OIDYyNSAwIFI+Pi9DWzAuMCAwLjAgMS4wXS9Db250ZW50cygiLCBmb3IgZXhhbXBsZSB1 c2luZyBhIHByb3BlciBQS0kgdG8gc2VjdXJlIG1lc3NhZ2VzLiJcclxyQW5kIGhlcmUgaXQgd291 bGQgYmUgcG9zc2libGUgdG8gY2l0ZSBjdXJyZW50IEVUU0kgZG9jdW1lbnRzIHJlZ2FyZGluZyBz ZWN1cml0eSB1c2luZyBQS0ksIGFsdGhvdWdoIGZyb20gbXkgdW5kZXJzdGFuZGluZyB0aGVyZSBp cyBub3QgbWFueSBleHBsaWNpdCBjaXRlcyB0byBJUHY2IGhlcmUuXHJcclxyWzJdLiBFVFNJIFRT IDEwMiA5NDAgVjFcDS4yLjEsIEludGVsbGlnZW50IFRyYW5zcG9ydCBTeXN0ZW1zIFwoSVRTXCk7 IFNlY3VyaXR5OyBJVFMgY29tbXVuaWNhdGlvbnMgc2VjdXJpdHkgYXJjaGl0ZWN0dXJlIGFuZCBz ZWN1cml0eSBtYW5hZ2VtZW50LCBKdW5lIDIwMTIuIFxyXHJbNV0uIEVUU0kgVFMgMTAzIDA5NyBW Mi4wLjUsIEludGVsbGlnZW50IFRyYW5zcG9ydCBTeXN0ZW1zIFwoSVRTXCk7IFNlY3VyaXR5OyBT ZWN1cml0eSBoZWFkZXIgYW5kIGNlcnRpZmljYXRlIGZvcm1hdHMuIFwNXChUQkQuIFN0YW5kYXJk IG5vdCB5ZXQgcHVibGlzaGVkXCkuIFxyXHJJbnRlcmVzdGluZyBpbiB0aGUgZmlyc3Qgb25lIHRo ZSBuZXh0IHRleHQgYWJvdXQgIkxvdy1zcGVlZCB1bmljYXN0IHNlcnZpY2VzIjpcblxuIFRoZXNl IHNlcnZpY2VzIGRpZmZlciBmcm9tIGhpZ2gtc3BlZWQgdW5pY2FzdCBzZXJ2aWNlcyBpbiB0aGF0 IHRoZSBvZmYtdmVoaWNsZSBlbmQgb2YgdGhlIGNvbW11bmljYXRpb25zIHNlc3Npb24gbWF5IGJl XG5yZW1vdGUgb3ZlXA1yIHRoZSBuZXR3b3JrLiBUaGUgYXBwbGljYXRpb24gY2Fubm90IHJlbHkg b24gcmFwaWQgZXhjaGFuZ2Ugb2YgbGFyZ2UgYW1vdW50cyBvZiBpbmZvcm1hdGlvbiBhbmQgd2ls bCBoYXZlXG5oaWdoZXIgbGF0ZW5jeSB0aGFuIHRoZSBoaWdoLXNwZWVkIHVuaWNhc3Qgc2Vydmlj ZS5cbkluIGdlbmVyYWwsIHRoZXNlIHNlcnZpY2VzIHdpbGwgdXNlIGFuIElQIGNvbm5lY3Rpb24g YW5kIHNvIHRoZSB1c2Ugb2YgZXhpc3RpbmcgSVAgc2VjdXJpdHkgbWVcDWNoYW5pc21zIG1heSBi ZVxuYXBwcm9wcmlhdGUuXG5OT1RFOiBJbiBnZW5lcmFsIGZvciBJVFMgSVAgY29ubmVjdGlvbnMg SXB2NiB3aWxsIGJlIHVzZWQgYWx0aG91Z2ggdGhlIHByZXNlbnQgZG9jdW1lbnQgZG9lcyBub3Qg ZGlzYWxsb3cgYW55XG5vdGhlciB2YXJpYW50IG9mIElQLlxyKS9DcmVhdGlvbkRhdGUoRDoyMDE3 MDkwNzE2NDQ0NCswMicwMCcpL0YgNC9NKEQ6MjAxNzA5MDcxNzA2MjUrMDInMDAnKS9OTShjODlk NmFhZS0wZjdkLTFhNGQtODMxMC1lZGU0YTVjOTdlNjgpL1AgMjUxIDAgUi9Qb3B1cCA2MDYgMCBS L1JDKDw/eG1sIHZlcnNpb249IjEuMCI/Pjxib2R5IHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8x OTk5L3hodG1sIiB4bWxuczp4ZmE9Imh0dHA6Ly93d3cueGZhLm9yZy9zY2hlbWEveGZhLWRhdGEv MS4wLyIgeGZhOkFQSVZlcnNpb249IkFjcm9iYXQ6MTcuMTIuMCIgeGZhOnNwZWM9IjIuMC4yIiA+ PHAgZGlyPSJsdHIiPjxzcGFuIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDt0ZXh0 LWFsaWduOmxlZnQ7Y29sb3I6IzAwMDAwMDtmb250LVwNd2VpZ2h0Om5vcm1hbDtmb250LXN0eWxl Om5vcm1hbCI+JnF1b3Q7LCBmb3IgZXhhbXBsZSB1c2luZyBhIHByb3BlciBQS0kgdG8gc2VjdXJl IG1lc3NhZ2VzLiZxdW90OyYjMTM7JiMxMztBbmQgaGVyZSBpdCB3b3VsZCBiZSBwb3NzaWJsZSB0 byBjaXRlIGN1cnJlbnQgRVRTSSBkb2N1bWVudHMgcmVnYXJkaW5nIHNlY3VyaXR5IHVzaW5nIFBL SSwgYWx0aG91Z2ggZnJvbSBteSB1bmRlcnN0YW5kaW5nIHRoZXJlIGlzIG5vdCBtYW55IGV4cGxp Y2l0XA0gY2l0ZXMgdG8gSVB2NiBoZXJlLiYjMTM7JiMxMzsmIzEzO1syXS4gRVRTSSBUUyAxMDIg OTQwIFYxLjIuMSwgSW50ZWxsaWdlbnQgVHJhbnNwb3J0IFN5c3RlbXMgXChJVFNcKTsgU2VjdXJp dHk7IElUUyBjb21tdW5pY2F0aW9ucyBzZWN1cml0eSBhcmNoaXRlY3R1cmUgYW5kIHNlY3VyaXR5 IG1hbmFnZW1lbnQsIEp1bmUgMjAxMi4gJiMxMzsmIzEzO1s1XS4gRVRTSSBUUyAxMDMgMDk3IFYy LjAuNSwgSW50ZWxsaWdlbnQgVHJhbnNwb3J0IFN5c3RcDWVtcyBcKElUU1wpOyBTZWN1cml0eTsg U2VjdXJpdHkgaGVhZGVyIGFuZCBjZXJ0aWZpY2F0ZSBmb3JtYXRzLiBcKFRCRC4gU3RhbmRhcmQg bm90IHlldCBwdWJsaXNoZWRcKS4gJiMxMzsmIzEzO0ludGVyZXN0aW5nIGluIHRoZSBmaXJzdCBv bmUgdGhlIG5leHQgdGV4dCBhYm91dCAmcXVvdDtMb3ctc3BlZWQgdW5pY2FzdCBzZXJ2aWNlcyZx dW90OzomIzEwOyYjMTA7PC9zcGFuPjxzcGFuIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdFwNO3RleHQtYWxpZ246bGVmdDtjb2xvcjojMDAwMDAwO2ZvbnQtd2VpZ2h0Om5vcm1hbDtm b250LXN0eWxlOm5vcm1hbCI+IFRoZXNlIHNlcnZpY2VzIGRpZmZlciBmcm9tIGhpZ2gtc3BlZWQg dW5pY2FzdCBzZXJ2aWNlcyBpbiB0aGF0IHRoZSBvZmYtdmVoaWNsZSBlbmQgb2YgdGhlIGNvbW11 bmljYXRpb25zIHNlc3Npb24gbWF5IGJlJiMxMDtyZW1vdGUgb3ZlciB0aGUgbmV0d29yay4gVGhl IGFwcGxpY2F0aW9uIGNhbm5vdCByZWx5IG9uIHJhcGlkXA0gZXhjaGFuZ2Ugb2YgbGFyZ2UgYW1v dW50cyBvZiBpbmZvcm1hdGlvbiBhbmQgd2lsbCBoYXZlJiMxMDtoaWdoZXIgbGF0ZW5jeSB0aGFu IHRoZSBoaWdoLXNwZWVkIHVuaWNhc3Qgc2VydmljZS4mIzEwO0luIGdlbmVyYWwsIHRoZXNlIHNl cnZpY2VzIHdpbGwgdXNlIGFuIElQIGNvbm5lY3Rpb24gYW5kIHNvIHRoZSB1c2Ugb2YgZXhpc3Rp bmcgSVAgc2VjdXJpdHkgbWVjaGFuaXNtcyBtYXkgYmUmIzEwO2FwcHJvcHJpYXRlLiYjMTA7Tk9U RTogSW5cDSBnZW5lcmFsIGZvciBJVFMgSVAgY29ubmVjdGlvbnMgSXB2NiB3aWxsIGJlIHVzZWQg YWx0aG91Z2ggdGhlIHByZXNlbnQgZG9jdW1lbnQgZG9lcyBub3QgZGlzYWxsb3cgYW55JiMxMDtv dGhlciB2YXJpYW50IG9mIElQLjwvc3Bhbj48c3BhbiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7dGV4dC1hbGlnbjpsZWZ0O2NvbG9yOiMwMDAwMDA7Zm9udC13ZWlnaHQ6bm9ybWFs O2ZvbnQtc3R5bGU6bm9ybWFsIj4mIzEzOzwvc3Bhbj48L1wNcD48L2JvZHk+KS9SRFswLjU1ODg2 OCAwLjU1ODg2OCAwLjU1ODg2OCAwLjU1ODg2OF0vUmVjdFs0MjMuNDEzIDE4OC4xMDYgNDMxLjY0 NCAxOTQuODEyXS9TdWJqKFRleHRvIGluc2VydGFkbykvU3VidHlwZS9DYXJldC9UKEpvc2UpL1R5 cGUvQW5ub3Q+Pg1lbmRvYmoNNjEwIDAgb2JqDTw8L0FQPDwvTiA2MjIgMCBSPj4vQ1sxLjAgMC44 MTk2MTEgMC4wXS9Db250ZW50cyhXaHkgbm90IGEgIlNIT1VMRCIuIEluIG91ciBjYXNlIHdlIGRv IG5vdCB1c2UgImZhc3QiIGFjaGlldmVudHMgYW5kIGl0IHdvcmtzIHF1aXRlIHdlbGwgXChpbiBv dXIgLXJlc2VhcmNoLSBzY2VuYXJpbyB3aXRoIE5FTU8gKyBNQ09BICsgSUVFRSA4MDIuMjFcKS4g VGhpcyBkb2VzIG5vdCBtZWFucyB0aGF0IGluY2x1ZGluZyAiZmFzdCIgYWNoaWV2ZW10cyBvdXIg c29sdXRpb24gY2FuIGltcHJvdmUsIG9mIGNvdXJzZS4pL0NyZWF0aW9uRGF0ZShEOjIwMTcwOTA3 MTcxMTMxKzAyJzAwJykvRiA0L00oRDoyMDE3MDkwNzE3MTMxOSswMicwMCcpL05NKDQwMWY1MDE2 LTkzZDQtNGY0Mi1iMjkyLTAzY2EwNzdlMzBjOSkvUCAzODYgMCBSL1BvcHVwIDYxMSAwIFIvUXVh ZFBvaW50c1sxNTQuMTU5IDUxOS43MDggMTc3LjkxOCA1MTkuNzA4IDE1NC4xNTkgNTA5LjI5MyAx NzcuOTE4IDUwOS4yOTNdL1JDKDw/eG1sIHZlcnNpb249IjEuMCI/Pjxib2R5IHhtbG5zPSJodHRw Oi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWxuczp4ZmE9Imh0dHA6Ly93d3cueGZhLm9yZy9z Y2hlbWEveGZhLWRhdGEvMS4wLyIgeGZhOkFQSVZlcnNpb249IkFjcm9iYXQ6MTcuMTIuMCIgeGZh OnNwZWM9IjIuMC4yIiA+PHAgZGlyPSJsdHIiPjxzcGFuIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1z aXplOjE0LjBwdDt0ZXh0LWFsaWduOmxlZnQ7Y29sb3I6IzAwMDAwMDtmb250LVwNd2VpZ2h0Om5v cm1hbDtmb250LXN0eWxlOm5vcm1hbCI+V2h5IG5vdCBhICZxdW90O1NIT1VMRCZxdW90Oy4gSW4g b3VyIGNhc2Ugd2UgZG8gbm90IHVzZSAmcXVvdDtmYXN0JnF1b3Q7IGFjaGlldmVudHMgYW5kIGl0 IHdvcmtzIHF1aXRlIHdlbGwgXChpbiBvdXIgLXJlc2VhcmNoLSBzY2VuYXJpbyB3aXRoIE5FTU8g KyBNQ09BICsgSUVFRSA4MDIuMjFcKS4gVGhpcyBkb2VzIG5vdCBtZWFucyB0aGF0IGluY2x1ZGlu ZyAmcXVvdDtmYXN0JnF1b3Q7XA0gYWNoaWV2ZW10cyBvdXIgc29sdXRpb24gY2FuIGltcHJvdmUs IG9mIGNvdXJzZS48L3NwYW4+PC9wPjwvYm9keT4pL1JlY3RbMTUxLjM3OSA1MDguOTY4IDE4MC42 OTkgNTIwLjAzM10vU3ViaihSZXNhbHRhZG8pL1N1YnR5cGUvSGlnaGxpZ2h0L1QoSm9zZSkvVHlw ZS9Bbm5vdD4+DWVuZG9iag02MTEgMCBvYmoNPDwvRiAyOC9PcGVuIGZhbHNlL1BhcmVudCA2MTAg MCBSL1JlY3RbNTk1LjAgMzc3LjcwOCA3NzUuMCA1MTkuNzA4XS9TdWJ0eXBlL1BvcHVwL1R5cGUv QW5ub3Q+Pg1lbmRvYmoNNjEyIDAgb2JqDTw8L0FQPDwvTiA2MTkgMCBSPj4vQ1sxLjAgMC44MTk2 MTEgMC4wXS9Db250ZW50cyhvciBhIHRyYW5zY2VpdmVyIHN1cHBvcnRpbmcgbW9yZSB0aGFuIG9u ZSBjaGFubm5lbCB0byBiZSB1c2VkIHNpbXVsdGFuZW91c2x5LikvQ3JlYXRpb25EYXRlKEQ6MjAx NzA5MDcxNzE0MDQrMDInMDAnKS9GIDQvTShEOjIwMTcwOTA3MTcxNDM5KzAyJzAwJykvTk0oMTlm YWFmZmYtZmZlZS1jOTQ5LWIzN2QtZGFmMDZhMmQ1ODE0KS9QIDM4NiAwIFIvUG9wdXAgNjEzIDAg Ui9RdWFkUG9pbnRzWzg4LjgxOTcgNDcyLjE4NyA0NjguOTc0IDQ3Mi4xODcgODguODE5NyA0NjEu NzczIDQ2OC45NzQgNDYxLjc3MyA4OC44MTk3IDQ2MC4zMDcgMTk1LjczOCA0NjAuMzA3IDg4Ljgx OTcgNDQ5Ljg5MyAxOTUuNzM4IDQ0OS44OTNdL1JDKDw/eG1sIHZlcnNpb249IjEuMCI/Pjxib2R5 IHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWxuczp4ZmE9Imh0dHA6Ly93 d3cueGZhLm9yZy9zY2hlbWEveGZhLWRhdGEvMS4wLyIgeGZhOkFQSVZlcnNpb249IkFjcm9iYXQ6 MTcuMTIuMCIgeGZhOnNwZWM9IjIuMC4yIiA+PHAgZGlyPSJsdHIiPjxzcGFuIGRpcj0ibHRyIiBz dHlsZT0iZm9udC1zaXplOjE0LjBwdDt0ZXh0LWFsaWduOmxlZnQ7Y29sb3I6IzAwMDAwMDtmb250 LVwNd2VpZ2h0Om5vcm1hbDtmb250LXN0eWxlOm5vcm1hbCI+b3IgYSB0cmFuc2NlaXZlciBzdXBw b3J0aW5nIG1vcmUgdGhhbiBvbmUgY2hhbm5uZWwgdG8gYmUgdXNlZCBzaW11bHRhbmVvdXNseS48 L3NwYW4+PC9wPjwvYm9keT4pL1JlY3RbODYuMDM5NSA0NDkuNTY3IDQ3MS43NTQgNDcyLjUxM10v U3ViaihSZXNhbHRhZG8pL1N1YnR5cGUvSGlnaGxpZ2h0L1QoSm9zZSkvVHlwZS9Bbm5vdD4+DWVu ZG9iag02MTMgMCBvYmoNPDwvRiAyOC9PcGVuIGZhbHNlL1BhcmVudCA2MTIgMCBSL1JlY3RbNTk1 LjAgMzMwLjE4NyA3NzUuMCA0NzIuMTg3XS9TdWJ0eXBlL1BvcHVwL1R5cGUvQW5ub3Q+Pg1lbmRv YmoNNjE0IDAgb2JqDTw8L0FQPDwvTiA2MTYgMCBSPj4vQ1sxLjAgMC44MTk2MTEgMC4wXS9DcmVh dGlvbkRhdGUoRDoyMDE3MDkwNzE3MTU1NiswMicwMCcpL0YgNC9NKEQ6MjAxNzA5MDcxNzE1NTYr MDInMDAnKS9OTShlNGQ1OGFhMy1mZDc4LWM5NDctYjliMC0yN2JjY2U4NDM1MmYpL1AgMzg2IDAg Ui9Qb3B1cCA2MTUgMCBSL1F1YWRQb2ludHNbMjU1LjEzNyAyNDYuNDY2IDI2Ny4wMTcgMjQ2LjQ2 NiAyNTUuMTM3IDIzNi4wNTEgMjY3LjAxNyAyMzYuMDUxXS9SZWN0WzI1Mi4zNTcgMjM1LjcyNSAy NjkuNzk3IDI0Ni43OTFdL1N1YmooUmVzYWx0YWRvKS9TdWJ0eXBlL0hpZ2hsaWdodC9UKEpvc2Up L1R5cGUvQW5ub3Q+Pg1lbmRvYmoNNjE1IDAgb2JqDTw8L0YgMjgvT3BlbiBmYWxzZS9QYXJlbnQg NjE0IDAgUi9SZWN0WzU5NS4wIDEwNC40NjYgNzc1LjAgMjQ2LjQ2Nl0vU3VidHlwZS9Qb3B1cC9U eXBlL0Fubm90Pj4NZW5kb2JqDTYxNiAwIG9iag08PC9CQm94WzAuMCAwLjAgMTcuNDQwMiAxMS4w NjU2XS9Gb3JtVHlwZSAxL0xlbmd0aCAyMC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBd L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUv RXh0R1N0YXRlPj4+Pi9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9NV0ZPRm9ybSA2MTcgMCBSPj4+ Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9SMCBncwovTVdGT0Zvcm0gRG8K DWVuZHN0cmVhbQ1lbmRvYmoNNjE3IDAgb2JqDTw8L0JCb3hbMC4wIDAuMCAxNy40NDAyIDExLjA2 NTZdL0Zvcm1UeXBlIDEvR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L0xlbmd0aCA5L01hdHJpeFsx LjAgMC4wIDAuMCAxLjAgMC4wIDAuMF0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGXS9YT2JqZWN0 PDwvRm9ybSA2MTggMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9G b3JtIERvCg1lbmRzdHJlYW0NZW5kb2JqDTYxOCAwIG9iag08PC9CQm94WzI1Mi4zNTcgMjM1Ljcy NSAyNjkuNzk3IDI0Ni43OTFdL0Zvcm1UeXBlIDEvTGVuZ3RoIDE3OS9NYXRyaXhbMS4wIDAuMCAw LjAgMS4wIC0yNTIuMzU3IC0yMzUuNzI1XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3Vi dHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQoxIDAuODE5NjExIDAgcmcKMC42NTA5IHcK MjU1LjEzNzIgMjM2LjA1MDkgbQoyNTIuNjgyNSAyMzguNTA1NyAyNTIuNjgyNSAyNDQuMDEwOCAy NTUuMTM3MiAyNDYuNDY1NiBjCjI2Ny4wMTcxIDI0Ni40NjU2IGwKMjY5LjQ3MTggMjQ0LjAxMDgg MjY5LjQ3MTggMjM4LjUwNTcgMjY3LjAxNzEgMjM2LjA1MDkgYwpmCg1lbmRzdHJlYW0NZW5kb2Jq DTYxOSAwIG9iag08PC9CQm94WzAuMCAwLjAgMzg1LjcxNSAyMi45NDU3XS9Gb3JtVHlwZSAxL0xl bmd0aCAyMC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L0V4dEdT dGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pi9Qcm9j U2V0Wy9QREZdL1hPYmplY3Q8PC9NV0ZPRm9ybSA2MjAgMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlw ZS9YT2JqZWN0Pj5zdHJlYW0NCi9SMCBncwovTVdGT0Zvcm0gRG8KDWVuZHN0cmVhbQ1lbmRvYmoN NjIwIDAgb2JqDTw8L0JCb3hbMC4wIDAuMCAzODUuNzE1IDIyLjk0NTddL0Zvcm1UeXBlIDEvR3Jv dXA8PC9TL1RyYW5zcGFyZW5jeT4+L0xlbmd0aCA5L01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgMC4w IDAuMF0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGXS9YT2JqZWN0PDwvRm9ybSA2MjEgMCBSPj4+ Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9Gb3JtIERvCg1lbmRzdHJlYW0N ZW5kb2JqDTYyMSAwIG9iag08PC9CQm94Wzg2LjAzOTUgNDQ5LjU2NyA0NzEuNzU0IDQ3Mi41MTNd L0ZpbHRlclsvRmxhdGVEZWNvZGVdL0Zvcm1UeXBlIDEvTGVuZ3RoIDE1MS9NYXRyaXhbMS4wIDAu MCAwLjAgMS4wIC04Ni4wMzk1IC00NDkuNTY3XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4v U3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiWyOuw3DMAxEe03BCQ4iRfEzj4G4 cZo0WT8yYEsu0pEPeHfHVBGcxkyVPnupsF6TviXi5E5qDHcJepcwNOuDKES80/wT3sRpKi7gcKWt qAVyXBMdRZ2hErG8B7mSp3aXb+X1Z5omIkfAmtYFTYc4f0d0sTXNKlr1NgI5+6gPXuwYLMApucQH uaKXd9ef434CDAC6pEC/DWVuZHN0cmVhbQ1lbmRvYmoNNjIyIDAgb2JqDTw8L0JCb3hbMC4wIDAu MCAyOS4zMjAxIDExLjA2NTZdL0Zvcm1UeXBlIDEvTGVuZ3RoIDIwL01hdHJpeFsxLjAgMC4wIDAu MCAxLjAgMC4wIDAuMF0vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0v TXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+L1Byb2NTZXRbL1BERl0vWE9iamVjdDw8L01XRk9G b3JtIDYyMyAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KL1IwIGdz Ci9NV0ZPRm9ybSBEbwoNZW5kc3RyZWFtDWVuZG9iag02MjMgMCBvYmoNPDwvQkJveFswLjAgMC4w IDI5LjMyMDEgMTEuMDY1Nl0vRm9ybVR5cGUgMS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vTGVu Z3RoIDkvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8PC9Qcm9jU2V0 Wy9QREZdL1hPYmplY3Q8PC9Gb3JtIDYyNCAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmpl Y3Q+PnN0cmVhbQ0KL0Zvcm0gRG8KDWVuZHN0cmVhbQ1lbmRvYmoNNjI0IDAgb2JqDTw8L0JCb3hb MTUxLjM3OSA1MDguOTY4IDE4MC42OTkgNTIwLjAzM10vRm9ybVR5cGUgMS9MZW5ndGggMTc3L01h dHJpeFsxLjAgMC4wIDAuMCAxLjAgLTE1MS4zNzkgLTUwOC45NjhdL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCjEgMC44MTk2MTEg MCByZwowLjY1MDkgdwoxNTQuMTU4OCA1MDkuMjkzMiBtCjE1MS43MDQgNTExLjc0NzkgMTUxLjcw NCA1MTcuMjUzMSAxNTQuMTU4OCA1MTkuNzA3OCBjCjE3Ny45MTg0IDUxOS43MDc4IGwKMTgwLjM3 MzIgNTE3LjI1MzEgMTgwLjM3MzIgNTExLjc0NzkgMTc3LjkxODQgNTA5LjI5MzIgYwpmCg1lbmRz dHJlYW0NZW5kb2JqDTYyNSAwIG9iag08PC9CQm94Wy0wLjU1ODg2OCAtMC41NTg4NjggNy42NzE5 MSA2LjE0NzY0XS9Gb3JtVHlwZSAxL0xlbmd0aCAxMTEvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAw LjU1ODg2OCAwLjU1ODg2OF0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGXT4+L1N1YnR5cGUvRm9y bS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KMCAwIDEgUkcKMC41NTg5IHcKMCAwIDEgcmcKMCAwIG0K My41NTY1IDAgMy41NTY1IDIuNzk0NCAzLjU1NjUgNS41ODg4IGMKMy41NTY1IDIuNzk0NCAzLjU1 NjUgMCA3LjExMyAwIGMKaApmClMKDWVuZHN0cmVhbQ1lbmRvYmoNNjI2IDAgb2JqDTw8L0ZpbHRl ci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAxNTkvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0N CmjeNI5LCoMwEIavkhuMGrUJSKAvuyqIuhMXYofSTaaYKdjbNwnp6mOG/yVVLTLRNHC0lthNUml/ 90LqLLLO/8wTi0SZWCZWgTOcyTJadkKqQ/jAHR+v5UT7FIIqXQlVFjN0y+ZVIoZAj44+24rO77ju fBt4YfQTYiW0FIQ69kK30TogT9BdWhhx59kY6CkaMhi/b/TRTzTmJ8AAo2Y6Aw1lbmRzdHJlYW0N ZW5kb2JqDTYyNyAwIG9iag08PC9EZWNvZGVQYXJtczw8L0NvbHVtbnMgNC9QcmVkaWN0b3IgMTI+ Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvSURbPDZBQUZBMTg1NEMyQ0UxREM5MDFCNDdBOUExMkI2M0Ex Pjw3RTI2NTI5MjM5MzE0MDM3OTQ4MUVCNEY0ODE3NTdCOD5dL0luZGV4WzIgMSAzODYgMSA0MTUg MSA2MDUgMSA2MTAgMThdL0luZm8gMiAwIFIvTGVuZ3RoIDc2L1ByZXYgMTA1MzIxL1Jvb3QgMSAw IFIvU2l6ZSA2MjgvVHlwZS9YUmVmL1dbMSAzIDBdPj5zdHJlYW0NCmjeYmJknHODifF/2iym/4xz LjIxMPAbAgleTiDBugZIMBQACZY2GIsxA0SAWTIg4jWIKAcSTCAuA4jLhCZbChIzB7H+AgQYANOH Dw0NZW5kc3RyZWFtDWVuZG9iag1zdGFydHhyZWYNMTE5MzA4DSUlRU9GDTIgMCBvYmoNPDwvQXV0 aG9yKCkvQ3JlYXRpb25EYXRlKEQ6MjAxNzA4MjExMzAwNTAtMDcnMDAnKS9DcmVhdG9yKGh0bWwy cHMgdmVyc2lvbiAxLjAgYmV0YTcpL0tleXdvcmRzKCkvTW9kRGF0ZShEOjIwMTcwOTA3MTcxNjM1 KzAyJzAwJykvUHJvZHVjZXIoR1BMIEdob3N0c2NyaXB0IDkuMDYpL1N1YmplY3QoKS9UaXRsZShk cmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMDQgLSBUcmFuc21pc3Npb24gb2Yg SVB2NiBQYWNrZXRzIG92ZXIgSUVFRSA4MDIuMTEgTmV0d29ya3MgaW4gbW9kZSBPdXRzaWRlIHRo ZSBDb250ZXh0IG9mIGEgQmFzaWMgU2VydmljZSBTZXQggUlQdjYtb3Zlci04MDIxMW9jYoIpPj4N ZW5kb2JqDTQxNSAwIG9iag08PC9MZW5ndGggMzgxMS9TdWJ0eXBlL1hNTC9UeXBlL01ldGFkYXRh Pj5zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3pr YzlkIj8+Cjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2Jl IFhNUCBDb3JlIDUuNi1jMDE1IDg0LjE1OTgxMCwgMjAxNi8wOS8xMC0wMjo0MTozMCAgICAgICAg Ij4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJk Zi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAg ICAgICAgeG1sbnM6cGRmPSJodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvIgogICAgICAgICAg ICB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iCiAgICAgICAgICAgIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIgogICAgICAgICAgICB4 bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iPgogICAgICAgICA8cGRm OlByb2R1Y2VyPkdQTCBHaG9zdHNjcmlwdCA5LjA2PC9wZGY6UHJvZHVjZXI+CiAgICAgICAgIDxw ZGY6S2V5d29yZHMvPgogICAgICAgICA8eG1wOk1vZGlmeURhdGU+MjAxNy0wOS0wN1QxNzoxNjoz NSswMjowMDwveG1wOk1vZGlmeURhdGU+CiAgICAgICAgIDx4bXA6Q3JlYXRlRGF0ZT4yMDE3LTA4 LTIxVDEzOjAwOjUwLTA3OjAwPC94bXA6Q3JlYXRlRGF0ZT4KICAgICAgICAgPHhtcDpDcmVhdG9y VG9vbD5odG1sMnBzIHZlcnNpb24gMS4wIGJldGE3PC94bXA6Q3JlYXRvclRvb2w+CiAgICAgICAg IDx4bXA6TWV0YWRhdGFEYXRlPjIwMTctMDktMDdUMTc6MTY6MzUrMDI6MDA8L3htcDpNZXRhZGF0 YURhdGU+CiAgICAgICAgIDx4bXBNTTpEb2N1bWVudElEPnV1aWQ6ZmFhOGE5NzAtYmVjNy0xMWYy LTAwMDAtOTkzMjQzNjI2MjBiPC94bXBNTTpEb2N1bWVudElEPgogICAgICAgICA8eG1wTU06SW5z dGFuY2VJRD51dWlkOmNlYmMzMmJhLTFhNzMtNzk0ZC1hNWZhLTlmOGYwYzZmMDlkMDwveG1wTU06 SW5zdGFuY2VJRD4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1h dD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAgICAgICAg ICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5kcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92 ZXItODAyMTFvY2ItMDQgLSBUcmFuc21pc3Npb24gb2YgSVB2NiBQYWNrZXRzIG92ZXIgSUVFRSA4 MDIuMTEgTmV0d29ya3MgaW4gbW9kZSBPdXRzaWRlIHRoZSBDb250ZXh0IG9mIGEgQmFzaWMgU2Vy dmljZSBTZXQg4oCgSVB2Ni1vdmVyLTgwMjExb2Ni4oChPC9yZGY6bGk+CiAgICAgICAgICAgIDwv cmRmOkFsdD4KICAgICAgICAgPC9kYzp0aXRsZT4KICAgICAgICAgPGRjOmNyZWF0b3I+CiAgICAg ICAgICAgIDxyZGY6U2VxPgogICAgICAgICAgICAgICA8cmRmOmxpLz4KICAgICAgICAgICAgPC9y ZGY6U2VxPgogICAgICAgICA8L2RjOmNyZWF0b3I+CiAgICAgICAgIDxkYzpkZXNjcmlwdGlvbj4K ICAgICAgICAgICAgPHJkZjpBbHQ+CiAgICAgICAgICAgICAgIDxyZGY6bGkgeG1sOmxhbmc9Ingt ZGVmYXVsdCIvPgogICAgICAgICAgICAgICA8cmRmOmxpIHhtbDpsYW5nPSJ4LXJlcGFpciIvPgog ICAgICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAgIDwvZGM6ZGVzY3JpcHRpb24+CiAgICAgIDwv cmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9Inci Pz4NZW5kc3RyZWFtDWVuZG9iag02MjggMCBvYmoNPDwvQVA8PC9OIDYzMCAwIFI+Pi9DWzAuODk4 MDQxIDAuMTMzMzMxIDAuMjE1NjgzXS9DcmVhdGlvbkRhdGUoRDoyMDE3MDkwNzE3MTYyNCswMicw MCcpL0YgNC9NKEQ6MjAxNzA5MDcxNzE2MjQrMDInMDAnKS9OTSg5NTRmMGM1OC1iODJiLWMyNDgt YjQxYS02MDFiZDhlNGJhNjYpL1AgMzkzIDAgUi9Qb3B1cCA2MjkgMCBSL1F1YWRQb2ludHNbMjk2 LjcxNyA3MjEuNjcgMzAyLjY1NyA3MjEuNjcgMjk2LjcxNyA3MTEuMjU1IDMwMi42NTcgNzExLjI1 NV0vUmVjdFsyOTMuNjExIDcxMC42MDQgMzA1Ljc2MiA3MjIuMzIxXS9TdWJqKFRhY2hhZG8pL1N1 YnR5cGUvU3RyaWtlT3V0L1QoSm9zZSkvVHlwZS9Bbm5vdD4+DWVuZG9iag02MjkgMCBvYmoNPDwv RiAyOC9PcGVuIGZhbHNlL1BhcmVudCA2MjggMCBSL1JlY3RbNTk1LjAgNTc5LjY3IDc3NS4wIDcy MS42N10vU3VidHlwZS9Qb3B1cC9UeXBlL0Fubm90Pj4NZW5kb2JqDTYzMCAwIG9iag08PC9CQm94 WzI5My42MTEgNzEwLjYwNCAzMDUuNzYyIDcyMi4zMjFdL0Zvcm1UeXBlIDEvTGVuZ3RoIDgxL01h dHJpeFsxLjAgMC4wIDAuMCAxLjAgLTI5My42MTEgLTcxMC42MDRdL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCjAuODk4MDQxIDAu MTMzMzMxIDAuMjE1NjgzIFJHCjAuNjUwOSB3CjI5Ni43MTY2IDcxNS43MTg1IG0KMzAyLjY1NjUg NzE1LjcxODUgbApTCg1lbmRzdHJlYW0NZW5kb2JqDTYzMSAwIG9iag08PC9GaWx0ZXIvRmxhdGVE ZWNvZGUvRmlyc3QgNi9MZW5ndGggMTU2L04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3iyNywqD MBBFfyV/MKlRa0ACfdlVQaI7cSF2kG6Skkwh/ftOg6vDmblzR2klpGhbODnnKU5K1+xWKH3c2ezU mXXR7Mw+w8U7QkeRE+V/Ag98vpazT5NkrXQlmrKYoV8Cp4TKEYvRf8KKkf/eEt0HWghFKWXedtzI csjSB78OSBP01w5GTDQbA9bnAwnj941cvaExPwEGAC/UNx8NZW5kc3RyZWFtDWVuZG9iag02MzIg MCBvYmoNPDwvRGVjb2RlUGFybXM8PC9Db2x1bW5zIDQvUHJlZGljdG9yIDEyPj4vRmlsdGVyL0Zs YXRlRGVjb2RlL0lEWzw2QUFGQTE4NTRDMkNFMURDOTAxQjQ3QTlBMTJCNjNBMT48OUVDMzQ5QzU4 MjM2NDI2RDg5NDE5QzFDQzFBMEMxRUM+XS9JbmRleFsyIDEgMzkzIDEgNDE1IDEgNjI4IDVdL0lu Zm8gMiAwIFIvTGVuZ3RoIDQ0L1ByZXYgMTE5MzA4L1Jvb3QgMSAwIFIvU2l6ZSA2MzMvVHlwZS9Y UmVmL1dbMSAzIDBdPj5zdHJlYW0NCmjeYmJkvNzGxPhf/yPTf8ZLVUwMDAKGQIIxD0gwgAgmERD3 F0CAAQDJXwgHDWVuZHN0cmVhbQ1lbmRvYmoNc3RhcnR4cmVmDTEyNDk0MA0lJUVPRg0= --Apple-Mail=_6C4FB1E6-5F1C-4947-8CF5-867D918B36DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

-- 
Jos=C3=A9= Santa Lozano
Department = of Information and Communication Engineering
Faculty of Computer Science
University of = Murcia
30100 = Murcia, Spain
Phone: +34-868-884616 / +34-868-884455
Fax: +34-868-884151
Web: http://ants.inf.um.es/~josesanta






= --Apple-Mail=_6C4FB1E6-5F1C-4947-8CF5-867D918B36DC-- --Apple-Mail=_FF92C8B0-0AAA-404A-8F2A-6BBDA9915154-- From nobody Sun Sep 10 06:55:27 2017 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D70126D0C; Sun, 10 Sep 2017 06:55:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150505172020.8046.11281564472286170442@ietfa.amsl.com> Date: Sun, 10 Sep 2017 06:55:20 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-05.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 13:55:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Alexandre Petrescu Nabil Benamar Jérôme Härri Christian Huitema Jong-Hyouk Lee Thierry Ernst Tony Li Filename : draft-ietf-ipwave-ipv6-over-80211ocb-05.txt Pages : 37 Date : 2017-09-10 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks run outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. In addition, the document lists what is different in 802.11-OCB (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, where IPv6 protocols operate without issues. Most notably, the operation outside the context of a BSS (OCB) has impact on IPv6 handover behaviour and on IPv6 security. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-05 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/ From nobody Sun Sep 10 06:58:30 2017 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 A98081320D9 for ; Sun, 10 Sep 2017 06:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, 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 e5MpI7BCbCBL for ; Sun, 10 Sep 2017 06:58:26 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 A711F126D0C for ; Sun, 10 Sep 2017 06:58:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8ADwNUS145391 for ; Sun, 10 Sep 2017 15:58:23 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A566E2098C6 for ; Sun, 10 Sep 2017 15:58:23 +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 99ED8209892 for ; Sun, 10 Sep 2017 15:58:23 +0200 (CEST) Received: from [132.166.84.15] ([132.166.84.15]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8ADwMLq004381 for ; Sun, 10 Sep 2017 15:58:22 +0200 References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> Message-ID: <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> Date: Sun, 10 Sep 2017 15:58:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------4C683628765100EE65F98BDE" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 13:58:28 -0000 This is a multi-part message in MIME format. --------------4C683628765100EE65F98BDE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear participants to IPWAVE WG, This is the new IPv6-over-802.11-OCB addressing all the Reviewers comments. This is the ChangeLog: o Lengthened the title and cleanded the abstract. o Added text suggesting LLs may be easy to use on OCB, rather than GUAs based on received prefix. o Added the risks of spoofing and hijacking. o Removed the text speculation on adoption of the TSA message. o Clarified that the ND protocol is used. o Clarified what it means "No association needed". o Added some text about how two STAs discover each other. o Added mention of external (OCB) and internal network (stable), in the subnet structure section. o Added phrase explaining that both .11 Data and .11 QoS Data headers are currently being used, and may be used in the future. o Moved the packet capture example into an Appendix Implementation Status. o Suggested moving the reliability requirements appendix out into another document. o Added a IANA Consiserations section, with content, requesting for a new multicast group "all OCB interfaces". o Added new OBU term, improved the RSU term definition, removed the ETTC term, replaced more occurences of 802.11p, 802.11 OCB with 802.11-OCB. o References: * Added an informational reference to ETSI’s IPv6-over- GeoNetworking. * Added more references to IETF and ETSI security protocols. * Updated some references from I-D to RFC, and from old RFC to new RFC numbers. * Added reference to multicast extensions to IPsec architecture RFC. * Added a reference to 2464-bis. * Removed FCC informative references, because not used. o Updated the affiliation of one author. o Reformulation of some phrases for better readability, and correction of typographical errors. Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt Date : Sun, 10 Sep 2017 06:55:20 -0700 De : internet-drafts@ietf.org Pour : Nabil Benamar , Christian Huitema , Jong-Hyouk Lee , Jérôme Härri , Alexandre Petrescu , Tony Li , Alexandre Petrescu , Jerome Haerri , Thierry Ernst , ipwave-chairs@ietf.org A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 05 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Document date: 2017-09-10 Group: ipwave Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-05.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-05 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks run outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. In addition, the document lists what is different in 802.11-OCB (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, where IPv6 protocols operate without issues. Most notably, the operation outside the context of a BSS (OCB) has impact on IPv6 handover behaviour and on IPv6 security. 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 --------------4C683628765100EE65F98BDE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear participants to IPWAVE WG,

This is the new IPv6-over-802.11-OCB addressing all the Reviewers comments.

This is the ChangeLog:

o Lengthened the title and cleanded the abstract.
o Added text suggesting LLs may be easy to use on OCB, rather than
GUAs based on received prefix.
o Added the risks of spoofing and hijacking.
o Removed the text speculation on adoption of the TSA message.
o Clarified that the ND protocol is used.
o Clarified what it means "No association needed".
o Added some text about how two STAs discover each other.
o Added mention of external (OCB) and internal network (stable), in
the subnet structure section.
o Added phrase explaining that both .11 Data and .11 QoS Data
headers are currently being used, and may be used in the future.
o Moved the packet capture example into an Appendix Implementation
Status.
o Suggested moving the reliability requirements appendix out into
another document.
o Added a IANA Consiserations section, with content, requesting for
a new multicast group "all OCB interfaces".
o Added new OBU term, improved the RSU term definition, removed the
ETTC term, replaced more occurences of 802.11p, 802.11 OCB with
802.11-OCB.
o References:
* Added an informational reference to ETSI’s IPv6-over-
GeoNetworking.
* Added more references to IETF and ETSI security protocols.
* Updated some references from I-D to RFC, and from old RFC to
new RFC numbers.
* Added reference to multicast extensions to IPsec architecture
RFC.
* Added a reference to 2464-bis.
* Removed FCC informative references, because not used.
o Updated the affiliation of one author.
o Reformulation of some phrases for better readability, and
correction of typographical errors.

Alex

-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt
Date : Sun, 10 Sep 2017 06:55:20 -0700
De : internet-drafts@ietf.org
Pour : Nabil Benamar <benamar73@gmail.com>, Christian Huitema <huitema@huitema.net>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr>, Jérôme Härri <Jerome.Haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Tony Li <tony.li@tony.li>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Jerome Haerri <jerome.haerri@eurecom.fr>, Thierry Ernst <thierry.ernst@yogoko.fr>, ipwave-chairs@ietf.org 


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

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	05
Title:		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:	2017-09-10
Group:		ipwave
Pages:		37
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-05.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-05
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-05

Abstract:
   In order to transmit IPv6 packets on IEEE 802.11 networks run outside
   the context of a basic service set (OCB, earlier "802.11p") there is
   a need to define a few parameters such as the supported Maximum
   Transmission Unit size on the 802.11-OCB link, the header format
   preceding the IPv6 header, the Type value within it, and others.
   This document describes these parameters for IPv6 and IEEE 802.11-OCB
   networks; it portrays the layering of IPv6 on 802.11-OCB similarly to
   other known 802.11 and Ethernet layers - by using an Ethernet
   Adaptation Layer.

   In addition, the document lists what is different in 802.11-OCB
   (802.11p) links compared to more 'traditional' 802.11a/b/g/n links,
   where IPv6 protocols operate without issues.  Most notably, the
   operation outside the context of a BSS (OCB) has impact on IPv6
   handover behaviour and on IPv6 security.

                                                                                  


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
--------------4C683628765100EE65F98BDE-- From nobody Sun Sep 10 06:59:11 2017 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 EDF15126D0C for ; Sun, 10 Sep 2017 06:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 cYT7vvJ-0TmN for ; Sun, 10 Sep 2017 06:59:07 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 E34041320D9 for ; Sun, 10 Sep 2017 06:59:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8ADx42o011188 for ; Sun, 10 Sep 2017 15:59:04 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 68B2120995D for ; Sun, 10 Sep 2017 15:59:04 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5F012209887 for ; Sun, 10 Sep 2017 15:59:04 +0200 (CEST) Received: from [132.166.84.15] ([132.166.84.15]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8ADx3tj004682 for ; Sun, 10 Sep 2017 15:59:04 +0200 To: its@ietf.org References: <007401d32028$a06b8ce0$e142a6a0$@gmail.com> From: Alexandre Petrescu Message-ID: <534037a7-9be7-925e-cc3f-9f803a2f3c52@gmail.com> Date: Sun, 10 Sep 2017 15:59:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <007401d32028$a06b8ce0$e142a6a0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 13:59:10 -0000 Le 28/08/2017 20:08, Franois Simon a crit: [...] > *[Fygs] Since 2010 the OCB is defined in IEEE Std 802.11p, IEEE Std > 802.11-2012, and IEEE 802.11-2016.* What's the reference to 2016? Can I just go with 'p' and with 2012? Or should I add a 3rd? [...]> RSU: Road Side Unit. A computer equipped with at least one IEEE > 802.11 interface operated in OCB mode. This definition applies to > this document. An RSU may be connected to the Internet, and may be > equipped with additional wired or wireless network interfaces running > IP. An RSU MAY be an IP Router. > > > [Sri] RSU can be compared to an 802.11 access point; Or, WTP as defined > in CAPWAP specification, RFC5415. > > *[Fygs] While I am not familiar with WTP as defined in CAPWAP > specification, RFC5415, I know that an RSU has no commonality with an > 802.11 AP.* Mr. Simon - an RSU does use an 802.11 interface run in OCB mode, and a WiFi Access Point also uses an 802.11 interface, so they do have a comonality. [...]> *[Fygs] Here is a definition of OBU (FCC): An On-Board Unit is a DSRCS > transceiver that is normally mounted in or on a vehicle, or which in > some instances may be a portable unit. An OBU can be operational while a > vehicle or person is either mobile or stationary.* That is why an OBU FCC talks about is different than the OBUs I play with (there are many "transceivers" in OBUs I work with - there are multiple 802.11-OCB transceivers, LTE transceivers, and more, in just one OBU). Some currently call it an "IoT Platform", a "Mobile Router", an "ITS Station", and more other terms. I am not sure we want to converge now. As such I will call it a computer with at least two IP interface, and at least one IP interface running in OCB mode. [...]> [Sri] A packet sent from a vehicles OBU is received by a single RSU, or > multiple RSUs? How does the link-layer resolution happen? > > *[Fygs] Assuming that:* > > *a) ****If t**here are**single or**multiple RSU**s****in the > communication range and it is a**multicast**message**,**the single RSU > or**RSUs in the comm**.**range will receive it (eventually)**.**There is > no resolution at the link layer. But there is resolution at the IP layer: it is the IPv6 Neighbor Discovery protocol. > The RSU**(**s**)**will determine > their****interest** based on**the content of the message at the higher > layers (application);*** YEs too. But the interest is based on the MAC dst address, not the app layer. Apps talk to apps, MAC layers to MAC layers, net layers to net layers. > *b) ****If there are single or multiple RSUs in the communication rand > and it is**unicast message, then the link-layer resolves by > the**destination**MAC address**.* I agree. It uses ND. [...] > The distinction between the two formats is given by the value of the > field "Type/Subtype". The value of the field "Type/Subtype" in the > 802.11 Data header is 0x0020. The value of the field "Type/Subtype" > in the 802.11 QoS header is 0x0028. > The mapping between qos-related fields in the IPv6 header (e.g. > "Traffic Class", "Flow label") and fields in the "802.11 QoS Data > Header" (e.g. "QoS Control") are not specified in this document. > Guidance for a potential mapping is provided in > > > [https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-I-D.ietf-tsvwg-ieee-802-11], > although it is not specific to OCB > > mode. > > > > [Sri] The applicability of the QoS mapping draft to 802.11-OCB needs > further investigation, IMO. > > ***[Fygs] I am not familiar with QoS control of IPv6****. As for the > OCB MAC QoS it is somewhat involved.****It is based > on********transmission priority****of MAC frames. A higher priority > frame is intended to be transmitted ahead of lower priority > frames.****If a detail process is required, please, let me know and I > would provide the text.***** The QoS mapping needs to be worked on a separate document that should answer this: which MAC QoS field is mapped into which IPv6 header field. On this list a few participants expressed interest in the QoS work. IP QoS is a key solution to the distinctive safety-entertainment needs in vehicular communications. Alex From nobody Sun Sep 10 06:59:46 2017 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 7E3EE1320D9 for ; Sun, 10 Sep 2017 06:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 wiVG_kF59i2g for ; Sun, 10 Sep 2017 06:59:41 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 78FAD126D0C for ; Sun, 10 Sep 2017 06:59:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8ADxb0k145755; Sun, 10 Sep 2017 15:59:37 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2261220995D; Sun, 10 Sep 2017 15:59:37 +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 14C9B209887; Sun, 10 Sep 2017 15:59:37 +0200 (CEST) Received: from [132.166.84.15] ([132.166.84.15]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8ADxaCY004850; Sun, 10 Sep 2017 15:59:36 +0200 To: "Sri Gundavelli (sgundave)" References: From: Alexandre Petrescu Cc: "its@ietf.org" Message-ID: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> Date: Sun, 10 Sep 2017 15:59:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 13:59:44 -0000 Sri, Thanks for the review. Le 27/08/2017 16:44, Sri Gundavelli (sgundave) a crit : [...] > 1.) Its not clear, if the document makes any assumption on the > operating environment/communication profile. There is not much > discussion on that aspect; For example, Is it always a one-hop > communication between RSU and OBU where the 802.11-OCB link? So, is > the use of IPv6 only in that context of 1-hop communication? The question is very relevant, but not place in this document to go to much extent about it in an IP-over-foo document. To answer now: is that 1 OCB hop is right at this time. > 2.) There is also no discussion on how these links get formed in > vehicular environment and when they are attached/detached. As above. > 3.) How do nodes discover each other? How does ND resolution work? > Are these messages received by a multiple RSUs, or a single RSU? > Whats the implication of that. Note that you dont have that issue in > 802.11, given the association to an access point, which in turn maps > the links to a VLAN/subnet. I think ND may answer to some of the questions. > > 4.) What happens as a vehicle moves between RSUs, how does it impact > address configuration? Mobile IP, but not in this document. > Is DHCPv6 based address configuration relevant here? YEs, but not to describe the detail use of DHCPv6-over-foo on IP-over-foo. If you want to just refer to DHCP, that would be at which place in this document? [...] > We briefly introduce the vehicular communication scenarios where > IEEE 802.11-OCB links are used. > > > [Sri] I have not seen much discussion on the link / communication > assumptions. That's why it says 'briefly'. [...] > The IEEE 802.11 OCB Networks are used for vehicular communications, > as 'Wireless Access in Vehicular Environments'. The IP > communication scenarios for these environments have been described in > several documents, among which we refer the reader to one recently > updated [I-D.petrescu-its-scenarios-reqs > ], > about scenarios and requirements for IP in Intelligent Transportation > Systems. > > > [Sri] You can do bit more justice to this section. > > Explain the link model. STA ----802.11-OCBSTA. Then talk about > the applicability in Vehicular networks, with STA's as RSU and OCB. > > You may also want to talk about, how links get formed/terminated; how > nodes peer/discover and how mobility works ..etc. While 802.11-OCB > is clearly specified and the use of IPv6 over such link is also not > radically new, but the operating environment which is vehicular > brings many new things. That description is not present any where. I mentioned it but the details are out of scope for an IPv6 over foo document. [...] > [Sri] I am really not sure how link throughput (12Mbps) relates to > "IPv6 support on OCB links". 802.11-OCB max 12mbit/s means one _can_ run a wide range of applications on it. Other links are so small and rare that you can not run IPv6 on them, must change IPv6. (LORA, 15.4, etc). > o Operation Outside the Context of a BSS (OCB): the (earlier > 802.11p) 802.11-OCB links are operated without a Basic Service Set > (BSS). This means that the frames IEEE 802.11 Beacon, Association > Request/Response, Authentication Request/Response, and similar, are > not used. The used identifier of BSS (BSSID) has a hexadecimal value > always 0xffffffffffff (48 '1' bits, represented as MAC address > ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard' BSSID), as opposed to > an arbitrary BSSID value set by administrator (e.g. > 'My-Home-AccessPoint'). The OCB operation - namely the lack of > beacon-based scanning and lack of authentication - has a potentially > strong impact on the use of the Mobile IPv6 protocol [RFC6275 > ] and on the protocols for IP > layer security [RFC4301 ]. > > > [Sri] The document till now has been arguing heavily on how IPv6 > operates so naturally on these links and now I see discussion on > Impact to a high-level protocol such as MIPv6. You may want to fix > the earlier text. I removed 'impact' word. But also, the way MIP adapts to OCB is outside the scope of this document. > In any case, the absence of link-layer security practically impacts > every application, not just MIPv6. Also, MIPv6 does not make any > assumptions on the link-layer security. Also, the the > 0xFF-FF-FF-FF-FF-FF as the BSSID, makes the messages readable by all > other RSUs in proximity. I think the discussion on the nature of > the link, who all sees the messages.. how L2 addresses are resolved > is not explained clearly. I added some text about ND and some in the security section about how this is open. [...] > Other aspects particular to 802.11-OCB which are also particular to > 802.11 (e.g. the 'hidden node' operation) may have an influence on > the use of transmission of IPv6 packets on 802.11-OCB networks.*The > subnet structure which may be assumed in 802.11-OCB networks is > strongly influenced by the mobility of vehicles.* > > > [Sri] Per my earlier comment, the link model, addressing ..etc needs > to be explained in more detail. It is not clear what exactly the > subnet structure that is assumed in 802.11-OCB. Improved the subnet structure section. [...]> The Equivalent Transmit Time on Channel is a concept that may be used > as an alternative to the MTU concept. A rate of transmission may be > specified as well. The ETTC, rate and MTU may be in direct > relationship. > > [Sri] The last paragraph needs some additional context. Did > 802.11-OCB introduce ETTC concept? We heard this term at mic in Berlin BoF. Sounded like a more universal term. Should we remove it? [...] > The mapping between qos-related fields in the IPv6 header (e.g. > "Traffic Class", "Flow label") and fields in the "802.11 QoS Data > Header" (e.g. "QoS Control") are not specified in this document. > Guidance for a potential mapping is provided in > [I-D.ietf-tsvwg-ieee-802-11 > ], > although it is not specific to OCB mode. > > > > [Sri] The applicability of the QoS mapping draft to 802.11-OCB needs > further investigation, IMO. YEs, it is out of scope in this document. > 5.3 > . > > Link-Local Addresses > > > > The link-local address of an 802.11-OCB interface is formed in the > same manner as on an Ethernet interface. This manner is described > in section 5 of [RFC2464] > . > > > > [Sri] Does this go against the 8064 recommendation on Interface > identifier generation? YEs. > May be RFC7217 for interface identifier generation in conjunction > with the link-local address generation per RFC2464 YEs. But I think it's up to rfc2464-bis to say that, and this IPv6-over-OCB to just refer to rfc2464-bis. [...] > For unicast as for multicast, there is no change from the unicast > and multicast address mapping format of Ethernet interfaces, as > defined by sections6 > > and7 > > of [RFC2464 ]. > > > > [Sri] RFC6085 specified mapping is also relevant; If the > communication peers are aware that there is only one peer, it should > apply 6085 specified mapping. That mode is relevant for 802.11-OCB > types links as well. Same here, would be great to get 6085 into 2464-bis, at which point this ip-over-ocb inherits from 2464-bis. I added a reference to 2464-bis. > 5.4.1 > . > > Address Mapping -- Unicast > > > > The procedure for mapping IPv6 unicast addresses into Ethernet link- > layer addresses is described in [RFC4861 > ]. The Source/Target Link- > layer Address option has the following form when the link-layer is > Ethernet. > > [Sri] I thought, mapping of IPv6 unicast addresses to Ethernet > link-layer addresses is specified in section 6, of RFC2464 and not in > RFC4861. Either we have a brief paragraph that just refers to 2464 section 6, or copy paste that section from 2464 and update its [DISC] reference to 4861. That I did, in order to have the text a bit longer. At this time I keep it that way, unless someone opposes. A key question here is how is 2464bis advancing, and how we coordinate with it. [...] > An IPv6 packet with a multicast destination address DST, consisting > of the sixteen octets DST[1] through DST[16], is transmitted to the > IEEE 802.11-OCB MAC multicast address whose first two octets are the > value 0x3333 and whose last four octets are the last four octets of > DST. > > [Sri] Please add a reference to Section 7, RFC4861 and also RFC6085. > In general, for both unicast and multicast, you may want to clearly > say that this is per the existing specs and duplicated here for > convenience. Should _this_ document do it, or should the 2464bis do it? At this time I keep it that way. [...] > The Interface Identifier for an 802.11-OCB interface is formed using > the same rules as the Interface Identifier for an Ethernet > interface; this is described insection 4 of [RFC2464] > . No changes are > needed, but some care must be taken when considering the use of the > SLAAC procedure. > > > > [Sri] Per my earlier comment, please refer to the current > recommendation on interface-identifier generation and its use in > link-local, global or other addresses. Per my comments above - what do you think about 2464bis doing your recommendations, rather than this one. Depending on that, we can see further with this document. [...] > The 802.11 networks in OCB mode may be considered as 'ad-hoc' > networks. The addressing model for such networks is described in > [RFC5889 ].o > > > [Sri] Per my earlier comment, there is no system level view of the > network where 802.11-OCB links are used. So, in the absence of such > discussion So, I am not sure what part of RFC5889 is applicable here. > That's the only RFC the IETF has about the subnet structure in 'ad-hoc' networks, and the 'ad-hoc' is what OCB is like. > For example, link-local addresses may just work fine. Yes, added. [...] > Overall, the captured message is identical with a capture of an IPv6 > packet emitted on a 802.11b interface. The contents are precisely > similar. > > > [Sri] I suggest moving this discussion under the section > Implementation Status, Agreed. > which will eventually be removed from the RFC. But at the same time it depicts this topology of Router-connected-to-Host, using 802.11-OCB. This is something that you requested earlier with STA1----STA2 with OCB in the middle. So I suggest to keep this section in Appendix. > There is nothing new here. This are details on experimentation. But, > if you think there is some useful information such as discussion on > Capture mode ..etc, you may want to move this entire section to > Appendix. Implementors may use these tools for verification. Yes. [...] > . > IANA Considerations > > > > [Sri] I though there was one IANA request on some multicast related? added Alex From nobody Sun Sep 10 07:00:37 2017 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 7E74D1320D9 for ; Sun, 10 Sep 2017 07:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 QmUy48kCwICP for ; Sun, 10 Sep 2017 07:00:33 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 842DF126D0C for ; Sun, 10 Sep 2017 07:00:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8AE0Vx2015130 for ; Sun, 10 Sep 2017 16:00:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BF92F20995D for ; Sun, 10 Sep 2017 16:00:31 +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 B69EB2098C6 for ; Sun, 10 Sep 2017 16:00:31 +0200 (CEST) Received: from [132.166.84.15] ([132.166.84.15]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8AE0UMn005358 for ; Sun, 10 Sep 2017 16:00:31 +0200 From: Alexandre Petrescu To: its@ietf.org References: <150307081500.14196.2111291351079489748@ietfa.amsl.com> <6f4dfdfc-e092-f610-40d6-58ddcff00299@ing.uchile.cl> Message-ID: <74e2bc40-6c9e-5034-1425-45e38f877efb@gmail.com> Date: Sun, 10 Sep 2017 16:00:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <6f4dfdfc-e092-f610-40d6-58ddcff00299@ing.uchile.cl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 14:00:35 -0000 Le 21/08/2017 à 17:14, Sandra Céspedes U. a écrit : [...] > 3. In page 4, there seems to be a contradiction. In the first > paragraph is mentioned that "while there is no encryption applied > below the network layer using 802.11p, 1609.2 [ieee1609.2] does > provide security services for applications to use so that there can > easily be data security over the air without invoking IPsec." > However, in the fifth paragraph is mentioned that "the IP security > mechanisms are necessary, since OCB means that 802.11 is stripped of > all 802.11 link-layer security;". I understood that IPSec wasn't > necessary but the last phrase seems to say the opposite. Am I wrong? No. I removed "so that there can easily be data security over the air without invoking IPsec". > 5. In page 7, suggest to change "This band is "5.9GHz" which is > different from the bands "2.4GHz" or "5GHz" used by Wireless LAN" to > "The 5.9GHz band is different from the 2.4GHz and 5GHz bands used by > Wireless LAN". Done. > Same suggestion to other appearances in the same paragraph. I dont see where. > 6. In page 7 you mention " In the list below, the only 802.11 OCB > fundamental points which influence IPv6 are the OCB operation and the > 12Mbit/s maximum which may be afforded by the IPv6 applications." I > found the description for OCB operation but none for the 12Mbit/s > maximum (not sure if you are referring to a maximum data rate? I > thought it was actually 27 Mbps), so it is not clear how the second > "fundamental point" influences the operation of IPv6. I reformulated. > 7. In Appendix C.1, perhaps it should be mentioned that relaying on > an identifier obtained from the MAC address might not be possible > not only in the presence of multiple 802.11-OCB NICs, but also if > there is randomization of MAC addresses. But if there is randomisation of the MAC address (a single MAC address), it is still possible to identify one vehicle by that MAC address, even if it is a number that is randomised. I suppose it is randomised only once in a lifetime, not every time the machine boots. I suppose it is randomised such that an privacy attacker is prevented from correlating the OUI of a MAC address to the true organisation (obfuscation). Or maybe you assumed frequent MAC randomisation. In that case, I reformulated. > 8. Appendix C.2 defines several MUSTs for authentication, time > synchronization, etc. Why is this defined as an appendix and not in > the main document? It looks like these requirements should be outside the document altogether. Thank you. Alex From nobody Sun Sep 10 07:00:57 2017 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 25E3A132403 for ; Sun, 10 Sep 2017 07:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 bXW9mRcPL7tS for ; Sun, 10 Sep 2017 07:00:52 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 9DA05126D0C for ; Sun, 10 Sep 2017 07:00:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8AE0pLV011395 for ; Sun, 10 Sep 2017 16:00:51 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 03D1B2099BF for ; Sun, 10 Sep 2017 16:00:51 +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 E860320992E for ; Sun, 10 Sep 2017 16:00:50 +0200 (CEST) Received: from [132.166.84.15] ([132.166.84.15]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8AE0mGp005412 for ; Sun, 10 Sep 2017 16:00:50 +0200 From: Alexandre PETRESCU To: its@ietf.org References: <58D01021-E27E-44AC-BCDD-31800CDE38E4@um.es> Organization: CEA Message-ID: <116eeef6-83fb-0f5d-94ae-1ec58bcafada@cea.fr> Date: Sun, 10 Sep 2017 16:00:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <58D01021-E27E-44AC-BCDD-31800CDE38E4@um.es> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030505010004080103050607" Archived-At: Subject: Re: [ipwave] Comments on draft-ietf-ipwave-ipv6-over-80211ocb-04 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 14:00:55 -0000 This is a cryptographically signed message in MIME format. --------------ms030505010004080103050607 Content-Type: multipart/alternative; boundary="------------936963D0C4E27C76753B1D99" Content-Language: fr This is a multi-part message in MIME format. --------------936963D0C4E27C76753B1D99 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jos=C3=A9, The comments helped improve the document. You raise a question that I answer here. Draft says: > At the time of writing, the prohibition is explicit at higher > layer protocols providing services to the application; these > higher layer protocols are specified in IEEE 1609 documents. Jos=C3=A9 said: > Do you refer here to he WAVE stack, or this statement is also true for = > the European case? Yes, the text refers to WAVE stack because it says IEEE 1609. For the European case: I heard people saying IPv6 is forbidden on the=20 control channel.=C2=A0 But I could not find a standardised agreed reference to that. Countries=20 restrict the control channel to "safety" use, yet countries dont talk about forbidding IPv6 explicitely.=C2=A0 This can= =20 easily let think that in Europe IPv6-used-as-safety is not forbidden on the control channel. In Europe, some people say that IPv6 _is_ allowed on the CCH, _if_ it=20 runs on GeoNetworking.=C2=A0 But the country frequency regulators dont talk about GeoNetworking at all. In America IEEE 1609 they say explicitly IPv6 forbidden on control=20 channel.=C2=A0 But the FCC doesnt say so. Add to that: the control channel value in terms of mega Hertz in America = is different than in Europe. The channel considered as CCH in America falls in an SCH in Europe=20 (service channel).=C2=A0 In that sense one could say that where IPv6 is forbidden in America, is explicitely=20 permitted in Europe. This makes little sense.=C2=A0 Ideally, there would be one control channe= l=20 number in terms of mega Hertz both in America and in Europe _and_ IPv6 would not be forbidden there.=C2= =A0=20 But still restrict the use of that channel to more like "safety".=C2=A0 That "safety" could easi= ly=20 be implemented in IPv6: it's a Traffic Class, or a Flow Label, and in 802.11 it's also a "Traffic=20 Something". Because of this doubt, I prefer to keep the text as is, and just add=20 "WAVE stack". Draft says: > Other aspects particular to 802.11-OCB which are also particular to > 802.11 (e.g. the =E2=80=99hidden node=E2=80=99 operation) may have an i= nfluence on > the use of transmission of IPv6 packets on 802.11-OCB networks. The > subnet structure which may be assumed in 802.11-OCB networks is > strongly influenced by the mobility of vehicles. Jos=C3=A9 says: > ... but, for this reason there exist solutions like=C2=A0 NEMO, isn't i= t? I=20 > am not sure if you refer here to the posibility of an in-vehicle=20 > network movement. I reformulated to mean the car-external subnet.=C2=A0 The NEMO protocols = deals with the in-vehicle stable network. Mobile IPv6 and its handover management mechanism deal with such varying = subnet structure, but only when there is an RSU.=C2=A0 In this document we dont deal with handover, nor Mobile = IPv6, nor NEMO - it's other documents. Draft says: > There are considerations for 2 or more IEEE 802.11-OCB interface > cards per vehicle. Jos=C3=A9 says: > or a transceiver supporting more than one channnel to be used=20 > simultaneously. There are no 802.11-OCB transceivers that can use more than one channel=20 simultaneously.=C2=A0 So I dont include that text. Yours, -- Alexandre Petrescu alexandre.petrescu@cea.fr, t=C3=A9l 0169089223 Le 07/09/2017 =C3=A0 17:20, Jos=C3=A9 Santa Lozano a =C3=A9crit=C2=A0: > Dear all, > > Please, find attached a list of comments and suggestions embedded in a = > PDF document of the draft, with the aim of make easier their following.= > > Expecting that they result of interest and help. > > Regards, > > > --=20 > Jos=C3=A9 Santa Lozano > Department of Information and Communication Engineering > Faculty of Computer Science > University of Murcia > 30100 Murcia, Spain > Phone: +34-868-884616 /=C2=A0+34-868-884455 > Fax: +34-868-884151 > Web: http://ants.inf.um.es/~josesanta > > > > > > --------------936963D0C4E27C76753B1D99 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Jos=C3=A9,<= /font>

The comments helped improve the document.

You raise a question that I answer here.

Draft says:

At the time of writing, the prohibition= is explicit at higher
layer protocols providing services to the application; these higher layer protocols are specified in IEEE 1609 documents.
Jos=C3=A9 said:
Do you refer here to he WAVE stack, or this statement is also true for the European case?
=
Yes, the text refers to WAVE stack because it says IEEE 1609.
=
For the European case: I heard people saying IPv6 is forbidden on the control channel.=C2=A0 But
I could not find a standardised agreed reference to that.=C2=A0 Countries restrict the control channel to "safety" use,
yet countries dont talk about forbidding IPv6 explicitely.=C2=A0 = This can easily let think that in Europe
IPv6-used-as-safety is not forbidden on the control channel.

In Europe, some people say that IPv6 _is_ allowed on the CCH, _if_ it runs on GeoNetworking.=C2=A0 But
the country frequency regulators dont talk about GeoNetworking at all.

In America IEEE 1609 they say explicitly IPv6 forbidden on control channel.=C2=A0 But the FCC doesnt say so.

Add to that: the control channel value in terms of mega Hertz in America is different than in Europe.
The channel considered as CCH in America falls in an SCH in Europe (service channel).=C2=A0 In that sense
one could say that where IPv6 is forbidden in America, is explicitely permitted in Europe.

This makes little sense.=C2=A0 Ideally, there would be one contro= l channel number in terms of mega Hertz
both in America and in Europe _and_ IPv6 would not be forbidden there.=C2=A0 But still restrict the
use of that channel to more like "safety".=C2=A0 That "safety" co= uld easily be implemented in IPv6: it's
a Traffic Class, or a Flow Label, and in 802.11 it's also a "Traffic Something".

Because of this doubt, I prefer to keep the text as is, and just add "WAVE stack".

Draft says:
Other aspects particular to 802.11-OCB which are also particular to
802.11 (e.g. the =E2=80=99hidden node=E2=80=99 operation) may h= ave an influence on
the use of transmission of IPv6 packets on 802.11-OCB networks. The
subnet structure which may be assumed in 802.11-OCB networks is
strongly influenced by the mobility of vehicles.

Jos=C3=A9 says:
... but, for this reason there exist solutions like=C2=A0 NEMO, isn't it? I am not sure if you refer= here to the posibility of an in-vehicle network movement.

I reformulated to mean the car-external subnet.=C2=A0 The NEMO protocols deals with the in-vehicle stable network.
Mobile IPv6 and its handover management mechanism deal with such varying subnet structure, but only when there
is an RSU.=C2=A0 In this document we dont deal with handover, nor= Mobile IPv6, nor NEMO - it's other documents.

Draft says:
There are considerations for 2 or more IEEE 802.11-OCB interface
cards per vehicle.

Jos=C3=A9 says:
or a transceiver supporting more than one channnel to be used simultaneously.

There are no 802.11-OCB transceivers that can use more than one channel simultaneously.=C2=A0 So I dont include that text.

Yours,<= br> 

--
Alexandre Petrescu
alexandre.petrescu@cea.fr, t=C3=A9l 0169089223
Le 07/09/2017 =C3=A0 17:20, Jos=C3=A9 = Santa Lozano a =C3=A9crit=C2=A0:
Dear all,

Please, find attached a list of comments and suggestions embedded in a PDF document of the draft, with the aim of make easier their following.

Expecting that they result of interest and help.<= /div>

Regards,


=
--=C2= =A0
Jos=C3= =A9 Santa Lozano
= Department of Information and Communication Engineering
Facul= ty of Computer Science
Unive= rsity of Murcia
30100= Murcia, Spain
Phone= : +34-868-884616 /=C2=A0+34-868-884455
Fax: +34-868-884151
Web:=C2= =A0http://ants= =2Einf.um.es/~josesanta







--------------936963D0C4E27C76753B1D99-- --------------ms030505010004080103050607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Signature cryptographique S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC C6QwggWgMIIEiKADAgECAgI5MDANBgkqhkiG9w0BAQUFADBjMQswCQYDVQQGEwJGUjEMMAoG A1UECgwDQ0VBMRcwFQYDVQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwCQUMxIDAeBgNV BAMMF0NFQSBBQyBVdGlsaXNhdGV1ciAyMDIxMB4XDTE1MDExNTEzNDI1MFoXDTE4MDExNTEz NDI1MFowVTELMAkGA1UEBhMCRlIxDDAKBgNVBAoMA2NlYTEUMBIGA1UECwwLVXRpbGlzYXRl dXIxIjAgBgNVBAMMGVBFVFJFU0NVIEFsZXhhbmRyZSAyMjIwNDAwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDAmIx5QVYSXlLNLE/D9SySZPKHBBP0G9NgtMYKQuYWODXAkmI8 b4xp1YniPStCcyPauXfVn+ySgAr4SX/oWwB2kTPISYWt8FQ7eNdXH7AM7cPbLQh0IYwHUWAf 6Mzakx+/oajWhYv8NvLhVnb7qjGmWObdLUcOgJOSYAzHSVPQRnRB9A9Fw7NzNMi/9wqGwmJz maBhaDL/iMRZEDnllsnGFHZr1h6N8srFER7nEJVS/CDTIlZwBFO6DXScy1mq8ZzcD3hNIOV1 2PmhiW7dPfeE7BDjvDS+Fb0PQB7R4TCQo4J7+Nm4Cca+U4cloclzpznWJZWD1AZw8CdwXqNM /tYXAgMBAAGjggJqMIICZjAdBgNVHQ4EFgQUonHmXxWzWW2Z52J+svVY7gn56jUwHwYDVR0j BBgwFoAU+4DifDNZ7hKDQxL+ys+vHYZdUJgwgcgGA1UdIASBwDCBvTCBugYKKwYBBAHgYAEG AjCBqzAlBggrBgEFBQcCARYZaHR0cDovL3d3dy1pZ2MuY2VhLmZyL3BjLzCBgQYIKwYBBQUH AgIwdTANFgNDRUEwBgIBAgIBABpkVm91cyBkZXZleiBhY2NlcHRlciBsYSBwb2xpdGlxdWUg ZGUgY2VydGlmaWNhdGlvbiBhdmFudCBkJ3V0aWxpc2VyIGNlIGNlcnRpZmljYXQsIGNmLiB3 d3ctaWdjLmNlYS5mcjARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgSwMCQGA1Ud EQQdMBuBGWFsZXhhbmRyZS5wZXRyZXNjdUBjZWEuZnIwTQYDVR0fBEYwRDBCoECgPoY8aHR0 cDovL2NybC1hYy11dGlsaXNhdGV1ci5jZWEuZnIvY3JsL2FjLXV0aWxpc2F0ZXVyLTIwMjEu Y3JsMHMGCWCGSAGG+EIBDQRmFmRWb3VzIGRldmV6IGFjY2VwdGVyIGxhIHBvbGl0aXF1ZSBk ZSBjZXJ0aWZpY2F0aW9uIGF2YW50IGQndXRpbGlzZXIgY2UgY2VydGlmaWNhdCwgY2YuIHd3 dy1pZ2MuY2VhLmZyMEwGCCsGAQUFBwEBBEAwPjA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy1p Z2MuY2VhLmZyL2FjL2FjLXV0aWxpc2F0ZXVyLTIwMjEuY2VyMA0GCSqGSIb3DQEBBQUAA4IB AQB+wFDqbtylGRYrv0BVuBjf9ZHHixvEVOz1SMyR+9671bbqPylE3xAEENJ9Obz+wI/hTsrL R0R+UQuMutmU4N2y84YbdWirtCneyiLrS4aG8OkOl0cKdQubj+ptcXHWl0WWdB9urwYjBaZ4 A9Z+/VqJQBz1B3ci1u5Kz4P1HpfILJnjxaAdEvt6xepyshPCms8jEcEKz4OggYAQFKzJoIZx QPB2yBRc8aJZW+Vqb/W5i7Ow+2oaUTw2RQ7Iv84AvBMyqSFFU//tsgTED4QmIL3+bWcqrG4q rkFNeuDnQr5neJ2sR3s2kPSCZYn2d1W6BjQ67flz/V6jBEgkshD0TttRMIIF/DCCA+SgAwIB AgIBAjANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJGUjEMMAoGA1UECgwDQ0VBMRcwFQYD VQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwCQUMxGzAZBgNVBAMMEkNFQSBBQyBSYWNp bmUgMjA0MTAeFw0xMTExMjgxMzU0MzVaFw0yMTEyMDExMzU0MzVaMGMxCzAJBgNVBAYTAkZS MQwwCgYDVQQKDANDRUExFzAVBgNVBAsMDjAwMDIgNzc1Njg1MDE5MQswCQYDVQQLDAJBQzEg MB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMjEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCc/G4Oogc3nYQybY/irx22kJi+TuA6EqkXjtNRcPYfRi619L7ikuZNsVfa fBWp/1KQD6VdW4cBzNYghKyrUkdPRhGQ0xLNQhTyVFn3QuJIjyWEpl9IESc2ctzme6NIF4lG axXvlwve+UCt9v4Xuk1pUcSAt2AJ9PdTNNinJQBNprOTh6Twq30i4YcTxH99X94AWfiYZRvm /tFE38oK6fD7y8S6/xW90QuCmMHpTUtmKt8l7t6PAwNTx8uFayGFCCfeMAbLIcaXvKZzuBpA XpKXr7zvGTu/OsdNKNyzxvF7kon/2kDA4dxXAp/MTDIjaARBFjVVfs+/esdROUsLTqUDAgMB AAGjggG+MIIBujAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT7gOJ8M1nuEoNDEv7Kz68d hl1QmDAfBgNVHSMEGDAWgBSgEYn4mr+mhLEpBzdTQe2XlUJ7HTCByAYDVR0gBIHAMIG9MIG6 BgorBgEEAeBgAQYCMIGrMCUGCCsGAQUFBwIBFhlodHRwOi8vd3d3LWlnYy5jZWEuZnIvcGMv MIGBBggrBgEFBQcCAjB1MA0WA0NFQTAGAgECAgEAGmRWb3VzIGRldmV6IGFjY2VwdGVyIGxh IHBvbGl0aXF1ZSBkZSBjZXJ0aWZpY2F0aW9uIGF2YW50IGQndXRpbGlzZXIgY2UgY2VydGlm aWNhdCwgY2YuIHd3dy1pZ2MuY2VhLmZyMA4GA1UdDwEB/wQEAwIBBjBDBgNVHR8EPDA6MDig NqA0hjJodHRwOi8vY3JsLWFjLXJhY2luZS5jZWEuZnIvY3JsL2FjLXJhY2luZS0yMDQxLmNy bDBHBggrBgEFBQcBAQQ7MDkwNwYIKwYBBQUHMAKGK2h0dHA6Ly93d3ctaWdjLmNlYS5mci9h Yy9hYy1yYWNpbmUtMjA0MS5jZXIwDQYJKoZIhvcNAQEFBQADggIBAMCbWqmZRh1h4klw5m6b t2okNIorESBuwWQ3woAdLb9PsVUW70mLwwzvmf/++lphdYn6cWVHxXNn707DPz6XG/IsRfBA UWTshe0QmrGx5xpVvpbrU9gQVWGwLugF6rYgZ9B7ELOxQp/Ac03nheADYevePfbZ/2lbIJGt sn7/8lF5JKENkhvAb2+bXZZsyvy59W8xc2QsDUddemHKz9ZtggGeToG0LDT78SkSPbE3RwP+ Q0VXt7QYo8vhmV43mp+UrZeI4JUQibWXvIOp6avOf1zfpbm9RhLa501puoKaVaeHkcxi46je Bv4znpwQEi5I9yS6Hekivh9hofq52lIQJ+UNe2+QYGAzJmuI62Buto1iwWmBm8Qe+uIpZnRU /O/tFgw2Gm2fbDdtT1tbaZdJgbI40D4DpUGBbf1kkbn1G5i0bkDUZfUk18w1aa5d4sSC1tLU xAZqhKe1iA7iLeweZhqLzmylFCL5BlJrVh+PNXwUYhOOLkiE7/uC/ncog+K5J2HnzZfX2Ejh haeBCTxeQBvmm/omrzWerid6FLG/jlBjqkpoALNucTRfDB6YmspYqOY8sU8yiLKt/v6xpxb4 AI3FEheIzTz/bgCNNbQv3Be1TpdKI8cc40HG72jK/s7sbbKMf1SRtTxDZGGmarjaWtxWo6S9 uFc2ZX4lyqYbNnh3MYIDZTCCA2ECAQEwaTBjMQswCQYDVQQGEwJGUjEMMAoGA1UECgwDQ0VB MRcwFQYDVQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwCQUMxIDAeBgNVBAMMF0NFQSBB QyBVdGlsaXNhdGV1ciAyMDIxAgI5MDANBglghkgBZQMEAgEFAKCCAc0wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTEwMTQwMDQ4WjAvBgkqhkiG9w0B CQQxIgQgwvIfxDeGq/aRWsnFnnsYT0nRjxJTMfyrGYxUl2DnqvgwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQx azBpMGMxCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExFzAVBgNVBAsMDjAwMDIgNzc1Njg1 MDE5MQswCQYDVQQLDAJBQzEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMjECAjkw MHoGCyqGSIb3DQEJEAILMWugaTBjMQswCQYDVQQGEwJGUjEMMAoGA1UECgwDQ0VBMRcwFQYD VQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwCQUMxIDAeBgNVBAMMF0NFQSBBQyBVdGls aXNhdGV1ciAyMDIxAgI5MDANBgkqhkiG9w0BAQEFAASCAQBR+AEdF4ggzq9Yom57vgbOhAa3 dvoMSHuheNZ/fUdeTM42h6vMtxlkFAaZ0mRYi54OZZ5fYDUPKiaqFRGkd3z2Dm0PK/dVVe/o 4wuYUq8OHEINlA3jkSF0OADvvwRLA5zkZVMgiD5wCMSr1ekRgXuZaOh9Bo+YUvph3mRKmx94 aS7kJ/6ERcjIvEyTtKnR1UdKgmo2F7ESbDDDN6snSaK3TG8lHtSF10sopmMixVflkYzjIn0Y odXXKvwfPWBadZax0b768UFhD1Z6719kf5n7hmyyqLWPJXqsjiAmmnKYf2Q3dBp77fvMG//6 uohyk0+EbYCDuJvY2K3kFE8gwd1UAAAAAAAA --------------ms030505010004080103050607-- From nobody Sun Sep 10 07:02:06 2017 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 985B91320D9 for ; Sun, 10 Sep 2017 07:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 HejNfnAQ75Rs for ; Sun, 10 Sep 2017 07:02:03 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 272AF126D0C for ; Sun, 10 Sep 2017 07:02:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8AE21sU011650 for ; Sun, 10 Sep 2017 16:02:01 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 85E412099BF for ; Sun, 10 Sep 2017 16:02:01 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7CC22209887 for ; Sun, 10 Sep 2017 16:02:01 +0200 (CEST) Received: from [132.166.84.15] ([132.166.84.15]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8AE20AY006027 for ; Sun, 10 Sep 2017 16:02:01 +0200 From: Alexandre Petrescu To: its@ietf.org References: Message-ID: <14426e66-eb83-ae31-8496-2772b1053d4e@gmail.com> Date: Sun, 10 Sep 2017 16:02:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 14:02:05 -0000 Le 28/08/2017 17:23, Sri Gundavelli (sgundave) a crit: > Agree! > > If we look at this work as strictly about transmitting an IPv6 on > particular type of link, then its just about defining the mapping of > IPv6 address to link-layer addresses, and about details on L2 header > construction ..etc; more along the lines of RFC2464 / 6085 ..etc. We > dont talk about the operating environment, ND, security, routing ..we > only present the relation between L2 and L3 header fields and stay > silent on all other aspects. > > But, the issue is when we bring the system level aspects, then we may > have to state the assumptions as the considerations change based on > those assumptions. For example, if the operating environment is about > dynamically moving IPv6 nodes (connected over 802.11-OCB links), which > come into proximity for a transient period of time, then we dont know > which prefix is routable from which 802.11-OCB peer. How does routing/ND > work? This is more a MANET problem. Similarly, for other operating > environments, there may be different set of security, ND, routing and > other considerations. > > The document has to state those assumptions and then present the solution. Some of this is more of MANET space. We do refer now about ND and security (SeND). There is now a better subnet structure section. The question of the prefix: we may need to define elsewhere what's a prefix in a car, and how to exchange them to have routing work. Also, it may be that what you are asking is really outside the scope of an IPv6-over-foo document. RFC2464 IPv6-over-Ethernet does not talk about when it's used in a datacenter or in an IoT camera. But I keep the comment. Alex From nobody Sun Sep 10 20:58:38 2017 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 6EFD113295C for ; Sun, 10 Sep 2017 20:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 3hsIPA2AGCeX for ; Sun, 10 Sep 2017 20:58:34 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7341241FC for ; Sun, 10 Sep 2017 20:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22756; q=dns/txt; s=iport; t=1505102314; x=1506311914; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Cn/7NACo4GwX0IhkQh+VYeqYTS1NJ2dSbuq0cZP5Hn4=; b=eiFSA4Dkxh6fFCM1DfFx+bnMamof//p1XEfXKNqSSmRJPp49X6Ih72kp gyLKgvb2gCbyfa+d4SumsKlLeEHl5XYM8P2hNKB4S8T58D5fF1Poca8Ko te1y7UKdgNmuvGCpC6hFOPQLmNctKF355VKO+JZLsX+QqlKZ6ZBfiBVPT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BpAgAXCbZZ/49dJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy0tZG4nB4MtQ50qh0ONfYIECiWFGQIag3FXAQIBAQEBAQJrKIU?= =?us-ascii?q?ZBgwXET4HEAIBBgIaAiYCAgIfERUQAgQOBYoZAxUQj0WdZoInhysNg3wBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYEOgh2CAoFQgWIBgnM1gliBYyQCFheCfIJhBZg?= =?us-ascii?q?dF4gEPAKHWYNahCaEdoIThWeFKIVPiXyCV4grAhEZAYE4AVeBDXcVhV0FHIFnd?= =?us-ascii?q?ogogQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.42,375,1500940800"; d="scan'208";a="1596665" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2017 03:58:33 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v8B3wWVw001585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Sep 2017 03:58:32 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 10 Sep 2017 22:58:32 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Sun, 10 Sep 2017 22:58:32 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandre Petrescu CC: "its@ietf.org" Thread-Topic: Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt Thread-Index: AQHTKpXkKKdgguvXEkuyNkQi3r8Z6qKu7d2A Date: Mon, 11 Sep 2017 03:58:32 +0000 Message-ID: References: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.54] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 03:58:36 -0000 SGkgQWxleCwNCg0KVGhhbmtzIGZvciBwb3N0aW5nIHRoZSBuZXcgdmVyc2lvbiBhZGRyZXNzaW5n IHNvbWUgb2YgbXkgY29tbWVudHMuIE15IG1haW4NCmlzc3VlIGlzIHN0aWxsIGFib3V0IHRoZSBu YXR1cmUgb2YgdGhlIGxpbmsgYmFzZWQgb24gODAyLjExLU9DQiBhbmQgdGhlDQpiaWcgY2hhbmdl IHRoYXQgdGhpcyBvcGVyYXRpbmcgZW52aXJvbm1lbnQgKFZlaGljdWxhcikgYnJpbmdzIHRvIHRo ZQ0KdGFibGUuIFdlIGNhbiBjZXJ0YWlubHkgaW5zaXN0IHRoYXQgdGhlIHNjb3BlIG9mIHRoaXMg d29yayBpcyBhYm91dA0KSVB2Ni1vdmVyLWZvbyBhbmQgc28gYW55IGRpc2N1c3Npb25zIGFyb3Vu ZCBhZGRyZXNzIGNvbmZpZ3VyYXRpb24gbW9kZXMsDQpORCwgbGluayBtb2RlbHMsIGxpbmsgcHJl Zml4ZXMgLi5ldGMgaXMgb3V0IG9mIHNjb3BlLiBCdXQsIG5vdGUgdGhhdCB0aGUNCklFRUUgZGVm aW5pdGlvbiBvZiBXQVZFLCA4MDIuMTEtT0NCLCBvciB0aGUgRFNSQyBzcGVjdHJ1bSBiYW5kIGlz IHN0cmljdGx5DQpmb3IgdmVoaWN1bGFyIGVudmlyb25tZW50cyBhbmQgc28gSSB0ZW5kIHRvIHRo aXMgZG9jdW1lbnQgaGFzIHRvIG1ha2Ugc3VyZQ0Kd2UgZXhwbGFpbiBob3cgb25lIGNhbiBtYWtl IElQdjYgYW5kIHRoZSBkZXBlbmRlbnQgcHJvdG9jb2xzIHdvcmsgb24NCjgwMi4xMS1PQ0IgYmFz ZWQgbGlua3MuICBXZSBjYW5ub3QgaWdub3JlIHRoZSBvcGVyYXRpbmcgZW52aXJvbm1lbnQuDQoN CkZvciBhIG5vZGUgdG8gc2VuZCBhbiBJUHY2IHBhY2tldCwgaXQgc3VyZWx5IG5lZWRzIHRvIGJl IGFibGUgdG8gZG8gdGhlDQpMMi9MMyBtYXBwaW5nIHRvIHRoZSByZXNwZWN0aXZlIGFjY2VzcyB0 ZWNobm9sb2d5IGFuZCB0cmFuc21pdCB0aGUgcGFja2V0Lg0KQnV0LCBpdCBhbHNvIG5lZWRzIHRv IGdlbmVyYXRlIGFuIElQdjYgYWRkcmVzcyAobGluay1sb2NhbCAvIGdsb2JhbCksDQpwZXJmb3Jt IERBRCBvbiB0aGUgbGluaywgcGVyZm9ybSBORCByZXNvbHV0aW9ucyBmb3IgdGhlIGRlc3RpbmF0 aW9uDQphZGRyZXNzLCBkbyB0aGUgcm91dGUgbG9va3VwcyBhbmQgc2VuZCB0aGUgcGFja2V0IG91 dC4gU28sIHdoYXQgaXMgbm90DQpjbGVhciB0byBtZSBmcm9tIHJlYWRpbmcgdGhlIHNwZWMgaXMg aG93IGFsbCBvZiB0aGF0IHdvcmtzIG9uIDgwMi4xMS1PQ0IuDQoNCjEuKSBMZXRzIHRha2UgYSBo aWdoLXdheSBzY2VuYXJpbyB3aGVyZSAzIHZlaGljbGVzIChBLCBCLCBDKSBjb21lIGluIGNsb3Nl DQpwcm94aW1pdHkgYW5kIGNhbiBjb21tdW5pY2F0ZSBhbW9uZyB0aGVtc2VsdmVzLg0KDQpBdCBU PTAsIA0KQy3igJRBLeKAlEINCg0KQXQgVD0xLCBvbmUgb2YgdGhlIHZlaGljbGUgbW92ZXMgb24g KHdpdGggc2lnbmFsIGxldmVsIDwgMzMgZGJtKSBmcm9tIHRoZQ0KcHJldmlvdXMgbmVpZ2hib3Jz LiBCdXQgdGhlcmUgaXMgYSBuZXcgbm9kZSBEIGluIHRoZSB2aWNpbml0eS4gQWxzbywgbm9kZQ0K QyBpcyBub3cgaW4gYW5vdGhlciBncm91cCAoIEMsIEUgYW5kIEYpDQpELeKAlEHigJQtQg0KDQpD LeKAlEUt4oCURg0KDQpGcm9tIHRoZSBjbGFzc2ljIGxpbmsgc2Vuc2UsIHRoZSBub2RlIGNvbmZp Z3VyYXRpb25zIGhhdmUgY2hhbmdlZC4NCg0KDQoyLikgSG93IGRvIHRoZSBub2RlcyBjb21tdW5p Y2F0ZSBhbW9uZyB0aGVtc2VsdmVzIGluIHRoZSBiYXNlIHNjZW5hcmlvLiBEbw0KdGhleSB1c2Ug bGluay1sb2NhbCBvciBnbG9iYWwgYWRkcmVzcz8gSG93IGRvIHRoZXkgZ2VuZXJhdGUgdGhlIGFk ZHJlc3Nlcz8NCg0KMy4pIElmIGl0cyBnbG9iYWwsIGhvdyBkbyB0aGV5IGRpc2NvdmVyIHRoZSBv bi1saW5rIHByZWZpeD8NCg0KMy4pIElmIGl0cyBsaW5rLWxvY2FsIChvciBnbG9iYWwpIEhvdyBk b2VzIERBRCB3b3JrIGluIHRoZSBhYm92ZSBzY2VuYXJpbz8NCldpdGggdGhlIGxpbmsgdG9wb2xv Z3kgY2hhbmdpbmcgc28gZHluYW1pY2FsbHksIGhvdyBjYW4gTkQgd29yayBoZXJlPw0KDQo0Likg V2lsbCB0aGUgbm9kZXMgc3VwcG9ydCBhbGwgc3RhbmRhcmQgbXVsdGljYXN0IGdyb3Vwcy4gRm9y IGV4YW1wbGUsDQp3aWxsIHRoZXkgcGFydGljaXBhdGUgaW4gQUxMX05PREVTX01VTFRJQ0FTVCBH Uk9VUCAoRkYwMjo6MSkuIElGIHllcywgd2h5DQppcyB0aGUgc3BlYyBkZWZpbmluZyBhIG5ldyBn cm91cCBmb3IgT0NCIG5vZGVzPyBXaHkgaXMgdGhhdCBuZWVkZWQ/DQoNCg0KUGxlYXNlIHNlZSBp bmxpbmUgZm9yIG90aGVyIGNvbW1lbnRzDQoNCg0KDQoNCg0KT24gOS8xMC8xNywgNTozNSBQTSwg IlNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkiIDxzZ3VuZGF2ZUBjaXNjby5jb20+DQp3cm90ZToN Cg0KPg0KPg0KPk9uIDkvMTAvMTcsIDY6NTkgQU0sICJBbGV4YW5kcmUgUGV0cmVzY3UiIDxhbGV4 YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPg0KPndyb3RlOg0KPg0KPj5TcmksDQo+Pg0KPj5UaGFu a3MgZm9yIHRoZSByZXZpZXcuDQo+Pg0KPj5MZSAyNy8wOC8yMDE3IMOgIDE2OjQ0LCBTcmkgR3Vu ZGF2ZWxsaSAoc2d1bmRhdmUpIGEgw6ljcml0IDoNCj4+Wy4uLl0NCj4+DQo+Pj4gMS4pIEl0cyBu b3QgY2xlYXIsIGlmIHRoZSBkb2N1bWVudCBtYWtlcyBhbnkgYXNzdW1wdGlvbiBvbiB0aGUNCj4+ PiBvcGVyYXRpbmcgZW52aXJvbm1lbnQvY29tbXVuaWNhdGlvbiBwcm9maWxlLiBUaGVyZSBpcyBu b3QgbXVjaA0KPj4+IGRpc2N1c3Npb24gb24gdGhhdCBhc3BlY3Q7IEZvciBleGFtcGxlLCBJcyBp dCBhbHdheXMgYSBvbmUtaG9wDQo+Pj4gY29tbXVuaWNhdGlvbiBiZXR3ZWVuIFJTVSBhbmQgT0JV IHdoZXJlIHRoZSA4MDIuMTEtT0NCIGxpbms/ICBTbywgaXMNCj4+PiB0aGUgdXNlIG9mIElQdjYg b25seSBpbiB0aGF0IGNvbnRleHQgb2YgMS1ob3AgY29tbXVuaWNhdGlvbj8NCj4+DQo+PlRoZSBx dWVzdGlvbiBpcyB2ZXJ5IHJlbGV2YW50LCBidXQgbm90IHBsYWNlIGluIHRoaXMgZG9jdW1lbnQg dG8gZ28gdG8NCj4+bXVjaCBleHRlbnQgYWJvdXQgaXQgaW4gYW4gSVAtb3Zlci1mb28gZG9jdW1l bnQuDQoNCg0KSSB3b3VsZCBoYXZlIGFncmVlZCB3aXRoIHRoZSDigJxJUC1vdmVyLWZvb+KAnSBh bmFsb2d5IGFuZCBzdGF5IGF3YXkgZnJvbQ0KYW5zd2VyaW5nIG1hbnkgcXVlc3Rpb24sIGJ1dCBs ZXRzIGxvb2sgYXQgdGhlIFdBVkUsIDgwMi0xMS1PQ0IgYW5kIERTUkMNCmRlZmluaXRpb25zLiBJ dCBjbGVhcmx5IGZvciB2ZWhpY3VsYXIgZW52aXJvbm1lbnRzLiBUaGF0IHRoZSBiYXNlbGluZQ0K YXNzdW1wdGlvbi4gU28sIHdoZW4gd2Ugc2F5IElQdjYgZm9yIDgwMi0xMS1PQ0IsIHRoZSBvcGVy YXRpbmcgZW52aXJvbm1lbnQNCmNhbm5vdCBiZSBpZ25vcmVkLg0KDQoNCg0KPj4NCj4+VG8gYW5z d2VyIG5vdzogaXMgdGhhdCAxIE9DQiBob3AgaXMgcmlnaHQgYXQgdGhpcyB0aW1lLg0KPj4NCj4+ PiAyLikgVGhlcmUgaXMgYWxzbyBubyBkaXNjdXNzaW9uIG9uIGhvdyB0aGVzZSBsaW5rcyBnZXQg Zm9ybWVkIGluDQo+Pj4gdmVoaWN1bGFyIGVudmlyb25tZW50IGFuZCB3aGVuIHRoZXkgYXJlIGF0 dGFjaGVkL2RldGFjaGVkLg0KPj4NCj4+QXMgYWJvdmUuDQo+Pg0KPj4+IDMuKSBIb3cgZG8gbm9k ZXMgZGlzY292ZXIgZWFjaCBvdGhlcj8gIEhvdyBkb2VzIE5EIHJlc29sdXRpb24gd29yaz8NCj4+ PiBBcmUgdGhlc2UgbWVzc2FnZXMgcmVjZWl2ZWQgYnkgYSBtdWx0aXBsZSBSU1XCuXMsIG9yIGEg c2luZ2xlIFJTVT8NCj4+PiBXaGF0cyB0aGUgaW1wbGljYXRpb24gb2YgdGhhdC4gTm90ZSB0aGF0 IHlvdSBkb27CuXQgaGF2ZSB0aGF0IGlzc3VlIGluDQo+Pj4gODAyLjExLCBnaXZlbiB0aGUgYXNz b2NpYXRpb24gdG8gYW4gYWNjZXNzIHBvaW50LCB3aGljaCBpbiB0dXJuIG1hcHMNCj4+PiB0aGUg bGlua3MgdG8gYSBWTEFOL3N1Ym5ldC4NCj4+DQo+PkkgdGhpbmsgTkQgbWF5IGFuc3dlciB0byBz b21lIG9mIHRoZSBxdWVzdGlvbnMuDQo+Pj4gDQo+Pj4gNC4pIFdoYXQgaGFwcGVucyBhcyBhIHZl aGljbGUgbW92ZXMgYmV0d2VlbiBSU1XCuXMsIGhvdyBkb2VzIGl0IGltcGFjdA0KPj4+ICBhZGRy ZXNzIGNvbmZpZ3VyYXRpb24/DQo+Pg0KPj5Nb2JpbGUgSVAsIGJ1dCBub3QgaW4gdGhpcyBkb2N1 bWVudC4NCj4+DQo+Pj4gSXMgREhDUHY2IGJhc2VkIGFkZHJlc3MgY29uZmlndXJhdGlvbiByZWxl dmFudCBoZXJlPw0KPj4NCj4+WUVzLCBidXQgbm90IHRvIGRlc2NyaWJlIHRoZSBkZXRhaWwgdXNl IG9mIERIQ1B2Ni1vdmVyLWZvbyBvbg0KPj5JUC1vdmVyLWZvby4NCj4+DQo+PklmIHlvdSB3YW50 IHRvIGp1c3QgcmVmZXIgdG8gREhDUCwgdGhhdCB3b3VsZCBiZSBhdCB3aGljaCBwbGFjZSBpbiB0 aGlzDQo+PmRvY3VtZW50Pw0KPj4NCg0KDQpTdXJlLCBidXQgdGhpcyBpcyBhIHNwZWNpYWwgdHlw ZSBvZiBsaW5rIGFuZCBzbyBpdHMgbm90IGNsZWFyIGhvdyB0aGlzDQp3b3Jrcy4NCg0KREhDUCBz ZXJ2ZXIgY2FuIGJlIG91dHNpZGUgdGhlIGxpbms7IGluIHRoZSBjdXJyZW50IHNwZWMsIGl0cyBu b3QgY2xlYXINCmhvdyB0aGUgbm9kZSBldmVuIGRpc2NvdmVycyB0aGUgb24tbGluayBwcmVmaXgs IG9yIHRoZSBkZWZhdWx0IHJvdXRlci4NCg0KDQo+Pg0KPj5bLi4uXQ0KPj4+IFdlIGJyaWVmbHkg aW50cm9kdWNlIHRoZSB2ZWhpY3VsYXIgY29tbXVuaWNhdGlvbiBzY2VuYXJpb3Mgd2hlcmUNCj4+ PiBJRUVFIDgwMi4xMS1PQ0IgbGlua3MgYXJlIHVzZWQuDQo+Pj4gDQo+Pj4gDQo+Pj4gW1NyaV0g SSBoYXZlIG5vdCBzZWVuIG11Y2ggZGlzY3Vzc2lvbiBvbiB0aGUgbGluayAvIGNvbW11bmljYXRp b24NCj4+PiBhc3N1bXB0aW9ucy4NCj4+DQo+PlRoYXQncyB3aHkgaXQgc2F5cyAnYnJpZWZseScu DQo+Pg0KPj5bLi4uXQ0KPj4NCj4+PiBUaGUgSUVFRSA4MDIuMTEgT0NCIE5ldHdvcmtzIGFyZSB1 c2VkIGZvciB2ZWhpY3VsYXIgY29tbXVuaWNhdGlvbnMsDQo+Pj4gYXMgJ1dpcmVsZXNzIEFjY2Vz cyBpbiBWZWhpY3VsYXIgRW52aXJvbm1lbnRzJy4gIFRoZSBJUA0KPj4+IGNvbW11bmljYXRpb24g c2NlbmFyaW9zIGZvciB0aGVzZSBlbnZpcm9ubWVudHMgaGF2ZSBiZWVuIGRlc2NyaWJlZCBpbg0K Pj4+IHNldmVyYWwgZG9jdW1lbnRzLCBhbW9uZyB3aGljaCB3ZSByZWZlciB0aGUgcmVhZGVyIHRv IG9uZSByZWNlbnRseQ0KPj4+IHVwZGF0ZWQgW0ktRC5wZXRyZXNjdS1pdHMtc2NlbmFyaW9zLXJl cXMNCj4+PiANCj4+PjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHdh dmUtaXB2Ni1vdmVyLTgwMjExb2NiLTA0I3JlZg0KPj4+LQ0KPj4+SS1ELnBldHJlc2N1LWl0cy1z Y2VuYXJpb3MtcmVxcz5dLA0KPj4+IGFib3V0IHNjZW5hcmlvcyBhbmQgcmVxdWlyZW1lbnRzIGZv ciBJUCBpbiBJbnRlbGxpZ2VudCBUcmFuc3BvcnRhdGlvbg0KPj4+IFN5c3RlbXMuDQo+Pj4gDQo+ Pj4gDQo+Pj4gW1NyaV0gWW91IGNhbiBkbyBiaXQgbW9yZSBqdXN0aWNlIHRvIHRoaXMgc2VjdGlv bi4NCj4+PiANCj4+PiBFeHBsYWluIHRoZSBsaW5rIG1vZGVsLiDCs1NUQSAtLS0tODAyLjExLU9D QuKAueKAuVNUQcKyLiBUaGVuIHRhbGsgYWJvdXQNCj4+PiB0aGUgYXBwbGljYWJpbGl0eSBpbiBW ZWhpY3VsYXIgbmV0d29ya3MsIHdpdGggU1RBJ3MgYXMgUlNVIGFuZCBPQ0IuDQo+Pj4gDQo+Pj4g WW91IG1heSBhbHNvIHdhbnQgdG8gdGFsayBhYm91dCwgaG93IGxpbmtzIGdldCBmb3JtZWQvdGVy bWluYXRlZDsgaG93DQo+Pj4gIG5vZGVzIHBlZXIvZGlzY292ZXIgYW5kIGhvdyBtb2JpbGl0eSB3 b3JrcyAuLmV0Yy4gV2hpbGUgODAyLjExLU9DQg0KPj4+IGlzIGNsZWFybHkgc3BlY2lmaWVkIGFu ZCB0aGUgdXNlIG9mIElQdjYgb3ZlciBzdWNoIGxpbmsgaXMgYWxzbyBub3QNCj4+PiByYWRpY2Fs bHkgbmV3LCBidXQgdGhlIG9wZXJhdGluZyBlbnZpcm9ubWVudCB3aGljaCBpcyB2ZWhpY3VsYXIN Cj4+PiBicmluZ3MgbWFueSBuZXcgdGhpbmdzLiBUaGF0IGRlc2NyaXB0aW9uIGlzIG5vdCBwcmVz ZW50IGFueSB3aGVyZS4NCj4+DQo+PkkgbWVudGlvbmVkIGl0IGJ1dCB0aGUgZGV0YWlscyBhcmUg b3V0IG9mIHNjb3BlIGZvciBhbiBJUHY2IG92ZXIgZm9vDQo+PmRvY3VtZW50Lg0KDQoNClBlciBt eSBjb21tZW50cyBpbiB0aGUgYmVnaW5uaW5nIC4uLg0KDQoNCg0KDQo+Pg0KPj5bLi4uXQ0KPj4N Cj4+PiBbU3JpXSBJIGFtIHJlYWxseSBub3Qgc3VyZSBob3cgbGluayB0aHJvdWdocHV0ICgxMk1i cHMpIHJlbGF0ZXMgdG8NCj4+PiAiSVB2NiBzdXBwb3J0IG9uIE9DQiBsaW5rcyIuDQo+Pg0KPj44 MDIuMTEtT0NCIG1heCAxMm1iaXQvcyBtZWFucyBvbmUgX2Nhbl8gcnVuIGEgd2lkZSByYW5nZSBv ZiBhcHBsaWNhdGlvbnMNCj4+b24gaXQuICBPdGhlciBsaW5rcyBhcmUgc28gc21hbGwgYW5kIHJh cmUgdGhhdCB5b3UgY2FuIG5vdCBydW4gSVB2NiBvbg0KPj50aGVtLCBtdXN0IGNoYW5nZSBJUHY2 LiAoTE9SQSwgMTUuNCwgZXRjKS4NCj4+DQo+Pj4gbyAgT3BlcmF0aW9uIE91dHNpZGUgdGhlIENv bnRleHQgb2YgYSBCU1MgKE9DQik6IHRoZSAoZWFybGllcg0KPj4+IDgwMi4xMXApIDgwMi4xMS1P Q0IgbGlua3MgYXJlIG9wZXJhdGVkIHdpdGhvdXQgYSBCYXNpYyBTZXJ2aWNlIFNldA0KPj4+IChC U1MpLiAgVGhpcyBtZWFucyB0aGF0IHRoZSBmcmFtZXMgSUVFRSA4MDIuMTEgQmVhY29uLCBBc3Nv Y2lhdGlvbg0KPj4+IFJlcXVlc3QvUmVzcG9uc2UsIEF1dGhlbnRpY2F0aW9uIFJlcXVlc3QvUmVz cG9uc2UsIGFuZCBzaW1pbGFyLCBhcmUNCj4+PiBub3QgdXNlZC4gIFRoZSB1c2VkIGlkZW50aWZp ZXIgb2YgQlNTIChCU1NJRCkgaGFzIGEgaGV4YWRlY2ltYWwgdmFsdWUNCj4+PiBhbHdheXMgMHhm ZmZmZmZmZmZmZmYgKDQ4ICcxJyBiaXRzLCByZXByZXNlbnRlZCBhcyBNQUMgYWRkcmVzcw0KPj4+ IGZmOmZmOmZmOmZmOmZmOmZmLCBvciBvdGhlcndpc2UgdGhlICd3aWxkY2FyZCcgQlNTSUQpLCBh cyBvcHBvc2VkIHRvDQo+Pj4gYW4gYXJiaXRyYXJ5IEJTU0lEIHZhbHVlIHNldCBieSBhZG1pbmlz dHJhdG9yIChlLmcuDQo+Pj4gJ015LUhvbWUtQWNjZXNzUG9pbnQnKS4gIFRoZSBPQ0Igb3BlcmF0 aW9uIC0gbmFtZWx5IHRoZSBsYWNrIG9mDQo+Pj4gYmVhY29uLWJhc2VkIHNjYW5uaW5nIGFuZCBs YWNrIG9mIGF1dGhlbnRpY2F0aW9uIC0gaGFzIGEgcG90ZW50aWFsbHkNCj4+PiBzdHJvbmcgaW1w YWN0IG9uIHRoZSB1c2Ugb2YgdGhlIE1vYmlsZSBJUHY2IHByb3RvY29sIFtSRkM2Mjc1DQo+Pj4g PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2Mjc1Pl0gYW5kIG9uIHRoZSBwcm90b2Nv bHMgZm9yIElQDQo+Pj4gbGF5ZXIgc2VjdXJpdHkgW1JGQzQzMDEgPGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM0MzAxPl0uDQo+Pj4gDQo+Pj4gDQo+Pj4gW1NyaV0gVGhlIGRvY3VtZW50 IHRpbGwgbm93IGhhcyBiZWVuIGFyZ3VpbmcgaGVhdmlseSBvbiBob3cgSVB2Ng0KPj4+IG9wZXJh dGVzIHNvIG5hdHVyYWxseSBvbiB0aGVzZSBsaW5rcyBhbmQgbm93IEkgc2VlIGRpc2N1c3Npb24g b24NCj4+PiDCs0ltcGFjdCB0byBhIGhpZ2gtbGV2ZWwgcHJvdG9jb2wgc3VjaCBhcyBNSVB2NsKy LiBZb3UgbWF5IHdhbnQgdG8gZml4DQo+Pj4gdGhlIGVhcmxpZXIgdGV4dC4NCj4+SSByZW1vdmVk ICdpbXBhY3QnIHdvcmQuICAgQnV0IGFsc28sIHRoZSB3YXkgTUlQIGFkYXB0cyB0byBPQ0IgaXMN Cj4+b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCj4+DQo+Pj4gSW4gYW55IGNh c2UsIHRoZSBhYnNlbmNlIG9mIGxpbmstbGF5ZXIgc2VjdXJpdHkgcHJhY3RpY2FsbHkgaW1wYWN0 cw0KPj4+IGV2ZXJ5IGFwcGxpY2F0aW9uLCBub3QganVzdCBNSVB2Ni4gQWxzbywgTUlQdjYgZG9l cyBub3QgbWFrZSBhbnkNCj4+PiBhc3N1bXB0aW9ucyBvbiB0aGUgbGluay1sYXllciBzZWN1cml0 eS4gQWxzbywgdGhlIHRoZQ0KPj4+IDB4RkYtRkYtRkYtRkYtRkYtRkYgYXMgdGhlIEJTU0lELCBt YWtlcyB0aGUgbWVzc2FnZXMgcmVhZGFibGUgYnkgYWxsDQo+Pj4gIG90aGVyIFJTVcK5cyBpbiBw cm94aW1pdHkuIEkgdGhpbmsgdGhlIGRpc2N1c3Npb24gb24gdGhlIG5hdHVyZSBvZg0KPj4+IHRo ZSBsaW5rLCB3aG8gYWxsIHNlZcK5cyB0aGUgbWVzc2FnZXMuLiBob3cgTDIgYWRkcmVzc2VzIGFy ZSByZXNvbHZlZA0KPj4+IGlzIG5vdCBleHBsYWluZWQgY2xlYXJseS4NCj4+DQo+PkkgYWRkZWQg c29tZSB0ZXh0IGFib3V0IE5EIGFuZCBzb21lIGluIHRoZSBzZWN1cml0eSBzZWN0aW9uIGFib3V0 IGhvdw0KPj50aGlzIGlzIG9wZW4uDQo+Pg0KPj5bLi4uXQ0KPj4NCj4+PiBPdGhlciBhc3BlY3Rz IHBhcnRpY3VsYXIgdG8gODAyLjExLU9DQiB3aGljaCBhcmUgYWxzbyBwYXJ0aWN1bGFyIHRvDQo+ Pj4gODAyLjExIChlLmcuIHRoZSAnaGlkZGVuIG5vZGUnIG9wZXJhdGlvbikgbWF5IGhhdmUgYW4g aW5mbHVlbmNlIG9uDQo+Pj4gdGhlIHVzZSBvZiB0cmFuc21pc3Npb24gb2YgSVB2NiBwYWNrZXRz IG9uIDgwMi4xMS1PQ0IgbmV0d29ya3MuKlRoZQ0KPj4+IHN1Ym5ldCBzdHJ1Y3R1cmUgd2hpY2gg bWF5IGJlIGFzc3VtZWQgaW4gODAyLjExLU9DQiBuZXR3b3JrcyBpcw0KPj4+IHN0cm9uZ2x5IGlu Zmx1ZW5jZWQgYnkgdGhlIG1vYmlsaXR5IG9mIHZlaGljbGVzLioNCj4+PiANCj4+PiANCj4+PiBb U3JpXSBQZXIgbXkgZWFybGllciBjb21tZW50LCB0aGUgbGluayBtb2RlbCwgYWRkcmVzc2luZyAu LmV0YyBuZWVkcw0KPj4+IHRvIGJlIGV4cGxhaW5lZCBpbiBtb3JlIGRldGFpbC4gSXQgaXMgbm90 IGNsZWFyIHdoYXQgZXhhY3RseSB0aGUNCj4+PiDCs3N1Ym5ldCBzdHJ1Y3R1cmXCsiB0aGF0IGlz IGFzc3VtZWQgaW4gODAyLjExLU9DQi4NCj4+DQo+PkltcHJvdmVkIHRoZSBzdWJuZXQgc3RydWN0 dXJlIHNlY3Rpb24uDQoNCg0KTWF5IHJlcXVpcmUgZmV3IG1vcmUgZGV0YWlscw0KDQoNCj4+DQo+ PlsuLi5dPiAgICAgVGhlIEVxdWl2YWxlbnQgVHJhbnNtaXQgVGltZSBvbiBDaGFubmVsIGlzIGEg Y29uY2VwdCB0aGF0IG1heQ0KPj5iZSB1c2VkDQo+Pj4gYXMgYW4gYWx0ZXJuYXRpdmUgdG8gdGhl IE1UVSBjb25jZXB0LiAgQSByYXRlIG9mIHRyYW5zbWlzc2lvbiBtYXkgYmUNCj4+PiBzcGVjaWZp ZWQgYXMgd2VsbC4gIFRoZSBFVFRDLCByYXRlIGFuZCBNVFUgbWF5IGJlIGluIGRpcmVjdA0KPj4+ IHJlbGF0aW9uc2hpcC4NCj4+PiANCj4+PiBbU3JpXSBUaGUgbGFzdCBwYXJhZ3JhcGggbmVlZHMg c29tZSBhZGRpdGlvbmFsIGNvbnRleHQuIERpZA0KPj4+IDgwMi4xMS1PQ0IgaW50cm9kdWNlIEVU VEMgY29uY2VwdD8NCj4+DQo+PldlIGhlYXJkIHRoaXMgdGVybSBhdCBtaWMgaW4gQmVybGluIEJv Ri4gIFNvdW5kZWQgbGlrZSBhIG1vcmUgdW5pdmVyc2FsDQo+PnRlcm0uICBTaG91bGQgd2UgcmVt b3ZlIGl0Pw0KDQoNCg0KSSB1bmRlcnN0YW5kIHRoZSByZWxhdGlvbiBiZXR3ZWVuIE1UVSBhbmQg dGhlIEVUVEMuIEJ1dCwgaWYgd2UgdGFsayBhYm91dA0KaXQsIHdlIGhhdmUgdG8gZXhwbGFpbiB3 aGljaCBwYXJhbWV0ZXIgZHJpdmVzIHRoZSBvdGhlci4gSG93IGRvIHlvdQ0KZXhhY3RseSBzZXQg dGhlIE1UVSBiYXNlZCBvbiB0aGUgRVRUQyByYXRlLiBNb3JlIGRldGFpbHMgb24gbmVlZGVkLg0K DQoNCg0KPj4NCj4+Wy4uLl0NCj4+PiBUaGUgbWFwcGluZyBiZXR3ZWVuIHFvcy1yZWxhdGVkIGZp ZWxkcyBpbiB0aGUgSVB2NiBoZWFkZXIgKGUuZy4NCj4+PiAiVHJhZmZpYyBDbGFzcyIsICJGbG93 IGxhYmVsIikgYW5kIGZpZWxkcyBpbiB0aGUgIjgwMi4xMSBRb1MgRGF0YQ0KPj4+IEhlYWRlciIg KGUuZy4gICJRb1MgQ29udHJvbCIpIGFyZSBub3Qgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQu DQo+Pj4gR3VpZGFuY2UgZm9yIGEgcG90ZW50aWFsIG1hcHBpbmcgaXMgcHJvdmlkZWQgaW4NCj4+ PiBbSS1ELmlldGYtdHN2d2ctaWVlZS04MDItMTENCj4+PiANCj4+PjxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTA0I3JlZg0K Pj4+LQ0KPj4+SS1ELmlldGYtdHN2d2ctaWVlZS04MDItMTE+XSwNCj4+PiBhbHRob3VnaCBpdCBp cyBub3Qgc3BlY2lmaWMgdG8gT0NCIG1vZGUuDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gW1NyaV0g VGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIFFvUyBtYXBwaW5nIGRyYWZ0IHRvIDgwMi4xMS1PQ0Ig bmVlZHMNCj4+PiAgZnVydGhlciBpbnZlc3RpZ2F0aW9uLCBJTU8uDQo+Pg0KPj5ZRXMsIGl0IGlz IG91dCBvZiBzY29wZSBpbiB0aGlzIGRvY3VtZW50Lg0KPj4NCj4+PiA1LjMgDQo+Pj4gDQo+Pj48 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04 MDIxMW9jYi0wNCNzZWMNCj4+PnQNCj4+Pmlvbi01LjM+Lg0KPj4+DQo+Pj4gDQo+PkxpbmstTG9j YWwgQWRkcmVzc2VzDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gVGhlIGxpbmstbG9jYWwgYWRkcmVz cyBvZiBhbiA4MDIuMTEtT0NCIGludGVyZmFjZSBpcyBmb3JtZWQgaW4gdGhlDQo+Pj4gc2FtZSBt YW5uZXIgYXMgb24gYW4gRXRoZXJuZXQgaW50ZXJmYWNlLiAgVGhpcyBtYW5uZXIgaXMgZGVzY3Jp YmVkDQo+Pj4gaW4gc2VjdGlvbiA1IG9mIFtSRkMyNDY0XQ0KPj4+IDxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjMjQ2NCNzZWN0aW9uLTU+Lg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IFtT cmldIERvZXMgdGhpcyBnbyBhZ2FpbnN0IHRoZSA4MDY0IHJlY29tbWVuZGF0aW9uIG9uIEludGVy ZmFjZQ0KPj4+IGlkZW50aWZpZXIgZ2VuZXJhdGlvbj8NCj4+DQo+PllFcy4NCg0KDQpXZSBzaG91 bGQgc3RhdGUgdGhhdC4NCg0KDQoNCj4+DQo+Pj4gTWF5IGJlIFJGQzcyMTcgZm9yIGludGVyZmFj ZSBpZGVudGlmaWVyIGdlbmVyYXRpb24gaW4gY29uanVuY3Rpb24NCj4+PiB3aXRoIHRoZSBsaW5r LWxvY2FsIGFkZHJlc3MgZ2VuZXJhdGlvbiBwZXIgUkZDMjQ2NA0KPj4NCj4+WUVzLiAgQnV0IEkg dGhpbmsgaXQncyB1cCB0byByZmMyNDY0LWJpcyB0byBzYXkgdGhhdCwgYW5kIHRoaXMNCj4+SVB2 Ni1vdmVyLU9DQiB0byBqdXN0IHJlZmVyIHRvIHJmYzI0NjQtYmlzLg0KDQpBcyB3aXRoIGFueSBi aXMgZG9jdW1lbnQsIGl0cyBub3QgZ29pbmcgbWVyZ2UgbmV3ZXIgc3BlY3MgaW50byBpdC4gV2UN CnN0aWxsIG5lZWQgdG8gcmVmZXIgdG8gdGhlIG90aGVyIGRvY3VtZW50cywgSU1PLg0KDQoNCg0K DQo+Pg0KPj5bLi4uXQ0KPj4+IEZvciB1bmljYXN0IGFzIGZvciBtdWx0aWNhc3QsIHRoZXJlIGlz IG5vIGNoYW5nZSBmcm9tIHRoZSB1bmljYXN0DQo+Pj4gYW5kIG11bHRpY2FzdCBhZGRyZXNzIG1h cHBpbmcgZm9ybWF0IG9mIEV0aGVybmV0IGludGVyZmFjZXMsIGFzDQo+Pj4gZGVmaW5lZCBieSBz ZWN0aW9uczYNCj4+PiANCj4+PjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTA0I3NlYw0KPj4+dA0KPj4+aW9uLTY+DQo+Pj4g YW5kNyANCj4+PiANCj4+PjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1p cHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTA0I3NlYw0KPj4+dA0KPj4+aW9uLTc+DQo+Pj4gb2Yg W1JGQzI0NjQgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyNDY0Pl0uDQo+Pj4gDQo+ Pj4gDQo+Pj4gDQo+Pj4gW1NyaV0gUkZDNjA4NSBzcGVjaWZpZWQgbWFwcGluZyBpcyBhbHNvIHJl bGV2YW50OyBJZiB0aGUNCj4+PiBjb21tdW5pY2F0aW9uIHBlZXJzIGFyZSBhd2FyZSB0aGF0IHRo ZXJlIGlzIG9ubHkgb25lIHBlZXIsIGl0IHNob3VsZA0KPj4+IGFwcGx5IDYwODUgc3BlY2lmaWVk IG1hcHBpbmcuIFRoYXQgbW9kZSBpcyByZWxldmFudCBmb3IgODAyLjExLU9DQg0KPj4+IHR5cGVz IGxpbmtzIGFzIHdlbGwuDQo+Pg0KPj5TYW1lIGhlcmUsIHdvdWxkIGJlIGdyZWF0IHRvIGdldCA2 MDg1IGludG8gMjQ2NC1iaXMsIGF0IHdoaWNoIHBvaW50IHRoaXMNCj4+aXAtb3Zlci1vY2IgaW5o ZXJpdHMgZnJvbSAyNDY0LWJpcy4NCg0KDQpJIGRvIG5vdCB0aGluayAyNDY0LWJpcyB3aWxsIGFk ZCBuZXcgcmVmZXJlbmNlcy4gSXRzIHVwIHRvIHlvdSwgYnV0IDYwODUNCm1heSBiZSByZWxldmFu dCBoZXJlLg0KDQoNCj4+DQo+PkkgYWRkZWQgYSByZWZlcmVuY2UgdG8gMjQ2NC1iaXMuDQo+Pg0K Pj4+IDUuNC4xIA0KPj4+IA0KPj4+PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMDQjc2VjDQo+Pj50DQo+Pj5pb24tNS40LjE+ Lg0KPj4+DQo+Pj4gDQo+PkFkZHJlc3MgTWFwcGluZyAtLSBVbmljYXN0DQo+Pj4gDQo+Pj4gDQo+ Pj4gDQo+Pj4gVGhlIHByb2NlZHVyZSBmb3IgbWFwcGluZyBJUHY2IHVuaWNhc3QgYWRkcmVzc2Vz IGludG8gRXRoZXJuZXQgbGluay0NCj4+PiBsYXllciBhZGRyZXNzZXMgaXMgZGVzY3JpYmVkIGlu IFtSRkM0ODYxDQo+Pj4gPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0ODYxPl0uICBU aGUgU291cmNlL1RhcmdldCBMaW5rLQ0KPj4+IGxheWVyIEFkZHJlc3Mgb3B0aW9uIGhhcyB0aGUg Zm9sbG93aW5nIGZvcm0gd2hlbiB0aGUgbGluay1sYXllciBpcw0KPj4+IEV0aGVybmV0Lg0KPj4+ IA0KPj4+IFtTcmldIEkgdGhvdWdodCwgbWFwcGluZyBvZiBJUHY2IHVuaWNhc3QgYWRkcmVzc2Vz IHRvIEV0aGVybmV0DQo+Pj4gbGluay1sYXllciBhZGRyZXNzZXMgaXMgc3BlY2lmaWVkIGluIHNl Y3Rpb24gNiwgb2YgUkZDMjQ2NCBhbmQgbm90IGluDQo+Pj4gIFJGQzQ4NjEuDQo+Pg0KPj5FaXRo ZXIgd2UgaGF2ZSBhIGJyaWVmIHBhcmFncmFwaCB0aGF0IGp1c3QgcmVmZXJzIHRvIDI0NjQgc2Vj dGlvbiA2LCBvcg0KPj5jb3B5IHBhc3RlIHRoYXQgc2VjdGlvbiBmcm9tIDI0NjQgYW5kIHVwZGF0 ZSBpdHMgW0RJU0NdIHJlZmVyZW5jZSB0bw0KPj40ODYxLiAgVGhhdCBJIGRpZCwgaW4gb3JkZXIg dG8gaGF2ZSB0aGUgdGV4dCBhIGJpdCBsb25nZXIuDQo+Pg0KPj5BdCB0aGlzIHRpbWUgSSBrZWVw IGl0IHRoYXQgd2F5LCB1bmxlc3Mgc29tZW9uZSBvcHBvc2VzLg0KDQoNCk1heSBiZSBJIGFtIG1p c3Npbmcgc29tZSB0aGluZy4gVGhlIG1hcHBpbmcgaXMgZGVmaW5lZCBpbiAyNDY0IGFuZCBzbyB0 aGUNCjQ4NjEgcmVmZXJlbmNlIG1heSBiZSBpbmNvcnJlY3QuDQoNCg0KPj4NCj4+QSBrZXkgcXVl c3Rpb24gaGVyZSBpcyBob3cgaXMgMjQ2NGJpcyBhZHZhbmNpbmcsIGFuZCBob3cgd2UgY29vcmRp bmF0ZQ0KPj53aXRoIGl0Lg0KPj5bLi4uXQ0KPj4+IEFuIElQdjYgcGFja2V0IHdpdGggYSBtdWx0 aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyBEU1QsIGNvbnNpc3RpbmcNCj4+PiBvZiB0aGUgc2l4 dGVlbiBvY3RldHMgRFNUWzFdIHRocm91Z2ggRFNUWzE2XSwgaXMgdHJhbnNtaXR0ZWQgdG8gdGhl DQo+Pj4gSUVFRSA4MDIuMTEtT0NCIE1BQyBtdWx0aWNhc3QgYWRkcmVzcyB3aG9zZSBmaXJzdCB0 d28gb2N0ZXRzIGFyZSB0aGUNCj4+PiB2YWx1ZSAweDMzMzMgYW5kIHdob3NlIGxhc3QgZm91ciBv Y3RldHMgYXJlIHRoZSBsYXN0IGZvdXIgb2N0ZXRzIG9mDQo+Pj4gRFNULg0KPj4+IA0KPj4+IFtT cmldIFBsZWFzZSBhZGQgYSByZWZlcmVuY2UgdG8gU2VjdGlvbiA3LCBSRkM0ODYxIGFuZCBhbHNv IFJGQzYwODUuDQo+Pj4gSW4gZ2VuZXJhbCwgZm9yIGJvdGggdW5pY2FzdCBhbmQgbXVsdGljYXN0 LCB5b3UgbWF5IHdhbnQgdG8gY2xlYXJseQ0KPj4+IHNheSB0aGF0IHRoaXMgaXMgcGVyIHRoZSBl eGlzdGluZyBzcGVjcyBhbmQgZHVwbGljYXRlZCBoZXJlIGZvcg0KPj4+IGNvbnZlbmllbmNlLg0K Pj4NCj4+U2hvdWxkIF90aGlzXyBkb2N1bWVudCBkbyBpdCwgb3Igc2hvdWxkIHRoZSAyNDY0Ymlz IGRvIGl0PyAgQXQgdGhpcyB0aW1lDQo+Pkkga2VlcCBpdCB0aGF0IHdheS4NCg0KDQpJIGFtIG5v dCB0cmFja2luZyB0aGUgYmlzIGFuZCBzbyBub3Qgc3VyZSBpZiBpdCB3aWxsIGluY2x1ZGUgYWxs IHRoZXNlDQpkb2N1bWVudHMuIEFueSB3YXlzIOKApnlvdXIgY2FsbA0KDQo+PlsuLi5dDQo+Pg0K Pj4+IFRoZSBJbnRlcmZhY2UgSWRlbnRpZmllciBmb3IgYW4gODAyLjExLU9DQiBpbnRlcmZhY2Ug aXMgZm9ybWVkIHVzaW5nDQo+Pj4gdGhlIHNhbWUgcnVsZXMgYXMgdGhlIEludGVyZmFjZSBJZGVu dGlmaWVyIGZvciBhbiBFdGhlcm5ldA0KPj4+IGludGVyZmFjZTsgdGhpcyBpcyBkZXNjcmliZWQg aW5zZWN0aW9uIDQgb2YgW1JGQzI0NjRdDQo+Pj4gPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmMyNDY0I3NlY3Rpb24tND4uICBObyBjaGFuZ2VzIGFyZQ0KPj4+IG5lZWRlZCwgYnV0IHNv bWUgY2FyZSBtdXN0IGJlIHRha2VuIHdoZW4gY29uc2lkZXJpbmcgdGhlIHVzZSBvZiB0aGUNCj4+ PiBTTEFBQyBwcm9jZWR1cmUuDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gW1NyaV0gUGVyIG15IGVh cmxpZXIgY29tbWVudCwgcGxlYXNlIHJlZmVyIHRvIHRoZSBjdXJyZW50DQo+Pj4gcmVjb21tZW5k YXRpb24gb24gaW50ZXJmYWNlLWlkZW50aWZpZXIgZ2VuZXJhdGlvbiBhbmQgaXRzIHVzZSBpbg0K Pj4+IGxpbmstbG9jYWwsIGdsb2JhbCBvciBvdGhlciBhZGRyZXNzZXMuDQo+Pg0KPj5QZXIgbXkg Y29tbWVudHMgYWJvdmUgLSB3aGF0IGRvIHlvdSB0aGluayBhYm91dCAyNDY0YmlzIGRvaW5nIHlv dXINCj4+cmVjb21tZW5kYXRpb25zLCByYXRoZXIgdGhhbiB0aGlzIG9uZS4NCj4+DQo+PkRlcGVu ZGluZyBvbiB0aGF0LCB3ZSBjYW4gc2VlIGZ1cnRoZXIgd2l0aCB0aGlzIGRvY3VtZW50Lg0KPj4N Cj4+Wy4uLl0NCj4+DQo+Pj4gVGhlIDgwMi4xMSBuZXR3b3JrcyBpbiBPQ0IgbW9kZSBtYXkgYmUg Y29uc2lkZXJlZCBhcyAnYWQtaG9jJw0KPj4+IG5ldHdvcmtzLiAgVGhlIGFkZHJlc3NpbmcgbW9k ZWwgZm9yIHN1Y2ggbmV0d29ya3MgaXMgZGVzY3JpYmVkIGluDQo+Pj4gW1JGQzU4ODkgPGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODg5Pl0ubw0KPj4+IA0KPj4+IA0KPj4+IFtTcmld IFBlciBteSBlYXJsaWVyIGNvbW1lbnQsIHRoZXJlIGlzIG5vIHN5c3RlbSBsZXZlbCB2aWV3IG9m IHRoZQ0KPj4+IG5ldHdvcmsgd2hlcmUgODAyLjExLU9DQiBsaW5rcyBhcmUgdXNlZC4gU28sIGlu IHRoZSBhYnNlbmNlIG9mIHN1Y2gNCj4+PiBkaXNjdXNzaW9uIFNvLCBJIGFtIG5vdCBzdXJlIHdo YXQgcGFydCBvZiBSRkM1ODg5IGlzIGFwcGxpY2FibGUgaGVyZS4NCj4+PiANCj4+VGhhdCdzIHRo ZSBvbmx5IFJGQyB0aGUgSUVURiBoYXMgYWJvdXQgdGhlIHN1Ym5ldCBzdHJ1Y3R1cmUgaW4gJ2Fk LWhvYycNCj4+bmV0d29ya3MsIGFuZCB0aGUgJ2FkLWhvYycgaXMgd2hhdCBPQ0IgaXMgbGlrZS4N Cj4+DQo+Pj4gRm9yIGV4YW1wbGUsIGxpbmstbG9jYWwgYWRkcmVzc2VzIG1heSBqdXN0IHdvcmsg ZmluZS4NCj4+DQo+PlllcywgYWRkZWQuDQo+Pg0KPj5bLi4uXQ0KPj4NCj4+PiBPdmVyYWxsLCB0 aGUgY2FwdHVyZWQgbWVzc2FnZSBpcyBpZGVudGljYWwgd2l0aCBhIGNhcHR1cmUgb2YgYW4gSVB2 Ng0KPj4+IHBhY2tldCBlbWl0dGVkIG9uIGEgODAyLjExYiBpbnRlcmZhY2UuICBUaGUgY29udGVu dHMgYXJlIHByZWNpc2VseQ0KPj4+IHNpbWlsYXIuDQo+Pj4gDQo+Pj4gDQo+Pj4gW1NyaV0gSSBz dWdnZXN0IG1vdmluZyB0aGlzIGRpc2N1c3Npb24gdW5kZXIgdGhlIHNlY3Rpb24NCj4+PiDCs0lt cGxlbWVudGF0aW9uIFN0YXR1c8KyLA0KPj4NCj4+QWdyZWVkLg0KPj4NCj4+PiB3aGljaCB3aWxs IGV2ZW50dWFsbHkgYmUgcmVtb3ZlZCBmcm9tIHRoZSBSRkMuDQo+Pg0KPj5CdXQgYXQgdGhlIHNh bWUgdGltZSBpdCBkZXBpY3RzIHRoaXMgdG9wb2xvZ3kgb2YNCj4+Um91dGVyLWNvbm5lY3RlZC10 by1Ib3N0LCB1c2luZyA4MDIuMTEtT0NCLiAgVGhpcyBpcyBzb21ldGhpbmcgdGhhdCB5b3UNCj4+ cmVxdWVzdGVkIGVhcmxpZXIgd2l0aCBTVEExLS0tLVNUQTIgd2l0aCBPQ0IgaW4gdGhlIG1pZGRs ZS4NCj4+DQo+PlNvIEkgc3VnZ2VzdCB0byBrZWVwIHRoaXMgc2VjdGlvbiBpbiBBcHBlbmRpeC4N Cj4+DQo+Pj4gVGhlcmUgaXMgbm90aGluZyBuZXcgaGVyZS4gVGhpcyBhcmUgZGV0YWlscyBvbiBl eHBlcmltZW50YXRpb24uIEJ1dCwNCj4+PiBpZiB5b3UgdGhpbmsgdGhlcmUgaXMgc29tZSB1c2Vm dWwgaW5mb3JtYXRpb24gc3VjaCBhcyBkaXNjdXNzaW9uIG9uDQo+Pj4gQ2FwdHVyZSBtb2RlIC4u ZXRjLCB5b3UgbWF5IHdhbnQgdG8gbW92ZSB0aGlzIGVudGlyZSBzZWN0aW9uIHRvDQo+Pj4gQXBw ZW5kaXguIEltcGxlbWVudG9ycyBtYXkgdXNlIHRoZXNlIHRvb2xzIGZvciB2ZXJpZmljYXRpb24u DQo+Pg0KPj5ZZXMuDQo+Pg0KPj5bLi4uXSA+DQo+PjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTA0I3NlY3QNCj4+aQ0KPj5v bi04Pi4NCj4+PiBJQU5BIENvbnNpZGVyYXRpb25zDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gW1Ny aV0gSSB0aG91Z2ggdGhlcmUgd2FzIG9uZSBJQU5BIHJlcXVlc3Qgb24gc29tZSBtdWx0aWNhc3Qg cmVsYXRlZD8NCj4+DQo+PmFkZGVkDQo+Pg0KPj5BbGV4DQo+DQoNCg== From nobody Sun Sep 10 21:25:37 2017 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 76D34132396 for ; Sun, 10 Sep 2017 21:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 w6o8KoECk_4W for ; Sun, 10 Sep 2017 21:25:33 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D3C132055 for ; Sun, 10 Sep 2017 21:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6379; q=dns/txt; s=iport; t=1505103933; x=1506313533; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wyzu5LJsU07FD/dh22hSlM1e0wm+pJ5CGxHhsZew9JA=; b=LIBcpPriTjuhhKE+FJjzsqwbJLW1aQrEKPHEZW+Av1m8lF56bEHLExla 7EGXuXwdMRMckaUYZ963LHxDz4Y7mDLpg62I+DCemrGsas2XE9jWqfxBW XtH6haGmmbAc+RBL+HwIxw5rnp42N1bc4/gFitV15h0S5CGxCrItT6EUJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CFAwCrD7ZZ/4kNJK1RChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNaZG4nB6Ajd4dDjX2CBAoYC4UbAoQLVwECAQEBAQECax0LhRk?= =?us-ascii?q?BAQQBAWwLEAIBCBguIQYLJQIEDgUbiX4DFRCvV4crDYN8AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGAWDK4ICgVCBY4JzNYJYgVgLESuFdAWgODwCh1mIAIR2ghOFZ4p?= =?us-ascii?q?3jFOFN4J0AhEZAYE4AVeBDXcVSocbdogogQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.42,375,1500940800"; d="scan'208";a="1606256" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Sep 2017 04:25:31 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8B4PVGi011594 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Sep 2017 04:25:31 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 10 Sep 2017 23:25:31 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Sun, 10 Sep 2017 23:25:31 -0500 From: "Sri Gundavelli (sgundave)" To: "its@ietf.org" CC: Alexandre Petrescu , =?windows-1254?Q?Fran=E7ois_Simon?= Thread-Topic: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt Thread-Index: AQHTH6nS3MdwWO6+I0K2nyn/HA8hRaKvC0OA Date: Mon, 11 Sep 2017 04:25:30 +0000 Message-ID: References: <007401d32028$a06b8ce0$e142a6a0$@gmail.com> <534037a7-9be7-925e-cc3f-9f803a2f3c52@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.54] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 04:25:35 -0000 Hi Alex/Simon, On 9/10/17, 5:35 PM, "Sri Gundavelli (sgundave)" wrote: > > >On 9/10/17, 6:59 AM, "its on behalf of Alexandre Petrescu" > wrote: > >> >> >>Le 28/08/2017 =E0 20:08, Fran=E7ois Simon a =E9crit : >>[...] >> >>> *[Fygs] Since 2010 the OCB is defined in IEEE Std 802.11p, IEEE Std >>> 802.11-2012, and IEEE 802.11-2016.* >> >>What's the reference to 2016? Can I just go with 'p' and with 2012? Or >>should I add a 3rd? [Sri] IMO, adding a reference to IEEE Std 802.11-2016 is sufficient; That document clearly states that its a Revision of 802.11-2012. >> >>[...]> RSU: Road Side Unit. A computer equipped with at least one >>IEEE >>> 802.11 interface operated in OCB mode. This definition applies to >>> this document. An RSU may be connected to the Internet, and may be >>> equipped with additional wired or wireless network interfaces >>>running >>> IP. An RSU MAY be an IP Router. >>>=20 >>>=20 >>> [Sri] RSU can be compared to an 802.11 access point; Or, WTP as defined >>> in CAPWAP specification, RFC5415. >>>=20 >>> *[Fygs] While I am not familiar with =B3WTP as defined in CAPWAP >>> specification, RFC5415=B2, I know that an RSU has no commonality with a= n >>> 802.11 AP.* >> >>Mr. Simon - an RSU does use an 802.11 interface run in OCB mode, and a >>WiFi Access Point also uses an 802.11 interface, so they do have a >>comonality. [Sri] I was earlier thinking RSU is more like an AP, but looking at the WAVE specs and based on Simon=92s comments, the communication mode appears to be peer to peer (as opposed to peer to infra communication) mode. For example, even when sending WSMP messages, the RSU is still an IPv6 peer?? But, this does not mean a 802-11-OCB node cannot be extended to communicate with an IPv6 peer reachable through an RSU node connected to a backhaul. IMO, that is a more interesting scenarios and truly will show the value for using IPv6 in this environment. We can talk about a RSU connecting to a router/backfaul and then talk about link prefixes etc and how a node can reach the backhaul network. In that sense equating RSU to an AP might make sense. May be the spec (or other spec) needs to identify different communication modes. >> >>[...]> *[Fygs] Here is a definition of OBU (FCC): =B3An On-Board Unit is = a >>DSRCS >>> transceiver that is normally mounted in or on a vehicle, or which in >>> some instances may be a portable unit. An OBU can be operational while >>>a=20 >>> vehicle or person is either mobile or stationary.=B2* >> >>That is why an OBU FCC talks about is different than the OBUs I play >>with (there are many "transceivers" in OBUs I work with - there are >>multiple 802.11-OCB transceivers, LTE transceivers, and more, in just >>one OBU). >> >>Some currently call it an "IoT Platform", a "Mobile Router", an "ITS >>Station", and more other terms. I am not sure we want to converge now. >> >>As such I will call it a computer with at least two IP interface, and at >>least one IP interface running in OCB mode. >> >>[...]> [Sri] A packet sent from a vehicle=B9s OBU is received by a single >>RSU, or >>> multiple RSU=B9s? How does the link-layer resolution happen? >>>=20 >>> *[Fygs] Assuming that:* >>>=20 >>> *a) ****If t**here are**single or**multiple RSU**s****in the >>> communication range and it is a**multicast**message**,**the single RSU >>> or**RSUs in the comm**.**range will receive it (eventually)**.**There >>>is=20 >>> no resolution at the link layer. >> >>But there is resolution at the IP layer: it is the IPv6 Neighbor >>Discovery protocol. >> >>> The RSU**(**s**)**will determine >>> their**=B3**interest**=B2 based on**the content of the message at the >>>higher=20 >>> layers (application);*** >> >>YEs too. >> >>But the interest is based on the MAC dst address, not the app layer. >>Apps talk to apps, MAC layers to MAC layers, net layers to net layers. [Sri] I agree. In the context of this document, what happens in the application layer may be less relevant here. The spec needs to explain how unicast, multicast communication work and based on addresses in L2 and L3 headers ONLY.=20 >> >>> *b) ****If there are single or multiple RSUs in the communication rand >>> and it is**unicast message, then the link-layer resolves by >>> the**destination**MAC address**.* >> >>I agree. It uses ND. >> >>[...] >> >>> The distinction between the two formats is given by the value of >>>the=20 >>> field "Type/Subtype". The value of the field "Type/Subtype" in the >>> 802.11 Data header is 0x0020. The value of the field >>>"Type/Subtype" >>> in the 802.11 QoS header is 0x0028. >>> The mapping between qos-related fields in the IPv6 header (e.g. >>> "Traffic Class", "Flow label") and fields in the "802.11 QoS Data >>> Header" (e.g. "QoS Control") are not specified in this document. >>> Guidance for a potential mapping is provided in >>>=20 >>> =20 >>>=20 >>>[https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref >>>- >>>I-D.ietf-tsvwg-ieee-802-11], >>> although it is not specific to OCB >>>=20 >>> mode. >>>=20 >>>=20 >>>=20 >>> [Sri] The applicability of the QoS mapping draft to 802.11-OCB needs >>> further investigation, IMO. >>>=20 >>> ***[Fygs] I am not familiar with QoS control of IPv6****. As for the >>> OCB MAC QoS it is somewhat involved.****It is based >>> on********transmission priority****of MAC frames. A higher priority >>> frame is intended to be transmitted ahead of lower priority >>> frames.****If a detail process is required, please, let me know and I >>> would provide the text.***** >> >>The QoS mapping needs to be worked on a separate document that should >>answer this: which MAC QoS field is mapped into which IPv6 header field. >> >>On this list a few participants expressed interest in the QoS work. >> >>IP QoS is a key solution to the distinctive safety-entertainment needs >>in vehicular communications. >> >>Alex >> >>_______________________________________________ >>its mailing list >>its@ietf.org >>https://www.ietf.org/mailman/listinfo/its > From nobody Mon Sep 11 02:26:35 2017 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 D6E0B13302B for ; Mon, 11 Sep 2017 02:26:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.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 wFMQaZOrP9-7 for ; Mon, 11 Sep 2017 02:26:30 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61610132F81 for ; Mon, 11 Sep 2017 02:26:30 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id a137so7050883wma.0 for ; Mon, 11 Sep 2017 02:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AMNEi3r5Rwxr6yc7kI/xfZhuoqf3WzV86uF8mV6cls0=; b=QSI9ll8bUcYF2ErSSqEW9l98rVoieaJi2riAziFqX+u0KOjgkgP8kEhjqSPAd4y6qX Y2d6FUe9NedSLjD8dghhAim5Ta5EsEtWUf3gC8WaxLUdSAamgYCfFwrklMAYyIxjp9l1 95WE//HBsLWpT95p0KMmhAuNovnm8bh0qSC8w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AMNEi3r5Rwxr6yc7kI/xfZhuoqf3WzV86uF8mV6cls0=; b=Ck9vleIm6png+1PD0OgYbc5iD9nqvDI+ThkhoA8BrvvVwW1SMtEZuklQshi+mKLgYA EVHIzcIgf6pnmYyOfgCAqsJWrLIENu0Go7k2XzBCshS3IvWJR+zoZG+wNyDeZkim6eXy IKpKOyIUEcZoI5oZxWgX+70io8mJ6ughdH0wEEorrildS7ErtbN1s9GQ5C6u3uQ5vhSr 4+mcLJJN04qBR+O9/Fz0eR9sCn9A4UKvWW3CbLFyyi5m2Qj/OgHkeRuyIOxSALOATxyn fbWRbdGXw4Ot55K7qA2g2GEhaQux++01zmvpmoHYxSJqIJR3iLXyvlAPw1ufQY0RCN1/ 0fjg== X-Gm-Message-State: AHPjjUib0wm+RldEHo2JfrVZDf77VpuEPngJf4e77ocwPHhjPNEscAOl +MEpZ9rPAo+iw+7WWdEqZmcF9p0xG1En X-Google-Smtp-Source: AOwi7QD5nVYj8K5ManuDPZhT15CLB3oGVKI9xwNqJqp8j1aSOgIwwiTzzbrtuZgX2oV8HhoO4lmxeN5IXND8kMhARsw= X-Received: by 10.28.147.199 with SMTP id v190mr6705546wmd.24.1505121988627; Mon, 11 Sep 2017 02:26:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.50.202 with HTTP; Mon, 11 Sep 2017 02:26:07 -0700 (PDT) In-Reply-To: References: <007401d32028$a06b8ce0$e142a6a0$@gmail.com> <534037a7-9be7-925e-cc3f-9f803a2f3c52@gmail.com> From: William Whyte Date: Mon, 11 Sep 2017 05:26:07 -0400 Message-ID: To: "Sri Gundavelli (sgundave)" Cc: "its@ietf.org" , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , Alexandre Petrescu Content-Type: multipart/alternative; boundary="001a1146ef0079da650558e685f3" Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 09:26:34 -0000 --001a1146ef0079da650558e685f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all -- just on this point: > [Sri] > IMO, adding a reference to IEEE Std 802.11-2016 is sufficient; That > document clearly states that its a Revision of 802.11-2012. 802.11-2016 is the only 802.11 that should be referenced; 802.11p hasn't existed as a separate document since 2012. Cheers, William On Mon, Sep 11, 2017 at 12:25 AM, Sri Gundavelli (sgundave) < sgundave@cisco.com> wrote: > Hi Alex/Simon, > > > On 9/10/17, 5:35 PM, "Sri Gundavelli (sgundave)" > wrote: > > > > > > >On 9/10/17, 6:59 AM, "its on behalf of Alexandre Petrescu" > > wrote: > > > >> > >> > >>Le 28/08/2017 =C3=A0 20:08, Fran=C3=A7ois Simon a =C3=A9crit : > >>[...] > >> > >>> *[Fygs] Since 2010 the OCB is defined in IEEE Std 802.11p, IEEE Std > >>> 802.11-2012, and IEEE 802.11-2016.* > >> > >>What's the reference to 2016? Can I just go with 'p' and with 2012? O= r > >>should I add a 3rd? > > > [Sri] > IMO, adding a reference to IEEE Std 802.11-2016 is sufficient; That > document clearly states that its a Revision of 802.11-2012. > > > > > > > >> > >>[...]> RSU: Road Side Unit. A computer equipped with at least one > >>IEEE > >>> 802.11 interface operated in OCB mode. This definition applies t= o > >>> this document. An RSU may be connected to the Internet, and may = be > >>> equipped with additional wired or wireless network interfaces > >>>running > >>> IP. An RSU MAY be an IP Router. > >>> > >>> > >>> [Sri] RSU can be compared to an 802.11 access point; Or, WTP as defin= ed > >>> in CAPWAP specification, RFC5415. > >>> > >>> *[Fygs] While I am not familiar with =C2=B3WTP as defined in CAPWAP > >>> specification, RFC5415=C2=B2, I know that an RSU has no commonality w= ith an > >>> 802.11 AP.* > >> > >>Mr. Simon - an RSU does use an 802.11 interface run in OCB mode, and a > >>WiFi Access Point also uses an 802.11 interface, so they do have a > >>comonality. > > > > [Sri] > I was earlier thinking RSU is more like an AP, but looking at the WAVE > specs and based on Simon=E2=80=99s comments, the communication mode appea= rs to be > peer to peer (as opposed to peer to infra communication) mode. For > example, even when sending WSMP messages, the RSU is still an IPv6 peer?? > > But, this does not mean a 802-11-OCB node cannot be extended to > communicate with an IPv6 peer reachable through an RSU node connected to = a > backhaul. IMO, that is a more interesting scenarios and truly will show > the value for using IPv6 in this environment. We can talk about a RSU > connecting to a router/backfaul and then talk about link prefixes etc and > how a node can reach the backhaul network. In that sense equating RSU to > an AP might make sense. May be the spec (or other spec) needs to identif= y > different communication modes. > > > > > > > > > >> > >>[...]> *[Fygs] Here is a definition of OBU (FCC): =C2=B3An On-Board Uni= t is a > >>DSRCS > >>> transceiver that is normally mounted in or on a vehicle, or which in > >>> some instances may be a portable unit. An OBU can be operational whil= e > >>>a > >>> vehicle or person is either mobile or stationary.=C2=B2* > >> > >>That is why an OBU FCC talks about is different than the OBUs I play > >>with (there are many "transceivers" in OBUs I work with - there are > >>multiple 802.11-OCB transceivers, LTE transceivers, and more, in just > >>one OBU). > >> > >>Some currently call it an "IoT Platform", a "Mobile Router", an "ITS > >>Station", and more other terms. I am not sure we want to converge now. > >> > >>As such I will call it a computer with at least two IP interface, and a= t > >>least one IP interface running in OCB mode. > >> > >>[...]> [Sri] A packet sent from a vehicle=C2=B9s OBU is received by a s= ingle > >>RSU, or > >>> multiple RSU=C2=B9s? How does the link-layer resolution happen? > >>> > >>> *[Fygs] Assuming that:* > >>> > >>> *a) ****If t**here are**single or**multiple RSU**s****in the > >>> communication range and it is a**multicast**message**,**the single RS= U > >>> or**RSUs in the comm**.**range will receive it (eventually)**.**There > >>>is > >>> no resolution at the link layer. > >> > >>But there is resolution at the IP layer: it is the IPv6 Neighbor > >>Discovery protocol. > >> > >>> The RSU**(**s**)**will determine > >>> their**=C2=B3**interest**=C2=B2 based on**the content of the message = at the > >>>higher > >>> layers (application);*** > >> > >>YEs too. > >> > >>But the interest is based on the MAC dst address, not the app layer. > >>Apps talk to apps, MAC layers to MAC layers, net layers to net layers. > > > > [Sri] I agree. In the context of this document, what happens in the > application layer may be less relevant here. The spec needs to explain ho= w > unicast, multicast communication work and based on addresses in L2 and L= 3 > headers ONLY. > > > > > > > > >> > >>> *b) ****If there are single or multiple RSUs in the communication ran= d > >>> and it is**unicast message, then the link-layer resolves by > >>> the**destination**MAC address**.* > >> > >>I agree. It uses ND. > >> > >>[...] > >> > >>> The distinction between the two formats is given by the value of > >>>the > >>> field "Type/Subtype". The value of the field "Type/Subtype" in t= he > >>> 802.11 Data header is 0x0020. The value of the field > >>>"Type/Subtype" > >>> in the 802.11 QoS header is 0x0028. > >>> The mapping between qos-related fields in the IPv6 header (e.g. > >>> "Traffic Class", "Flow label") and fields in the "802.11 QoS Data > >>> Header" (e.g. "QoS Control") are not specified in this document. > >>> Guidance for a potential mapping is provided in > >>> > >>> > >>> > >>>[https://tools.ietf.org/html/draft-ietf-ipwave-ipv6- > over-80211ocb-04#ref > >>>- > >>>I-D.ietf-tsvwg-ieee-802-11], > >>> although it is not specific to OCB > >>> > >>> mode. > >>> > >>> > >>> > >>> [Sri] The applicability of the QoS mapping draft to 802.11-OCB needs > >>> further investigation, IMO. > >>> > >>> ***[Fygs] I am not familiar with QoS control of IPv6****. As for the > >>> OCB MAC QoS it is somewhat involved.****It is based > >>> on********transmission priority****of MAC frames. A higher priority > >>> frame is intended to be transmitted ahead of lower priority > >>> frames.****If a detail process is required, please, let me know and I > >>> would provide the text.***** > >> > >>The QoS mapping needs to be worked on a separate document that should > >>answer this: which MAC QoS field is mapped into which IPv6 header field= . > >> > >>On this list a few participants expressed interest in the QoS work. > >> > >>IP QoS is a key solution to the distinctive safety-entertainment needs > >>in vehicular communications. > >> > >>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 > --=20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --001a1146ef0079da650558e685f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all -- just on this point:

> [Sri]
> IMO, adding a reference to IEEE Std 802.= 11-2016 is sufficient; That
> document clearly states that its a Revision of = 802.11-2012.

8= 02.11-2016 is the only 802.11 that should be referenced; 802.11p hasn't= existed as a separate document since 2012.

C= heers,

<= div>William



On Mon, Sep 11, 2017 at 12:25 AM, Sri Gundavelli (sgundave) <sgun= dave@cisco.com> wrote:
Hi A= lex/Simon,


On 9/10/17, 5:35 PM, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
wrote:

>
>
>On 9/10/17, 6:59 AM, "its on behalf of Alexandre Petrescu&q= uot;
><its-bounce= s@ietf.org on behalf of alexandre.petrescu@gmail.com> wrote:
>
>>
>>
>>Le 28/08/2017 =C3=A0 20:08, Fran=C3=A7ois Simon a =C3=A9crit :
>>[...]
>>
>>> *[Fygs] Since 2010 the OCB is defined in IEEE Std 802.11p, IEE= E Std
>>> 802.11-2012, and IEEE 802.11-2016.*
>>
>>What's the reference to 2016?=C2=A0 Can I just go with 'p&#= 39; and with 2012?=C2=A0 Or
>>should I add a 3rd?


[Sri]
IMO, adding a reference to IEEE Std 802.11-2016 is sufficient; That
document clearly states that its a Revision of 802.11-2012.






>>
>>[...]>=C2=A0 =C2=A0 =C2=A0RSU: Road Side Unit.=C2=A0 A computer = equipped with at least one
>>IEEE
>>>=C2=A0 =C2=A0 =C2=A0802.11 interface operated in OCB mode.=C2= =A0 This definition applies to
>>>=C2=A0 =C2=A0 =C2=A0this document.=C2=A0 An RSU may be connecte= d to the Internet, and may be
>>>=C2=A0 =C2=A0 =C2=A0equipped with additional wired or wireless = network interfaces
>>>running
>>>=C2=A0 =C2=A0 =C2=A0IP.=C2=A0 An RSU MAY be an IP Router.
>>>
>>>
>>> [Sri] RSU can be compared to an 802.11 access point; Or, WTP a= s defined
>>> in CAPWAP specification, RFC5415.
>>>
>>> *[Fygs] While I am not familiar with =C2=B3WTP as defined in C= APWAP
>>> specification, RFC5415=C2=B2, I know that an RSU has no common= ality with an
>>> 802.11 AP.*
>>
>>Mr. Simon - an RSU does use an 802.11 interface run in OCB mode, an= d a
>>WiFi Access Point also uses an 802.11 interface, so they do have a<= br> >>comonality.



[Sri]
I was earlier thinking RSU is more like an AP, but looking at the WAVE
specs and based on Simon=E2=80=99s comments, the communication mode appears= to be
peer to peer (as opposed to peer to infra communication) mode. For
example, even when sending WSMP messages, the RSU is still an IPv6 peer??
But, this does not mean a 802-11-OCB node cannot be extended to
communicate with an IPv6 peer reachable through an RSU node connected to a<= br> backhaul. IMO, that is a more interesting scenarios and truly will show
the value for using IPv6 in this environment. We can talk about a RSU
connecting to a router/backfaul and then talk about link prefixes etc and how a node can reach the backhaul network. In that sense equating RSU to an AP might make sense. May be the spec=C2=A0 (or other spec) needs to iden= tify
different communication modes.








>>
>>[...]> *[Fygs] Here is a definition of OBU (FCC): =C2=B3An On-Bo= ard Unit is a
>>DSRCS
>>> transceiver that is normally mounted in or on a vehicle, or wh= ich in
>>> some instances may be a portable unit. An OBU can be operation= al while
>>>a
>>> vehicle or person is either mobile or stationary.=C2=B2*
>>
>>That is why an OBU FCC talks about is different than the OBUs I pla= y
>>with (there are many "transceivers" in OBUs I work with -= there are
>>multiple 802.11-OCB transceivers, LTE transceivers, and more, in ju= st
>>one OBU).
>>
>>Some currently call it an "IoT Platform", a "Mobile = Router", an "ITS
>>Station", and more other terms.=C2=A0 I am not sure we want to= converge now.
>>
>>As such I will call it a computer with at least two IP interface, a= nd at
>>least one IP interface running in OCB mode.
>>
>>[...]> [Sri] A packet sent from a vehicle=C2=B9s OBU is received= by a single
>>RSU, or
>>> multiple RSU=C2=B9s? How does the link-layer resolution happen= ?
>>>
>>> *[Fygs] Assuming that:*
>>>
>>> *a) ****If t**here are**single or**multiple RSU**s****in the >>> communication range and it is a**multicast**message**,**the si= ngle RSU
>>> or**RSUs in the comm**.**range will receive it (eventually)**.= **There
>>>is
>>> no resolution at the link layer.
>>
>>But there is resolution at the IP layer: it is the IPv6 Neighbor >>Discovery protocol.
>>
>>> The RSU**(**s**)**will determine
>>> their**=C2=B3**interest**=C2=B2 based on**the content of the m= essage at the
>>>higher
>>> layers (application);***
>>
>>YEs too.
>>
>>But the interest is based on the MAC dst address, not the app layer= .
>>Apps talk to apps, MAC layers to MAC layers, net layers to net laye= rs.



[Sri] I agree. In the context of this document, what happens in= the
application layer may be less relevant here. The spec needs to explain how<= br> =C2=A0unicast, multicast communication work and based on addresses in L2 an= d L3
headers ONLY.







>>
>>> *b) ****If there are single or multiple RSUs in the communicat= ion rand
>>> and it is**unicast message, then the link-layer resolves by >>> the**destination**MAC address**.*
>>
>>I agree.=C2=A0 It uses ND.
>>
>>[...]
>>
>>>=C2=A0 =C2=A0 =C2=A0The distinction between the two formats is = given by the value of
>>>the
>>>=C2=A0 =C2=A0 =C2=A0field "Type/Subtype".=C2=A0 The v= alue of the field "Type/Subtype" in the
>>>=C2=A0 =C2=A0 =C2=A0802.11 Data header is 0x0020.=C2=A0 The val= ue of the field
>>>"Type/Subtype"
>>>=C2=A0 =C2=A0 =C2=A0in the 802.11 QoS header is 0x0028.
>>>=C2=A0 =C2=A0 =C2=A0The mapping between qos-related fields in t= he IPv6 header (e.g.
>>>=C2=A0 =C2=A0 =C2=A0"Traffic Class", "Flow label= ") and fields in the "802.11 QoS Data
>>>=C2=A0 =C2=A0 =C2=A0Header" (e.g.=C2=A0 "QoS Control&= quot;) are not specified in this document.
>>>=C2=A0 =C2=A0 =C2=A0Guidance for a potential mapping is provide= d in
>>>
>>>
>>>
>>>[https://tools.ie= tf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref
>>>-
>>>I-D.ietf-tsvwg-ieee-802-11],
>>> although it is not specific to OCB
>>>
>>>=C2=A0 =C2=A0 =C2=A0mode.
>>>
>>>
>>>
>>> [Sri] The applicability of the QoS mapping draft to 802.11-OCB= needs
>>> further investigation, IMO.
>>>
>>> ***[Fygs] I am not familiar with QoS control of IPv6****.=C2= =A0 As for the
>>> OCB MAC QoS it is somewhat involved.****It is based
>>> on********transmission priority****of MAC frames.=C2=A0 A high= er priority
>>> frame is intended to be transmitted ahead of lower priority >>> frames.****If a detail process is required, please, let me kno= w and I
>>> would provide the text.*****
>>
>>The QoS mapping needs to be worked on a separate document that shou= ld
>>answer this: which MAC QoS field is mapped into which IPv6 header f= ield.
>>
>>On this list a few participants expressed interest in the QoS work.=
>>
>>IP QoS is a key solution to the distinctive safety-entertainment ne= eds
>>in vehicular communications.
>>
>>Alex
>>
>>_______________________________________________
>>its mailing list
>>its@ietf.org
>>https://www.ietf.org/mailman/listinfo/its<= br> >

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



--
=


PLEASE UPDATE YOUR ADDRESS BOOKS WIT= H MY NEW ADDRESS: wwhyte@onboardsecurity.com
--001a1146ef0079da650558e685f3-- From nobody Mon Sep 11 06:04:15 2017 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 08752133078 for ; Mon, 11 Sep 2017 06:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 p290pTS_tB01 for ; Mon, 11 Sep 2017 06:04:10 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 BA7C5132199 for ; Mon, 11 Sep 2017 06:04:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8BD44W0014843; Mon, 11 Sep 2017 15:04:04 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A9D4020A5CC; Mon, 11 Sep 2017 15:04:04 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 99ADA20A548; Mon, 11 Sep 2017 15:04:04 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8BD448r013623; Mon, 11 Sep 2017 15:04:04 +0200 To: William Whyte , "Sri Gundavelli (sgundave)" Cc: "its@ietf.org" , =?UTF-8?Q?Fran=c3=a7ois_Simon?= References: <007401d32028$a06b8ce0$e142a6a0$@gmail.com> <534037a7-9be7-925e-cc3f-9f803a2f3c52@gmail.com> From: Alexandre Petrescu Message-ID: <945b876a-cd68-2ed6-3f39-5ca23087e80c@gmail.com> Date: Mon, 11 Sep 2017 15:04:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 13:04:14 -0000 Is the 802.11-2016 version more of an "ammendment" of -2012? or is it self-contained just like -2012 was. That 'p' didnt exist as a separate doc since 2012: I agree. Alex Le 11/09/2017 à 11:26, William Whyte a écrit : > Hi all -- just on this point: > >> [Sri] >> IMO, adding a reference to IEEE Std 802.11-2016 is sufficient; That >> document clearly states that its a Revision of 802.11-2012. > > 802.11-2016 is the only 802.11 that should be referenced; 802.11p hasn't > existed as a separate document since 2012. > > Cheers, > > William > > > > On Mon, Sep 11, 2017 at 12:25 AM, Sri Gundavelli (sgundave) > > wrote: > > Hi Alex/Simon, > > > On 9/10/17, 5:35 PM, "Sri Gundavelli (sgundave)" > > wrote: > > > > > > >On 9/10/17, 6:59 AM, "its on behalf of Alexandre Petrescu" > > on behalf of > alexandre.petrescu@gmail.com > > wrote: > > > >> > >> > >>Le 28/08/2017 à 20:08, François Simon a écrit : > >>[...] > >> > >>> *[Fygs] Since 2010 the OCB is defined in IEEE Std 802.11p, IEEE Std > >>> 802.11-2012, and IEEE 802.11-2016.* > >> > >>What's the reference to 2016?  Can I just go with 'p' and with 2012?  Or > >>should I add a 3rd? > > > [Sri] > IMO, adding a reference to IEEE Std 802.11-2016 is sufficient; That > document clearly states that its a Revision of 802.11-2012. > > > > > > > >> > >>[...]>     RSU: Road Side Unit.  A computer equipped with at least one > >>IEEE > >>>     802.11 interface operated in OCB mode.  This definition applies to > >>>     this document.  An RSU may be connected to the Internet, and may be > >>>     equipped with additional wired or wireless network interfaces > >>>running > >>>     IP.  An RSU MAY be an IP Router. > >>> > >>> > >>> [Sri] RSU can be compared to an 802.11 access point; Or, WTP as defined > >>> in CAPWAP specification, RFC5415. > >>> > >>> *[Fygs] While I am not familiar with ³WTP as defined in CAPWAP > >>> specification, RFC5415², I know that an RSU has no commonality with an > >>> 802.11 AP.* > >> > >>Mr. Simon - an RSU does use an 802.11 interface run in OCB mode, and a > >>WiFi Access Point also uses an 802.11 interface, so they do have a > >>comonality. > > > > [Sri] > I was earlier thinking RSU is more like an AP, but looking at the WAVE > specs and based on Simon’s comments, the communication mode appears > to be > peer to peer (as opposed to peer to infra communication) mode. For > example, even when sending WSMP messages, the RSU is still an IPv6 > peer?? > > But, this does not mean a 802-11-OCB node cannot be extended to > communicate with an IPv6 peer reachable through an RSU node > connected to a > backhaul. IMO, that is a more interesting scenarios and truly will show > the value for using IPv6 in this environment. We can talk about a RSU > connecting to a router/backfaul and then talk about link prefixes > etc and > how a node can reach the backhaul network. In that sense equating RSU to > an AP might make sense. May be the spec  (or other spec) needs to > identify > different communication modes. > > > > > > > > > >> > >>[...]> *[Fygs] Here is a definition of OBU (FCC): ³An On-Board > Unit is a > >>DSRCS > >>> transceiver that is normally mounted in or on a vehicle, or > which in > >>> some instances may be a portable unit. An OBU can be > operational while > >>>a > >>> vehicle or person is either mobile or stationary.²* > >> > >>That is why an OBU FCC talks about is different than the OBUs I play > >>with (there are many "transceivers" in OBUs I work with - there are > >>multiple 802.11-OCB transceivers, LTE transceivers, and more, in just > >>one OBU). > >> > >>Some currently call it an "IoT Platform", a "Mobile Router", an "ITS > >>Station", and more other terms.  I am not sure we want to > converge now. > >> > >>As such I will call it a computer with at least two IP interface, > and at > >>least one IP interface running in OCB mode. > >> > >>[...]> [Sri] A packet sent from a vehicle¹s OBU is received by a > single > >>RSU, or > >>> multiple RSU¹s? How does the link-layer resolution happen? > >>> > >>> *[Fygs] Assuming that:* > >>> > >>> *a) ****If t**here are**single or**multiple RSU**s****in the > >>> communication range and it is a**multicast**message**,**the > single RSU > >>> or**RSUs in the comm**.**range will receive it > (eventually)**.**There > >>>is > >>> no resolution at the link layer. > >> > >>But there is resolution at the IP layer: it is the IPv6 Neighbor > >>Discovery protocol. > >> > >>> The RSU**(**s**)**will determine > >>> their**³**interest**² based on**the content of the message at the > >>>higher > >>> layers (application);*** > >> > >>YEs too. > >> > >>But the interest is based on the MAC dst address, not the app layer. > >>Apps talk to apps, MAC layers to MAC layers, net layers to net > layers. > > > > [Sri] I agree. In the context of this document, what happens in the > application layer may be less relevant here. The spec needs to > explain how >  unicast, multicast communication work and based on addresses in L2 > and L3 > headers ONLY. > > > > > > > > >> > >>> *b) ****If there are single or multiple RSUs in the > communication rand > >>> and it is**unicast message, then the link-layer resolves by > >>> the**destination**MAC address**.* > >> > >>I agree.  It uses ND. > >> > >>[...] > >> > >>>     The distinction between the two formats is given by the > value of > >>>the > >>>     field "Type/Subtype".  The value of the field > "Type/Subtype" in the > >>>     802.11 Data header is 0x0020.  The value of the field > >>>"Type/Subtype" > >>>     in the 802.11 QoS header is 0x0028. > >>>     The mapping between qos-related fields in the IPv6 header (e.g. > >>>     "Traffic Class", "Flow label") and fields in the "802.11 > QoS Data > >>>     Header" (e.g.  "QoS Control") are not specified in this > document. > >>>     Guidance for a potential mapping is provided in > >>> > >>> > >>> > >>>[https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref > >>>- > >>>I-D.ietf-tsvwg-ieee-802-11], > >>> although it is not specific to OCB > >>> > >>>     mode. > >>> > >>> > >>> > >>> [Sri] The applicability of the QoS mapping draft to 802.11-OCB > needs > >>> further investigation, IMO. > >>> > >>> ***[Fygs] I am not familiar with QoS control of IPv6****.  As > for the > >>> OCB MAC QoS it is somewhat involved.****It is based > >>> on********transmission priority****of MAC frames.  A higher > priority > >>> frame is intended to be transmitted ahead of lower priority > >>> frames.****If a detail process is required, please, let me know > and I > >>> would provide the text.***** > >> > >>The QoS mapping needs to be worked on a separate document that should > >>answer this: which MAC QoS field is mapped into which IPv6 header > field. > >> > >>On this list a few participants expressed interest in the QoS work. > >> > >>IP QoS is a key solution to the distinctive safety-entertainment > needs > >>in vehicular communications. > >> > >>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 > > > > > > -- > > > PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: > wwhyte@onboardsecurity.com From nobody Mon Sep 11 06:08:12 2017 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 14EDA132199 for ; Mon, 11 Sep 2017 06:08:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.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 66WjL5Z9yc3S for ; Mon, 11 Sep 2017 06:08:02 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 1496D133077 for ; Mon, 11 Sep 2017 06:08:01 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id f199so39309419wme.0 for ; Mon, 11 Sep 2017 06:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TLr6nKg+ea2cSfQy4kFNEaYBQzlax0URIV9uNr2XTjo=; b=cdEv6f7n7rHaRiJjLlVnk3QTXqRYJ6LEfDjqGjNRn1NHm7nlBorqkfXMDCXy0HZzts x0meUn/huP5376MSgzRb0cfUAVAYTTvKZ5ueI/daGK2tnyLx6G5YlLhQfHLpIIrwVegv pV+bzzT0MLHrjDVqwTy/iXlq/yYpKT8QgMpEM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TLr6nKg+ea2cSfQy4kFNEaYBQzlax0URIV9uNr2XTjo=; b=kHuvsFTX3bJkFoqBil0oDhFYsw7RZycEYGgThc4aqSxwEPbFQWEXfTNhL1Vld36vp5 L39nhIwRUtwdO3z5XWFzLPy67YLx3U6gAD2QxcCvEwEBJoCEwJ5c7oIv1vz+ihg0Cvj8 VhyEdCtN4bpJQEdDQsgvL6vmPaHyPWlT/nJuyRgSHuirVu6/UWdwIlN19CNU3cNNuWoa qEA6dbE1UCjFh3iOeFjbf2OIAKmwx7hXP88h/EjNfruyRHpmKOUyfpWqKPkiNukTL+hd ck56D10wS6XPZRtqflHR0fX4eLyPrZl3Bsc5R+lwHtKUvczkS5r+DXkBGK26CeVZocem 1pcQ== X-Gm-Message-State: AHPjjUit7ZA/aDx9hEqscs++BjgmiyaISo6KjgsOUY/LYfxLcSzcyxY+ mPfaOP/zzeMyyJIHYs5zLmEKmgmKCfU7BQDI1Uq2jw== X-Google-Smtp-Source: AOwi7QAWoiq+qkxyCrcU+bJcuheZVmpOIKJZwXg9WSdHP4BY3loYLG9TKMaQAYI5nIyyTLkcyb8aZuglcbz+t6h3xZ8= X-Received: by 10.28.39.71 with SMTP id n68mr9028612wmn.114.1505135280070; Mon, 11 Sep 2017 06:08:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.50.202 with HTTP; Mon, 11 Sep 2017 06:07:38 -0700 (PDT) In-Reply-To: <945b876a-cd68-2ed6-3f39-5ca23087e80c@gmail.com> References: <007401d32028$a06b8ce0$e142a6a0$@gmail.com> <534037a7-9be7-925e-cc3f-9f803a2f3c52@gmail.com> <945b876a-cd68-2ed6-3f39-5ca23087e80c@gmail.com> From: William Whyte Date: Mon, 11 Sep 2017 09:07:38 -0400 Message-ID: To: Alexandre Petrescu Cc: "Sri Gundavelli (sgundave)" , "its@ietf.org" , =?UTF-8?Q?Fran=C3=A7ois_Simon?= Content-Type: multipart/alternative; boundary="001a114e36f8b53b960558e99db8" Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 13:08:10 -0000 --001a114e36f8b53b960558e99db8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's an updated document, containing all the original text of 802.11-2012 plus any amendments, corrections and additional material generated since then. It supersedes 802.11-2012. Cheers, William On Mon, Sep 11, 2017 at 9:04 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Is the 802.11-2016 version more of an "ammendment" of -2012? or is it > self-contained just like -2012 was. > > That 'p' didnt exist as a separate doc since 2012: I agree. > > Alex > > Le 11/09/2017 =C3=A0 11:26, William Whyte a =C3=A9crit : > >> Hi all -- just on this point: >> >> [Sri] >>> IMO, adding a reference to IEEE Std 802.11-2016 is sufficient; That >>> document clearly states that its a Revision of 802.11-2012. >>> >> >> 802.11-2016 is the only 802.11 that should be referenced; 802.11p hasn't >> existed as a separate document since 2012. >> >> Cheers, >> >> William >> >> >> >> On Mon, Sep 11, 2017 at 12:25 AM, Sri Gundavelli (sgundave) < >> sgundave@cisco.com > wrote: >> >> Hi Alex/Simon, >> >> >> On 9/10/17, 5:35 PM, "Sri Gundavelli (sgundave)" > > >> wrote: >> >> > >> > >> >On 9/10/17, 6:59 AM, "its on behalf of Alexandre Petrescu" >> > on behalf of >> alexandre.petrescu@gmail.com > >> >> wrote: >> > >> >> >> >> >> >>Le 28/08/2017 =C3=A0 20:08, Fran=C3=A7ois Simon a =C3=A9crit : >> >>[...] >> >> >> >>> *[Fygs] Since 2010 the OCB is defined in IEEE Std 802.11p, IEEE >> Std >> >>> 802.11-2012, and IEEE 802.11-2016.* >> >> >> >>What's the reference to 2016? Can I just go with 'p' and with >> 2012? Or >> >>should I add a 3rd? >> >> >> [Sri] >> IMO, adding a reference to IEEE Std 802.11-2016 is sufficient; That >> document clearly states that its a Revision of 802.11-2012. >> >> >> >> >> >> >> >> >> >>[...]> RSU: Road Side Unit. A computer equipped with at least >> one >> >>IEEE >> >>> 802.11 interface operated in OCB mode. This definition >> applies to >> >>> this document. An RSU may be connected to the Internet, and >> may be >> >>> equipped with additional wired or wireless network interface= s >> >>>running >> >>> IP. An RSU MAY be an IP Router. >> >>> >> >>> >> >>> [Sri] RSU can be compared to an 802.11 access point; Or, WTP as >> defined >> >>> in CAPWAP specification, RFC5415. >> >>> >> >>> *[Fygs] While I am not familiar with =C2=B3WTP as defined in CAP= WAP >> >>> specification, RFC5415=C2=B2, I know that an RSU has no commonal= ity >> with an >> >>> 802.11 AP.* >> >> >> >>Mr. Simon - an RSU does use an 802.11 interface run in OCB mode, >> and a >> >>WiFi Access Point also uses an 802.11 interface, so they do have a >> >>comonality. >> >> >> >> [Sri] >> I was earlier thinking RSU is more like an AP, but looking at the WA= VE >> specs and based on Simon=E2=80=99s comments, the communication mode = appears >> to be >> peer to peer (as opposed to peer to infra communication) mode. For >> example, even when sending WSMP messages, the RSU is still an IPv6 >> peer?? >> >> But, this does not mean a 802-11-OCB node cannot be extended to >> communicate with an IPv6 peer reachable through an RSU node >> connected to a >> backhaul. IMO, that is a more interesting scenarios and truly will >> show >> the value for using IPv6 in this environment. We can talk about a RS= U >> connecting to a router/backfaul and then talk about link prefixes >> etc and >> how a node can reach the backhaul network. In that sense equating RS= U >> to >> an AP might make sense. May be the spec (or other spec) needs to >> identify >> different communication modes. >> >> >> >> >> >> >> >> >> >> >> >>[...]> *[Fygs] Here is a definition of OBU (FCC): =C2=B3An On-Boa= rd >> Unit is a >> >>DSRCS >> >>> transceiver that is normally mounted in or on a vehicle, or >> which in >> >>> some instances may be a portable unit. An OBU can be >> operational while >> >>>a >> >>> vehicle or person is either mobile or stationary.=C2=B2* >> >> >> >>That is why an OBU FCC talks about is different than the OBUs I >> play >> >>with (there are many "transceivers" in OBUs I work with - there a= re >> >>multiple 802.11-OCB transceivers, LTE transceivers, and more, in >> just >> >>one OBU). >> >> >> >>Some currently call it an "IoT Platform", a "Mobile Router", an >> "ITS >> >>Station", and more other terms. I am not sure we want to >> converge now. >> >> >> >>As such I will call it a computer with at least two IP interface, >> and at >> >>least one IP interface running in OCB mode. >> >> >> >>[...]> [Sri] A packet sent from a vehicle=C2=B9s OBU is received = by a >> single >> >>RSU, or >> >>> multiple RSU=C2=B9s? How does the link-layer resolution happen? >> >>> >> >>> *[Fygs] Assuming that:* >> >>> >> >>> *a) ****If t**here are**single or**multiple RSU**s****in the >> >>> communication range and it is a**multicast**message**,**the >> single RSU >> >>> or**RSUs in the comm**.**range will receive it >> (eventually)**.**There >> >>>is >> >>> no resolution at the link layer. >> >> >> >>But there is resolution at the IP layer: it is the IPv6 Neighbor >> >>Discovery protocol. >> >> >> >>> The RSU**(**s**)**will determine >> >>> their**=C2=B3**interest**=C2=B2 based on**the content of the me= ssage at the >> >>>higher >> >>> layers (application);*** >> >> >> >>YEs too. >> >> >> >>But the interest is based on the MAC dst address, not the app >> layer. >> >>Apps talk to apps, MAC layers to MAC layers, net layers to net >> layers. >> >> >> >> [Sri] I agree. In the context of this document, what happens in the >> application layer may be less relevant here. The spec needs to >> explain how >> unicast, multicast communication work and based on addresses in L2 >> and L3 >> headers ONLY. >> >> >> >> >> >> >> >> >> >> >>> *b) ****If there are single or multiple RSUs in the >> communication rand >> >>> and it is**unicast message, then the link-layer resolves by >> >>> the**destination**MAC address**.* >> >> >> >>I agree. It uses ND. >> >> >> >>[...] >> >> >> >>> The distinction between the two formats is given by the >> value of >> >>>the >> >>> field "Type/Subtype". The value of the field >> "Type/Subtype" in the >> >>> 802.11 Data header is 0x0020. The value of the field >> >>>"Type/Subtype" >> >>> in the 802.11 QoS header is 0x0028. >> >>> The mapping between qos-related fields in the IPv6 header >> (e.g. >> >>> "Traffic Class", "Flow label") and fields in the "802.11 >> QoS Data >> >>> Header" (e.g. "QoS Control") are not specified in this >> document. >> >>> Guidance for a potential mapping is provided in >> >>> >> >>> >> >>> >> >>>[https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over >> -80211ocb-04#ref > raft-ietf-ipwave-ipv6-over-80211ocb-04#ref> >> >> >>>- >> >>>I-D.ietf-tsvwg-ieee-802-11], >> >>> although it is not specific to OCB >> >>> >> >>> mode. >> >>> >> >>> >> >>> >> >>> [Sri] The applicability of the QoS mapping draft to 802.11-OCB >> needs >> >>> further investigation, IMO. >> >>> >> >>> ***[Fygs] I am not familiar with QoS control of IPv6****. As >> for the >> >>> OCB MAC QoS it is somewhat involved.****It is based >> >>> on********transmission priority****of MAC frames. A higher >> priority >> >>> frame is intended to be transmitted ahead of lower priority >> >>> frames.****If a detail process is required, please, let me know >> and I >> >>> would provide the text.***** >> >> >> >>The QoS mapping needs to be worked on a separate document that >> should >> >>answer this: which MAC QoS field is mapped into which IPv6 header >> field. >> >> >> >>On this list a few participants expressed interest in the QoS wor= k. >> >> >> >>IP QoS is a key solution to the distinctive safety-entertainment >> needs >> >>in vehicular communications. >> >> >> >>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 >> >> >> >> >> >> -- >> >> >> PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: >> wwhyte@onboardsecurity.com >> > --=20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --001a114e36f8b53b960558e99db8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's an updated document, containing all the original = text of 802.11-2012 plus any amendments, corrections and additional materia= l generated since then. It supersedes 802.11-2012.

Cheer= s,

William
<= br>
On Mon, Sep 11, 2017 at 9:04 AM, Alexandre Pe= trescu <alexandre.petrescu@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Is the 802.11-2016 version more of an "a= mmendment" of -2012? or is it self-contained just like -2012 was.

That 'p' didnt exist as a separate doc since 2012: I agree.

Alex

Le 11/09/2017 =C3=A0 11:26, William Whyte a =C3=A9crit=C2=A0:
Hi all -- just on this point:

[Sri]
IMO, adding a reference to IEEE Std 802.11-2016 is sufficient; That
document clearly states that its a Revision of 802.11-2012.

802.11-2016 is the only 802.11 that should be referenced; 802.11p hasn'= t existed as a separate document since 2012.

Cheers,

William



 On Mon, Sep 11, 2017 at 12:25 AM, Sri Gundavelli (sgundave) <sgundave@cisco.com <mai= lto:sgundave@cisco.= com>> wrote:

=C2=A0 =C2=A0 Hi Alex/Simon,


=C2=A0 =C2=A0 On 9/10/17, 5:35 PM, "Sri Gundavelli (sgundave)" &l= t;sgundave@cisco.co= m
 =C2=A0 =C2=A0 <mailto:sgundave@cisco.com>>
=C2=A0 =C2=A0 wrote:

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0>On 9/10/17, 6:59 AM, "its on behalf of Alexand= re Petrescu"
 =C2=A0 =C2=A0 ><its-bounces@ietf.org <mailto:its-bounces@ietf.org> on behalf of
=C2=A0 =C2=A0 alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>

=C2=A0 =C2=A0 wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>Le 28/08/2017 =C3=A0 20:08, Fran=C3=A7ois Simon a =C3= =A9crit :
=C2=A0 =C2=A0 >>[...]
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>> *[Fygs] Since 2010 the OCB is defined in IEEE St= d 802.11p, IEEE Std
=C2=A0 =C2=A0 >>> 802.11-2012, and IEEE 802.11-2016.*
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>What's the reference to 2016?=C2=A0 Can I just go= with 'p' and with 2012?=C2=A0 Or
=C2=A0 =C2=A0 >>should I add a 3rd?


=C2=A0 =C2=A0 [Sri]
=C2=A0 =C2=A0 IMO, adding a reference to IEEE Std 802.11-2016 is sufficient= ; That
=C2=A0 =C2=A0 document clearly states that its a Revision of 802.11-2012.





=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>[...]>=C2=A0 =C2=A0 =C2=A0RSU: Road Side Unit.=C2= =A0 A computer equipped with at least one
=C2=A0 =C2=A0 >>IEEE
=C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0802.11 interface operated in = OCB mode.=C2=A0 This definition applies to
=C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0this document.=C2=A0 An RSU m= ay be connected to the Internet, and may be
=C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0equipped with additional wire= d or wireless network interfaces
=C2=A0 =C2=A0 >>>running
=C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0IP.=C2=A0 An RSU MAY be an IP= Router.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> [Sri] RSU can be compared to an 802.11 access po= int; Or, WTP as defined
=C2=A0 =C2=A0 >>> in CAPWAP specification, RFC5415.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> *[Fygs] While I am not familiar with =C2=B3WTP a= s defined in CAPWAP
=C2=A0 =C2=A0 >>> specification, RFC5415=C2=B2, I know that an RSU= has no commonality with an
=C2=A0 =C2=A0 >>> 802.11 AP.*
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>Mr. Simon - an RSU does use an 802.11 interface run i= n OCB mode, and a
=C2=A0 =C2=A0 >>WiFi Access Point also uses an 802.11 interface, so t= hey do have a
=C2=A0 =C2=A0 >>comonality.



=C2=A0 =C2=A0 [Sri]
=C2=A0 =C2=A0 I was earlier thinking RSU is more like an AP, but looking at= the WAVE
=C2=A0 =C2=A0 specs and based on Simon=E2=80=99s comments, the communicatio= n mode appears
=C2=A0 =C2=A0 to be
=C2=A0 =C2=A0 peer to peer (as opposed to peer to infra communication) mode= . For
=C2=A0 =C2=A0 example, even when sending WSMP messages, the RSU is still an= IPv6
=C2=A0 =C2=A0 peer??

=C2=A0 =C2=A0 But, this does not mean a 802-11-OCB node cannot be extended = to
=C2=A0 =C2=A0 communicate with an IPv6 peer reachable through an RSU node =C2=A0 =C2=A0 connected to a
=C2=A0 =C2=A0 backhaul. IMO, that is a more interesting scenarios and truly= will show
=C2=A0 =C2=A0 the value for using IPv6 in this environment. We can talk abo= ut a RSU
=C2=A0 =C2=A0 connecting to a router/backfaul and then talk about link pref= ixes
=C2=A0 =C2=A0 etc and
=C2=A0 =C2=A0 how a node can reach the backhaul network. In that sense equa= ting RSU to
=C2=A0 =C2=A0 an AP might make sense. May be the spec=C2=A0 (or other spec)= needs to
=C2=A0 =C2=A0 identify
=C2=A0 =C2=A0 different communication modes.








=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>[...]> *[Fygs] Here is a definition of OBU (= FCC): =C2=B3An On-Board
=C2=A0 =C2=A0 Unit is a
=C2=A0 =C2=A0 =C2=A0>>DSRCS
=C2=A0 =C2=A0 =C2=A0>>> transceiver that is normally mounted in or= on a vehicle, or
=C2=A0 =C2=A0 which in
=C2=A0 =C2=A0 =C2=A0>>> some instances may be a portable unit. An = OBU can be
=C2=A0 =C2=A0 operational while
=C2=A0 =C2=A0 =C2=A0>>>a
=C2=A0 =C2=A0 =C2=A0>>> vehicle or person is either mobile or stat= ionary.=C2=B2*
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>That is why an OBU FCC talks about is different= than the OBUs I play
=C2=A0 =C2=A0 =C2=A0>>with (there are many "transceivers" i= n OBUs I work with - there are
=C2=A0 =C2=A0 =C2=A0>>multiple 802.11-OCB transceivers, LTE transceiv= ers, and more, in just
=C2=A0 =C2=A0 =C2=A0>>one OBU).
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>Some currently call it an "IoT Platform&qu= ot;, a "Mobile Router", an "ITS
=C2=A0 =C2=A0 =C2=A0>>Station", and more other terms.=C2=A0 I am= not sure we want to
=C2=A0 =C2=A0 converge now.
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>As such I will call it a computer with at least= two IP interface,
=C2=A0 =C2=A0 and at
=C2=A0 =C2=A0 =C2=A0>>least one IP interface running in OCB mode.
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>[...]> [Sri] A packet sent from a vehicle=C2= =B9s OBU is received by a
=C2=A0 =C2=A0 single
=C2=A0 =C2=A0 =C2=A0>>RSU, or
=C2=A0 =C2=A0 =C2=A0>>> multiple RSU=C2=B9s? How does the link-lay= er resolution happen?
=C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0>>> *[Fygs] Assuming that:*
=C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0>>> *a) ****If t**here are**single or**multipl= e RSU**s****in the
=C2=A0 =C2=A0 =C2=A0>>> communication range and it is a**multicast= **message**,**the
=C2=A0 =C2=A0 single RSU
=C2=A0 =C2=A0 =C2=A0>>> or**RSUs in the comm**.**range will receiv= e it
=C2=A0 =C2=A0 (eventually)**.**There
=C2=A0 =C2=A0 =C2=A0>>>is
=C2=A0 =C2=A0 =C2=A0>>> no resolution at the link layer.
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>But there is resolution at the IP layer: it is = the IPv6 Neighbor
=C2=A0 =C2=A0 =C2=A0>>Discovery protocol.
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>> The RSU**(**s**)**will determine
=C2=A0 =C2=A0 =C2=A0>>> their**=C2=B3**interest**=C2=B2 based on**= the content of the message at the
=C2=A0 =C2=A0 =C2=A0>>>higher
=C2=A0 =C2=A0 =C2=A0>>> layers (application);***
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>YEs too.
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>But the interest is based on the MAC dst addres= s, not the app layer.
=C2=A0 =C2=A0 =C2=A0>>Apps talk to apps, MAC layers to MAC layers, ne= t layers to net
=C2=A0 =C2=A0 layers.



=C2=A0 =C2=A0 [Sri] I agree. In the context of this document, what happens = in the
=C2=A0 =C2=A0 application layer may be less relevant here. The spec needs t= o
=C2=A0 =C2=A0 explain how
=C2=A0 =C2=A0 =C2=A0=C2=A0unicast, multicast communication work and based o= n addresses in L2
=C2=A0 =C2=A0 and L3
=C2=A0 =C2=A0 headers ONLY.







=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>> *b) ****If there are single or multiple RS= Us in the
=C2=A0 =C2=A0 communication rand
=C2=A0 =C2=A0 =C2=A0>>> and it is**unicast message, then the link-= layer resolves by
=C2=A0 =C2=A0 =C2=A0>>> the**destination**MAC address**.*
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>I agree.=C2=A0 It uses ND.
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>[...]
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0The distinction between= the two formats is given by the
=C2=A0 =C2=A0 value of
=C2=A0 =C2=A0 =C2=A0>>>the
=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0field "Type/Subtyp= e".=C2=A0 The value of the field
=C2=A0 =C2=A0 "Type/Subtype" in the
=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0802.11 Data header is 0= x0020.=C2=A0 The value of the field
=C2=A0 =C2=A0 =C2=A0>>>"Type/Subtype"
=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0in the 802.11 QoS heade= r is 0x0028.
=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0The mapping between qos= -related fields in the IPv6 header (e.g.
=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0"Traffic Class&quo= t;, "Flow label") and fields in the "802.11
=C2=A0 =C2=A0 QoS Data
=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0Header" (e.g.=C2= =A0 "QoS Control") are not specified in this
=C2=A0 =C2=A0 document.
=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0Guidance for a potentia= l mapping is provided in
=C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0>>>[https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211= ocb-04#ref <https://to= ols.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref= >

=C2=A0 =C2=A0 =C2=A0>>>-
=C2=A0 =C2=A0 =C2=A0>>>I-D.ietf-tsvwg-ieee-802-11],
=C2=A0 =C2=A0 =C2=A0>>> although it is not specific to OCB
=C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0mode.
=C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0>>> [Sri] The applicability of the QoS mapping= draft to 802.11-OCB
=C2=A0 =C2=A0 needs
=C2=A0 =C2=A0 =C2=A0>>> further investigation, IMO.
=C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0>>> ***[Fygs] I am not familiar with QoS contr= ol of IPv6****.=C2=A0 As
=C2=A0 =C2=A0 for the
=C2=A0 =C2=A0 =C2=A0>>> OCB MAC QoS it is somewhat involved.****It= is based
=C2=A0 =C2=A0 =C2=A0>>> on********transmission priority****of MAC = frames.=C2=A0 A higher
=C2=A0 =C2=A0 priority
=C2=A0 =C2=A0 =C2=A0>>> frame is intended to be transmitted ahead = of lower priority
=C2=A0 =C2=A0 =C2=A0>>> frames.****If a detail process is required= , please, let me know
=C2=A0 =C2=A0 and I
=C2=A0 =C2=A0 =C2=A0>>> would provide the text.*****
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>The QoS mapping needs to be worked on a separat= e document that should
=C2=A0 =C2=A0 =C2=A0>>answer this: which MAC QoS field is mapped into= which IPv6 header
=C2=A0 =C2=A0 field.
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>On this list a few participants expressed inter= est in the QoS work.
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>IP QoS is a key solution to the distinctive saf= ety-entertainment
=C2=A0 =C2=A0 needs
=C2=A0 =C2=A0 =C2=A0>>in vehicular communications.
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>Alex
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>>__________________________________________= _____
=C2=A0 =C2=A0 =C2=A0>>its mailing list
=C2=A0 =C2=A0 =C2=A0>>its@ietf.org <mailto:its@ietf.org>
=C2=A0 =C2=A0 =C2=A0>>https://www.ietf.org/mailman/listinfo/its
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinf= o/its>
=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 its mailing list
 =C2=A0 =C2=A0 its@ietf.or= g <mailto:its@ietf= .org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/it= s
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinf= o/its>




--


PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com &= lt;mailto:w= whyte@onboardsecurity.com>



--


PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW AD= DRESS: wwhy= te@onboardsecurity.com
--001a114e36f8b53b960558e99db8-- From nobody Mon Sep 11 09:34:15 2017 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 B3098132EC1 for ; Mon, 11 Sep 2017 09:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 V5SU5IWH5-kq for ; Mon, 11 Sep 2017 09:34:12 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 B1AAA127005 for ; Mon, 11 Sep 2017 09:34:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8BGY6aT004764; Mon, 11 Sep 2017 18:34:06 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A4BC720A997; Mon, 11 Sep 2017 18:34:06 +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 9505C20A81F; Mon, 11 Sep 2017 18:34:06 +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 v8BGY699002408; Mon, 11 Sep 2017 18:34:06 +0200 To: "Sri Gundavelli (sgundave)" , "its@ietf.org" Cc: =?UTF-8?Q?Fran=c3=a7ois_Simon?= References: <007401d32028$a06b8ce0$e142a6a0$@gmail.com> <534037a7-9be7-925e-cc3f-9f803a2f3c52@gmail.com> From: Alexandre Petrescu Message-ID: <9bb74762-2c28-cac9-7fd4-6406bcc601e0@gmail.com> Date: Mon, 11 Sep 2017 18:34:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 16:34:14 -0000 Sri, Le 11/09/2017 06:25, Sri Gundavelli (sgundave) a crit : [...] >>> [...]> RSU: Road Side Unit. A computer equipped with at >>> least one IEEE >>>> 802.11 interface operated in OCB mode. This definition >>>> applies to this document. An RSU may be connected to the >>>> Internet, and may be equipped with additional wired or wireless >>>> network interfaces running IP. An RSU MAY be an IP Router. >>>> >>>> >>>> [Sri] RSU can be compared to an 802.11 access point; Or, WTP >>>> as defined in CAPWAP specification, RFC5415. >>>> >>>> *[Fygs] While I am not familiar with WTP as defined in CAPWAP >>>> specification, RFC5415, I know that an RSU has no >>>> commonality with an 802.11 AP.* >>> >>> Mr. Simon - an RSU does use an 802.11 interface run in OCB mode, >>> and a WiFi Access Point also uses an 802.11 interface, so they >>> do have a comonality. > > > > [Sri] I was earlier thinking RSU is more like an AP, but looking at > the WAVE specs and based on Simons comments, the communication mode > appears to be peer to peer (as opposed to peer to infra > communication) mode. Despite P1609 WAVE specs talking about RSU being like an AP it's certainly not an Access Point like in WiFi where it 'coordinates' others using its Registration Responses, or Authentication Responses. In WAVE an RSU is just a bridge or router that uses an .11 interface set in OCB mode (ad-hoc mode). > For example, even when sending WSMP messages, the RSU is still an > IPv6 peer?? I think that's a question about which 1609.3 is not much concerned. I think an IPv6 Router with an OCB interface can send IPv6 Router Advertisements simultaneously with sending WSMP messages (which dont have IP headers). For the former it will use the IPv6-over-OCB spec, whereas for the latter the P1609 specs. > But, this does not mean a 802-11-OCB node cannot be extended to > communicate with an IPv6 peer reachable through an RSU node > connected to a backhaul. IMO, that is a more interesting scenarios > and truly will show the value for using IPv6 in this environment. I agree. > We can talk about a RSU connecting to a router/backhaul and then talk > about link prefixes etc and how a node can reach the backhaul > network. In that sense equating RSU to an AP might make sense. May be > the spec (or other spec) needs to identify different communication > modes. I agree. [...] >>> >>> [...]> [Sri] A packet sent from a vehicles OBU is received by a >>> single RSU, or >>>> multiple RSUs? How does the link-layer resolution happen? >>>> >>>> *[Fygs] Assuming that:* >>>> >>>> *a) ****If t**here are**single or**multiple RSU**s****in the >>>> communication range and it is a**multicast**message**,**the >>>> single RSU or**RSUs in the comm**.**range will receive it >>>> (eventually)**.**There is no resolution at the link layer. >>> >>> But there is resolution at the IP layer: it is the IPv6 Neighbor >>> Discovery protocol. >>> >>>> The RSU**(**s**)**will determine their****interest** based >>>> on**the content of the message at the higher layers >>>> (application);*** >>> >>> YEs too. >>> >>> But the interest is based on the MAC dst address, not the app >>> layer. Apps talk to apps, MAC layers to MAC layers, net layers >>> to net layers. > > > > [Sri] I agree. In the context of this document, what happens in the > application layer may be less relevant here. The spec needs to > explain how unicast, multicast communication work and based on > addresses in L2 and L3 headers ONLY. Is it sufficient that we just say we use IPv6 ND protocol for that? Alex From nobody Mon Sep 11 09:56:21 2017 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 4D5A0132ED2 for ; Mon, 11 Sep 2017 09:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 SZJV5-f0b2cI for ; Mon, 11 Sep 2017 09:56:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0378A132644 for ; Mon, 11 Sep 2017 09:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=794; q=dns/txt; s=iport; t=1505148979; x=1506358579; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5Bzz5MUJ+jW28Xpc7N1ghcJaexoNc8p1fH2DOm8ka+8=; b=Me0s5WmkxjKG+Eff4vq94i3488eQVaTRChdhL48bIzoAekv9y9DSTrZc XrzmfVrU+W+A0glRH9NJRJeNGBRsQBfACYHTSlJACPS7vT1CmRfm8MY0d uQLblLx4T5XCKXmbqllLRAaOcehtbstvQjW1GXoxG3pAk7KLIaEhsEFLP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9AACbv7ZZ/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1uBUicHjhGQIYoujW8OggQKhT4ChCI/GAECAQEBAQEBAWsohRk?= =?us-ascii?q?GeRACAQhGIRElAgQBDQWKGQMVriOHLg2DbwEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?R2DK4ICgVCFC4JYgWOGMAWRc45FPAKPWYR2knGMU4grAhEZAYE4AR84gQ13FYd?= =?us-ascii?q?ldogwgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.42,378,1500940800"; d="scan'208";a="283574950" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Sep 2017 16:56:18 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v8BGuIdk019585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Sep 2017 16:56:18 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 11 Sep 2017 11:56:17 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Mon, 11 Sep 2017 11:56:17 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandre Petrescu , "its@ietf.org" CC: =?iso-8859-1?Q?Fran=E7ois_Simon?= Thread-Topic: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt Thread-Index: AQHTH6nS3MdwWO6+I0K2nyn/HA8hRQ== Date: Mon, 11 Sep 2017 16:56:17 +0000 Message-ID: References: <007401d32028$a06b8ce0$e142a6a0$@gmail.com> <534037a7-9be7-925e-cc3f-9f803a2f3c52@gmail.com> <9bb74762-2c28-cac9-7fd4-6406bcc601e0@gmail.com> In-Reply-To: <9bb74762-2c28-cac9-7fd4-6406bcc601e0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7E794CD0AB12D84982093DF5A805925E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 16:56:20 -0000 Hi Alex, On 9/11/17, 9:34 AM, "Alexandre Petrescu" wrote: > >>=20 >>=20 >>=20 >> [Sri] I agree. In the context of this document, what happens in the >> application layer may be less relevant here. The spec needs to >> explain how unicast, multicast communication work and based on >> addresses in L2 and L3 headers ONLY. > >Is it sufficient that we just say we use IPv6 ND protocol for that? Defining L2/L3 header mapping for 802.11-OCB access is very straight forward IMO, but making ND work in that environment is not trivial (unless I am completely off here). So, without telling how ND works, talking about IPv6 packet transmission/reception may not mean any thing, as ND is the essential control protocol for IPv6 operation. Sri From nobody Mon Sep 11 10:21:47 2017 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 535A813315A for ; Mon, 11 Sep 2017 10:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.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 g6_YOxCstk_F for ; Mon, 11 Sep 2017 10:21:43 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3B8132D97 for ; Mon, 11 Sep 2017 10:21:42 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id a43so16101193wrc.0 for ; Mon, 11 Sep 2017 10:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oWqVXkAVida36xMMJlBIKL69fPwpz1sFf8zLkDZHHaY=; b=bqh3nR7gtWcFQ4jLjr0RJpO65Z4oD3d9KQa8ItyXqZGT1H76YE3f6BnXnrPzWFBDNp Py8Xg/lCG9kkzdqWPrL2e1ZEbsI6R2C2wr3Xff4rIt1keBDmj2RK72cyxjue5/tKSCx6 l8Bzn9Ts29DOuE3BTbeyBJK4SOmaSpNUj3ktE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oWqVXkAVida36xMMJlBIKL69fPwpz1sFf8zLkDZHHaY=; b=Vl9Hxx0Ae9cNl8D9RnbAPUZp7DXpFSA3u63ibxMtk/G8vnEG2GCl+JdRrQnDi83HdH hyiR5XIOkbuhiaWnPcX3PPyZjGEioOk5JoAa+aAFXgeJZ9E+CRXXH09MHdSkZrvbVM/j 1+gx/W+gLxi0H1QrlweunMeZSQi5zHqAQP33c1bbqJ7unJMFPvANPNzS3KhOc9xnUy28 nml+Nv5fyVhnPEWguXStrzFyuEBvPEqenVNQJWEaE9UpyLj3pINj47gPpCghegj/1/kF cAwjHAciIkqxqfBiZ73dxBDBzqyRUHK73d0Z2mO0ANbfmGEl3xexQQm0tODVpqbpssT4 JE8A== X-Gm-Message-State: AHPjjUiadcXihMG2Du3ZTtatXxrVTTGLU8Q1J3Hz55bNBnNkaMIiD+GO MBVSAA+KchxVlYID+/gVbNvDPHc3Edj6 X-Google-Smtp-Source: ADKCNb4WExuPdQKtDoqanERClsu+mtYrWTefoj/laapF0X5WmjzwtDDMLClklU6W5iDvCzkZDoDmODY9523QtJUTWlo= X-Received: by 10.223.151.195 with SMTP id t3mr8786415wrb.222.1505150500684; Mon, 11 Sep 2017 10:21:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.50.202 with HTTP; Mon, 11 Sep 2017 10:21:19 -0700 (PDT) In-Reply-To: <9bb74762-2c28-cac9-7fd4-6406bcc601e0@gmail.com> References: <007401d32028$a06b8ce0$e142a6a0$@gmail.com> <534037a7-9be7-925e-cc3f-9f803a2f3c52@gmail.com> <9bb74762-2c28-cac9-7fd4-6406bcc601e0@gmail.com> From: William Whyte Date: Mon, 11 Sep 2017 13:21:19 -0400 Message-ID: To: Alexandre Petrescu Cc: "Sri Gundavelli (sgundave)" , "its@ietf.org" , =?UTF-8?Q?Fran=C3=A7ois_Simon?= Content-Type: multipart/alternative; boundary="94eb2c1b5d46ed5a9c0558ed28cf" Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 17:21:45 -0000 --94eb2c1b5d46ed5a9c0558ed28cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Despite P1609 WAVE specs talking about RSU being like an AP it's > certainly not an Access Point like in WiFi where it 'coordinates' > others using its Registration Responses, or Authentication Responses. > In WAVE an RSU is just a bridge or router that uses an .11 interface set in OCB mode (ad-hoc mode). Which 1609 specs? Neither 1609.2 nor 1609.3 defines an RSU type. (1609.2 mentions that RSEs may have longer range than OBEs; 1609.3 doesn't mention them at all). Cheers, William On Mon, Sep 11, 2017 at 12:34 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Sri, > > Le 11/09/2017 =C3=A0 06:25, Sri Gundavelli (sgundave) a =C3=A9crit : > [...] > > [...]> RSU: Road Side Unit. A computer equipped with at least one IE= EE >>>> >>>>> 802.11 interface operated in OCB mode. This definition >>>>> applies to this document. An RSU may be connected to the >>>>> Internet, and may be equipped with additional wired or wireless >>>>> network interfaces running IP. An RSU MAY be an IP Router. >>>>> >>>>> >>>>> [Sri] RSU can be compared to an 802.11 access point; Or, WTP >>>>> as defined in CAPWAP specification, RFC5415. >>>>> >>>>> *[Fygs] While I am not familiar with =C2=B3WTP as defined in CAPWAP >>>>> specification, RFC5415=C2=B2, I know that an RSU has no >>>>> commonality with an 802.11 AP.* >>>>> >>>> >>>> Mr. Simon - an RSU does use an 802.11 interface run in OCB mode, and a >>>> WiFi Access Point also uses an 802.11 interface, so they >>>> do have a comonality. >>>> >>> >> >> >> [Sri] I was earlier thinking RSU is more like an AP, but looking at the >> WAVE specs and based on Simon=E2=80=99s comments, the communication mode= appears to >> be peer to peer (as opposed to peer to infra communication) mode. >> > > Despite P1609 WAVE specs talking about RSU being like an AP it's > certainly not an Access Point like in WiFi where it 'coordinates' > others using its Registration Responses, or Authentication Responses. > In WAVE an RSU is just a bridge or router that uses an .11 interface set > in OCB mode (ad-hoc mode). > > For example, even when sending WSMP messages, the RSU is still an IPv6 >> peer?? >> > > I think that's a question about which 1609.3 is not much concerned. > > I think an IPv6 Router with an OCB interface can send IPv6 Router > Advertisements simultaneously with sending WSMP messages (which dont have > IP headers). > > For the former it will use the IPv6-over-OCB spec, whereas for the > latter the P1609 specs. > > But, this does not mean a 802-11-OCB node cannot be extended to >> communicate with an IPv6 peer reachable through an RSU node >> connected to a backhaul. IMO, that is a more interesting scenarios >> and truly will show the value for using IPv6 in this environment. >> > > I agree. > > We can talk about a RSU connecting to a router/backhaul and then talk >> about link prefixes etc and how a node can reach the backhaul >> network. In that sense equating RSU to an AP might make sense. May be >> the spec (or other spec) needs to identify different communication >> modes. >> > > I agree. > > [...] > >> >>>> [...]> [Sri] A packet sent from a vehicle=C2=B9s OBU is received by a = single >>>> RSU, or >>>> >>>>> multiple RSU=C2=B9s? How does the link-layer resolution happen? >>>>> >>>>> *[Fygs] Assuming that:* >>>>> >>>>> *a) ****If t**here are**single or**multiple RSU**s****in the >>>>> communication range and it is a**multicast**message**,**the single RS= U >>>>> or**RSUs in the comm**.**range will receive it (eventually)**.**There= is no >>>>> resolution at the link layer. >>>>> >>>> >>>> But there is resolution at the IP layer: it is the IPv6 Neighbor >>>> Discovery protocol. >>>> >>>> The RSU**(**s**)**will determine their**=C2=B3**interest**=C2=B2 based= on**the >>>>> content of the message at the higher layers (application);*** >>>>> >>>> >>>> YEs too. >>>> >>>> But the interest is based on the MAC dst address, not the app layer. >>>> Apps talk to apps, MAC layers to MAC layers, net layers >>>> to net layers. >>>> >>> >> >> >> [Sri] I agree. In the context of this document, what happens in the >> application layer may be less relevant here. The spec needs to explain h= ow >> unicast, multicast communication work and based on addresses in L2 and L= 3 >> headers ONLY. >> > > Is it sufficient that we just say we use IPv6 ND protocol for that? > > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --94eb2c1b5d46ed5a9c0558ed28cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Despite P1609 W= AVE specs talking about RSU being like an AP it's
> certainly not an Acce= ss Point like in WiFi where it 'coordinates'
> others using its Regis= tration Responses, or Authentication Responses.
> In WAVE an RSU is just a br= idge or router that uses an .11 interface set in OCB mode (ad-hoc mode).

Which 1609 specs? Neither 1609.2 nor 1609.3 defines a= n RSU type. (1609.2 mentions that RSEs may have longer range than OBEs; 160= 9.3 doesn't mention them at all).

Cheers,=

William

On Mon, Sep 11, 2017 at 12:34 PM, A= lexandre Petrescu <alexandre.petrescu@gmail.com> = wrote:
Sri,

Le 11/09/2017 =C3=A0 06:25, Sri Gundavelli (sgundave) a =C3=A9crit :
[...]

[...]>=C2=A0 =C2=A0 =C2=A0RSU: Road Side Unit.=C2=A0 A computer equipped= with at least one IEEE
802.11 interface operated in OCB mode.=C2=A0 This definition
applies to this document.=C2=A0 An RSU may be connected to the
Internet, and may be equipped with additional wired or wireless
network interfaces running IP.=C2=A0 An RSU MAY be an IP Router.


[Sri] RSU can be compared to an 802.11 access point; Or, WTP
as defined in CAPWAP specification, RFC5415.

*[Fygs] While I am not familiar with =C2=B3WTP as defined in CAPWAP
=C2=A0specification, RFC5415=C2=B2, I know that an RSU has no
commonality with an 802.11 AP.*

Mr. Simon - an RSU does use an 802.11 interface run in OCB mode, and a WiFi= Access Point also uses an 802.11 interface, so they
do have a comonality.



[Sri] I was earlier thinking RSU is more like an AP, but looking at the WAV= E specs and based on Simon=E2=80=99s comments, the communication mode appea= rs to be peer to peer (as opposed to peer to infra communication) mode.

 Despite P1609 WAVE specs talking about RSU being like an AP it's
certainly not an Access Point like in WiFi where it 'coordinates' others using its Registration Responses, or Authentication Responses.
In WAVE an RSU is just a bridge or router that uses an .11 interface set in= OCB mode (ad-hoc mode).

For example, even when sending WSMP messages, the RSU is still an IPv6 peer= ??

 I think that's a question about which 1609.3 is not much concerned.

I think an IPv6 Router with an OCB interface can send IPv6 Router
Advertisements simultaneously with sending WSMP messages (which dont have I= P headers).

For the former it will use the IPv6-over-OCB spec, whereas for the
latter the P1609 specs.

But, this does not mean a 802-11-OCB node cannot be extended to communicate= with an IPv6 peer reachable through an RSU node
connected to a backhaul. IMO, that is a more interesting scenarios
and truly will show the value for using IPv6 in this environment.

 I agree.

We can talk about a RSU connecting to a router/backhaul and then talk
about link prefixes etc and how a node can reach the backhaul
network. In that sense equating RSU to an AP might make sense. May be
the spec=C2=A0 (or other spec) needs to identify different communication modes.

I agree.

[...]

[...]> [Sri] A packet sent from a vehicle=C2=B9s OBU is received by a si= ngle RSU, or
multiple RSU=C2=B9s? How does the link-layer resolution happen?

*[Fygs] Assuming that:*

*a) ****If t**here are**single or**multiple RSU**s****in the communication = range and it is a**multicast**message**,**the single RSU or**RSUs in the co= mm**.**range will receive it (eventually)**.**There is no resolution at the= link layer.

But there is resolution at the IP layer: it is the IPv6 Neighbor
=C2=A0Discovery protocol.

The RSU**(**s**)**will determine their**=C2=B3**interest**=C2=B2 based on**= the content of the message at the higher layers (application);***

YEs too.

But the interest is based on the MAC dst address, not the app layer. Apps t= alk to apps, MAC layers to MAC layers, net layers
to net layers.



[Sri] I agree. In the context of this document, what happens in the applica= tion layer may be less relevant here. The spec needs to explain how unicast= , multicast communication work and based on addresses in L2 and L3 headers = ONLY.

 Is it sufficient that we just say we use IPv6 ND protocol for that?


Alex

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



--
=


PLEASE UPDATE YOUR ADDRESS BOOKS WIT= H MY NEW ADDRESS: wwhyte@onboardsecurity.com
--94eb2c1b5d46ed5a9c0558ed28cf-- From nobody Mon Sep 11 12:35:52 2017 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 E6EA2132F32 for ; Mon, 11 Sep 2017 12:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 QozmbJ8SgGjJ for ; Mon, 11 Sep 2017 12:35:48 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 B83111331CB for ; Mon, 11 Sep 2017 12:35:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8BJZODZ007366; Mon, 11 Sep 2017 21:35:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DD63C20A95D; Mon, 11 Sep 2017 21:35:24 +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 CDB5720A663; Mon, 11 Sep 2017 21:35:24 +0200 (CEST) Received: from [132.166.84.113] ([132.166.84.113]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8BJZNKs019504; Mon, 11 Sep 2017 21:35:24 +0200 To: "Sri Gundavelli (sgundave)" , "its@ietf.org" Cc: =?UTF-8?Q?Fran=c3=a7ois_Simon?= References: <007401d32028$a06b8ce0$e142a6a0$@gmail.com> <534037a7-9be7-925e-cc3f-9f803a2f3c52@gmail.com> <9bb74762-2c28-cac9-7fd4-6406bcc601e0@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 11 Sep 2017 21:35:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 19:35:51 -0000 Le 11/09/2017 à 18:56, Sri Gundavelli (sgundave) a écrit : > Hi Alex, > > > On 9/11/17, 9:34 AM, "Alexandre Petrescu" > wrote: > >> >>> >>> >>> >>> [Sri] I agree. In the context of this document, what happens in >>> the application layer may be less relevant here. The spec needs >>> to explain how unicast, multicast communication work and based >>> on addresses in L2 and L3 headers ONLY. >> >> Is it sufficient that we just say we use IPv6 ND protocol for >> that? > > Defining L2/L3 header mapping for 802.11-OCB access is very straight > forward IMO, but making ND work in that environment is not trivial > (unless I am completely off here). Certainly you are not off, but it is easier to discuss with an use-case at hand. In certain use-cases (e.g V2V in convoys, or stationary vehicle to electric charging station, or vehicle at the traffic lights) there is no ND problem over OCB - it works fine. I could describe these use-cases, if I not already done in some -its- drafts. In other use-cases, e.g. dynamic variable speed multi-lane convoys, we may be afraid how ND works. To that, maybe we want to describe the use-case first. > So, without telling how ND works, talking about IPv6 packet > transmission/reception may not mean any thing, as ND is the essential > control protocol for IPv6 operation. There is an ND document in IPWAVE WG, as an individual proposal. Maybe we want to pursue it. Alex > > Sri > > > > > > From nobody Mon Sep 11 12:50:52 2017 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 CE99A1331DD for ; Mon, 11 Sep 2017 12:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 gpnkXNSZouwU for ; Mon, 11 Sep 2017 12:50:49 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 EBFAB1331D9 for ; Mon, 11 Sep 2017 12:50:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8BJoisu011272; Mon, 11 Sep 2017 21:50:44 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 68B8920AA5A; Mon, 11 Sep 2017 21:50:44 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5B5E720A9D3; Mon, 11 Sep 2017 21:50:44 +0200 (CEST) Received: from [132.166.84.113] ([132.166.84.113]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8BJohmw027593; Mon, 11 Sep 2017 21:50:43 +0200 To: "Sri Gundavelli (sgundave)" Cc: "its@ietf.org" References: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> From: Alexandre Petrescu Message-ID: <8912c4b1-61d7-13e7-b7d2-653d542b6769@gmail.com> Date: Mon, 11 Sep 2017 21:50:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 19:50:51 -0000 Le 11/09/2017 à 05:58, Sri Gundavelli (sgundave) a écrit : > Hi Alex, > > Thanks for posting the new version addressing some of my comments. My main > issue is still about the nature of the link based on 802.11-OCB and the > big change that this operating environment (Vehicular) brings to the > table. We can certainly insist that the scope of this work is about > IPv6-over-foo and so any discussions around address configuration modes, > ND, link models, link prefixes ..etc is out of scope. But, note that the > IEEE definition of WAVE, 802.11-OCB, or the DSRC spectrum band is strictly > for vehicular environments and so I tend to this document has to make sure > we explain how one can make IPv6 and the dependent protocols work on > 802.11-OCB based links. We cannot ignore the operating environment. I agree, and in that operating environment there are many possible use-cases. Some of them may have more problems than others, in making ND work. > For a node to send an IPv6 packet, it surely needs to be able to do the > L2/L3 mapping to the respective access technology and transmit the packet. > But, it also needs to generate an IPv6 address (link-local / global), > perform DAD on the link, perform ND resolutions for the destination > address, do the route lookups and send the packet out. So, what is not > clear to me from reading the spec is how all of that works on 802.11-OCB. > > 1.) Lets take a high-way scenario where 3 vehicles (A, B, C) come in close > proximity and can communicate among themselves. > > At T=0, > C-—A-—B In this case, we need a mechanism in ND such that A routes packets from C to B, and vice-versa. The 'A' is a car with two OCB interfaces: one to C and one to B. It uses a different channel on each of these interfaces, and runs IP on each. Such mechanism is like in the drafts of routing advertisement between moving networks, or like in the INPD protocol. Do you think there can be another? > At T=1, one of the vehicle moves on (with signal level < 33 dbm) from the > previous neighbors. But there is a new node D in the vicinity. Also, node > C is now in another group ( C, E and F) > D-—A—-B > > C-—E-—F There will be multiple ND exchanges here to make it work. But I would like to ask you which is the particular use-case? Is this something planned, or something we are afraid it may arrive? > From the classic link sense, the node configurations have changed. > > > 2.) How do the nodes communicate among themselves in the base scenario. Do > they use link-local or global address? How do they generate the addresses? > > 3.) If its global, how do they discover the on-link prefix? > > 3.) If its link-local (or global) How does DAD work in the above scenario? > With the link topology changing so dynamically, how can ND work here? We can answer these questions. We can unfold the ND messaging and the SLAAC (if necessary), provided you think that use-case is important. Do you think we need to describe that use-case D-A-B/C-E-F as an example and then tell how ND would work? Would you be interested in participating in that description? > 4.) Will the nodes support all standard multicast groups. For example, > will they participate in ALL_NODES_MULTICAST GROUP (FF02::1). IF yes, why > is the spec defining a new group for OCB nodes? Why is that needed? That's a good question. It is good to have a separated group ID for OCB because it will help distinguish between all-nodes adresses on WiFi. Since the OCB nodes are special (they are not WiFi nodes) it makes sense to have special OCB IP multicast groups. Just like it's useful to have a distinguishing EtherType to distinguish between WAVE messages and IPv6 being carried in 802.11. [...] >>>> Is DHCPv6 based address configuration relevant here? >>> >>> YEs, but not to describe the detail use of DHCPv6-over-foo on >>> IP-over-foo. >>> >>> If you want to just refer to DHCP, that would be at which place in this >>> document? >>> > > > Sure, but this is a special type of link and so its not clear how this > works. > > DHCP server can be outside the link; in the current spec, its not clear > how the node even discovers the on-link prefix, or the default router. Because in IP-over-foo we dont talk about topologies like star topology, or shared topology, or point-to-point topology. In a separate document (I invite you to get involved) we can describe a topology of RSU and many cars around it. There we can talk how cars discover the RSU. And we can talk about topology of intelligent junction where cars see each other through an RSU mirror at angles where drivers cant see. And there again we can talk how cars form addresses, discover each other, etc. [...] >>> [...]> The Equivalent Transmit Time on Channel is a concept that may >>> be used >>>> as an alternative to the MTU concept. A rate of transmission may be >>>> specified as well. The ETTC, rate and MTU may be in direct >>>> relationship. >>>> >>>> [Sri] The last paragraph needs some additional context. Did >>>> 802.11-OCB introduce ETTC concept? >>> >>> We heard this term at mic in Berlin BoF. Sounded like a more universal >>> term. Should we remove it? > > > > I understand the relation between MTU and the ETTC. But, if we talk about > it, we have to explain which parameter drives the other. How do you > exactly set the MTU based on the ETTC rate. More details on needed. Maybe we get rid of ETTC altogether? Alex (see separate for 2464bis) From nobody Mon Sep 11 13:04:37 2017 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 A1E92132339 for ; Mon, 11 Sep 2017 13:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, 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 udn1tcVwEH4o for ; Mon, 11 Sep 2017 13:04:34 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 D5A8913219F for ; Mon, 11 Sep 2017 13:04:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8BK4TH5064128; Mon, 11 Sep 2017 22:04:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3A5FE20ABBF; Mon, 11 Sep 2017 22:04:29 +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 23D6920A92A; Mon, 11 Sep 2017 22:04:29 +0200 (CEST) Received: from [132.166.84.113] ([132.166.84.113]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8BK4Qpo018236; Mon, 11 Sep 2017 22:04:28 +0200 To: "Sri Gundavelli (sgundave)" Cc: "its@ietf.org" References: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 11 Sep 2017 22:04:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 20:04:36 -0000 Le 11/09/2017 à 05:58, Sri Gundavelli (sgundave) a écrit : [...] >>>> [Sri] Per my earlier comment, the link model, addressing ..etc needs >>>> to be explained in more detail. It is not clear what exactly the >>>> ³subnet structure² that is assumed in 802.11-OCB. >>> >>> Improved the subnet structure section. > > > May require few more details What kind of details would you see? Would you like to propose? Alex From nobody Mon Sep 11 13:11:36 2017 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 9ECFF1331DD for ; Mon, 11 Sep 2017 13:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 IQW8OBf8LSdS for ; Mon, 11 Sep 2017 13:11:32 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 E223013219F for ; Mon, 11 Sep 2017 13:11:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8BKBRot065900; Mon, 11 Sep 2017 22:11:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C846B20ABE1; Mon, 11 Sep 2017 22:11:27 +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 BAFC320ABC0; Mon, 11 Sep 2017 22:11:27 +0200 (CEST) Received: from [132.166.84.113] ([132.166.84.113]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8BKBQG1020625; Mon, 11 Sep 2017 22:11:27 +0200 To: "Sri Gundavelli (sgundave)" Cc: "its@ietf.org" References: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> From: Alexandre Petrescu Message-ID: <0a5b089b-0cd6-f0dd-15dd-76b9a19f009b@gmail.com> Date: Mon, 11 Sep 2017 22:11:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - vs 2464bis X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 20:11:34 -0000 Le 11/09/2017 à 05:58, Sri Gundavelli (sgundave) a écrit : [...] >>>> The link-local address of an 802.11-OCB interface is formed in the >>>> same manner as on an Ethernet interface. This manner is described >>>> in section 5 of [RFC2464] >>>> . >>>> >>>> >>>> >>>> [Sri] Does this go against the 8064 recommendation on Interface >>>> identifier generation? >>> >>> YEs. > > > We should state that. Can we tell 2464bis to state it? >>>> May be RFC7217 for interface identifier generation in conjunction >>>> with the link-local address generation per RFC2464 >>> >>> YEs. But I think it's up to rfc2464-bis to say that, and this >>> IPv6-over-OCB to just refer to rfc2464-bis. > > As with any bis document, its not going merge newer specs into it. We > still need to refer to the other documents, IMO. I think 2464bis should include 8064 recommendation, otherwise it's still obsolete. >>> [...] >>>> For unicast as for multicast, there is no change from the unicast >>>> and multicast address mapping format of Ethernet interfaces, as >>>> defined by sections6 >>>> >>>> >>> t >>>> ion-6> >>>> and7 >>>> >>>> >>> t >>>> ion-7> >>>> of [RFC2464 ]. >>>> >>>> >>>> >>>> [Sri] RFC6085 specified mapping is also relevant; If the >>>> communication peers are aware that there is only one peer, it should >>>> apply 6085 specified mapping. That mode is relevant for 802.11-OCB >>>> types links as well. >>> >>> Same here, would be great to get 6085 into 2464-bis, at which point this >>> ip-over-ocb inherits from 2464-bis. > > > I do not think 2464-bis will add new references. Its up to you, but 6085 > may be relevant here. I think it must. If I learn it will not, then I will add 7217 to IP-over-OCB. Do you think it is a good way forward? >>>> [Sri] I thought, mapping of IPv6 unicast addresses to Ethernet >>>> link-layer addresses is specified in section 6, of RFC2464 and not in >>>> RFC4861. >>> >>> Either we have a brief paragraph that just refers to 2464 section 6, or >>> copy paste that section from 2464 and update its [DISC] reference to >>> 4861. That I did, in order to have the text a bit longer. >>> >>> At this time I keep it that way, unless someone opposes. > > > May be I am missing some thing. The mapping is defined in 2464 and so the > 4861 reference may be incorrect. 2464 has an old reference to 2461 (instead of the new 4861). So we want 2464bis to add reference to 4861. That would be the ideal. (when 2464 talks about 'mapping' it means both a static mapping between addresses, _and_ a dynamic resolution like ND). >>> A key question here is how is 2464bis advancing, and how we coordinate >>> with it. >>> [...] >>>> An IPv6 packet with a multicast destination address DST, consisting >>>> of the sixteen octets DST[1] through DST[16], is transmitted to the >>>> IEEE 802.11-OCB MAC multicast address whose first two octets are the >>>> value 0x3333 and whose last four octets are the last four octets of >>>> DST. >>>> >>>> [Sri] Please add a reference to Section 7, RFC4861 and also RFC6085. >>>> In general, for both unicast and multicast, you may want to clearly >>>> say that this is per the existing specs and duplicated here for >>>> convenience. >>> >>> Should _this_ document do it, or should the 2464bis do it? At this time >>> I keep it that way. > > > I am not tracking the bis and so not sure if it will include all these > documents. Any ways …your call The 2464bis is in an individual submission stage. It is not yet a WG item. I do not know how the ADs see the situation of this IP-over-OCB document vs the advancement of 2464bis. Do you think we should pursue IP-over-OCB separate from 2464bis? I can also go that way, but I would like confirmation. Alex From nobody Mon Sep 11 13:21:48 2017 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 1B6F9132339 for ; Mon, 11 Sep 2017 13:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 EILqwf8CZrln for ; Mon, 11 Sep 2017 13:21:41 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E4013219F for ; Mon, 11 Sep 2017 13:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2728; q=dns/txt; s=iport; t=1505161300; x=1506370900; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/FeldFZwI3AOJ7N22xe6wdyl0JJA2lmGPN4u6qmoyLo=; b=EvJJhN4uzbIrj18ZbDKN3dOBtnoUL5hzG2p9WBdMYDbNqDAGd6rhHRJX WGq7o2bHna3/u46IF7CAidQ6OOfVXsJ40u657yYOLq3XkVxYSd4a1bf3A MKVo9cKAW+y+lh+lYVXul/HMl56aZtgfME5nV67fgp9YBN/TCpDGtNx9g g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAQAU8LZZ/4kNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1uBUicHnjOBdIg6kAEKhT4ChCNXAQIBAQEBAQJrKIUZAQQBeQU?= =?us-ascii?q?LAgEIRiERJQIEDgWKGQMNCK0JhzINg28BAQEBAQEBAQEBAQEBAQEBAQEBH4Mrg?= =?us-ascii?q?gKBUIFjgyiCWIIfhXQFigaWMjwCj1mEdpJxjFOIKwIRGQGBOAFXgQ13FYYXgU5?= =?us-ascii?q?2iXuBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,379,1500940800"; d="scan'208";a="1989644" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Sep 2017 20:21:40 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8BKLeTg030963 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Sep 2017 20:21:40 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 11 Sep 2017 15:21:39 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Mon, 11 Sep 2017 15:21:39 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandre Petrescu CC: "its@ietf.org" Thread-Topic: Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section Thread-Index: AQHTKzuTGRoJnuH1tkCfJq2fNvzHJQ== Date: Mon, 11 Sep 2017 20:21:39 +0000 Message-ID: References: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.41.32.30] Content-Type: text/plain; charset="windows-1254" Content-ID: <8DDC58610C8F4B4F931873F34D836DD3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 20:21:47 -0000 Hi Alex, > What kind of details would you see? Would you like to propose? Our starting point is still the link. Is there even possibility of realizing a =93link=94 in this environment. For hosting a prefix, you need = a link and when that link is based on dynamic grouping of random set of 802-11-OCB nodes, where the nodes are always changing groups, where is the link. What defines a link? There is node mobility even in other types of wired/wireless links, but the presence of a router on the link made a link a stable link where the prefix stay with the link. But, in WAVE, we don=92t have that router and so the question is what defines a link? Now, the second part is about the prefixes? If the hosted prefix is a link-local prefix FE80://, or a global prefix? A node is always moving between links/subnets, without ever noticing that it changed the link. Unless we throw some light on the above, any discussion on subnet structure is incomplete IMO. The below text does not seem to be addressing these points. Sri ------------------------- 5.6. Subnet Structure A subnet is formed by the external 802.11-OCB interfaces of vehicles that are in close range (not their on-board interfaces). This ephemeral subnet structure is strongly influenced by the mobility of vehicles: the 802.11 hidden node effects appear. On another hand, the structure of the internal subnets in each car is relatively stable. For routing purposes, a prefix exchange mechanism could be needed between neighboring vehicles. The 802.11 networks in OCB mode may be considered as 'ad-hoc' networks. The addressing model for such networks is described in [RFC5889]. An addressing model involves several types of addresses, like Globally-unique Addresses (GUA), Link-Local Addresses (LL) and Unique Local Addresses (ULA). The subnet structure in 'ad-hoc' networks may have characteristics that lead to difficulty of using GUAs derived from a received prefix, but the LL addresses may be easier to use since the prefix is constant. ----------------------------- On 9/11/17, 1:04 PM, "Alexandre Petrescu" wrote: > > >Le 11/09/2017 =E0 05:58, Sri Gundavelli (sgundave) a =E9crit : >[...] > >>>>> [Sri] Per my earlier comment, the link model, addressing ..etc needs >>>>> to be explained in more detail. It is not clear what exactly the >>>>> =B3subnet structure=B2 that is assumed in 802.11-OCB. >>>> >>>> Improved the subnet structure section. >>=20 >>=20 >> May require few more details > >What kind of details would you see? Would you like to propose? > >Alex From nobody Mon Sep 11 23:06:42 2017 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 21CFF132924 for ; Mon, 11 Sep 2017 23:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 yCKLuO6-xRdk for ; Mon, 11 Sep 2017 23:06:40 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 BF21A12426E for ; Mon, 11 Sep 2017 23:06:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8C66ZAw035925; Tue, 12 Sep 2017 08:06:35 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 890412040C3; Tue, 12 Sep 2017 08:06:35 +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 7BC47200BC5; Tue, 12 Sep 2017 08:06:35 +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 v8C66Z1V004334; Tue, 12 Sep 2017 08:06:35 +0200 To: "Sri Gundavelli (sgundave)" Cc: "its@ietf.org" References: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 12 Sep 2017 08:06:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 06:06:42 -0000 Le 11/09/2017 22:21, Sri Gundavelli (sgundave) a crit : > Hi Alex, > >> What kind of details would you see? Would you like to propose? > > Our starting point is still the link. Is there even possibility of > realizing a link in this environment. YEs, as pictured, two STAs next to each ohter have a link good enough for IPv6 ND to work on it. Move them a little bit further from each other and there is no more link. I do not understand what do you mean by 'link'? > For hosting a prefix, you need a link and when that link is based on > dynamic grouping of random set of 802-11-OCB nodes, where the nodes > are always changing groups, where is the link. What defines a link? That's a good point, but do you think we can define a link in this document? In OCB a 'link' is ephemeral: I see it created when a STA receives an NA as response to its NS. Even then, after that reception we're not sure the link is still there. Or it can. TCP will make sure that data gets across. In an RSU-to-OBUs communication there is a very stable link, as link as these OBUs stay within the limits of coverage of that OBU. All this is also valid with WiFi links: ICB (_Inside_ the Context of a BSS). > There is node mobility even in other types of wired/wireless links, > but the presence of a router on the link made a link a stable link I dont think it's the router's presence that makes that link stable(?) What makes a link stable is that nodes stay within radio range. > where the prefix stay with the link. But, in WAVE, we dont have that > router and so the question is what defines a link? Now, the second > part is about the prefixes? If the hosted prefix is a link-local > prefix FE80://, or a global prefix? A node is always moving between > links/subnets, without ever noticing that it changed the link. On another hand, I think a prefix is attached to an interface, not necessarily on a link. > Unless we throw some light on the above, any discussion on subnet > structure is incomplete IMO. The below text does not seem to be > addressing these points. Care to through some light with text you'd like to see in draft. Or maybe we learn to just live with the question. Alex From nobody Tue Sep 12 07:11:21 2017 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 CD3B61326DF for ; Tue, 12 Sep 2017 07:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 CxbHU4hsvwaa for ; Tue, 12 Sep 2017 07:11:17 -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 D786813305B for ; Tue, 12 Sep 2017 07:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5180; q=dns/txt; s=iport; t=1505225473; x=1506435073; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oUZgTskfxQukt8MWnjtd258tLQNKOS2dLsGQZpNzhbg=; b=hm5KBOJ0+3f8asIVIXYLvAC9R853FjCzvxzKIZGLJpeNyCVhDChzDkw5 OCXlH/7hx0fzQlE+iF4fFii9+tXrvM3PEsAA3pLci09wHUMKYocKFy2KJ 3OOhXeqotwO3iQOND3GYiigOI0hGzjoaO1cYHtoULQUu2R1jf9d9Gz2U/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAwCu6rdZ/40NJK1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNbZG4nB541gXSIOpAAChgLhRsChD1XAQIBAQEBAQJrKIUYAQE?= =?us-ascii?q?BBAEBbAsMBAIBCBEEAQEkBAchBgsUCQgCBAENBYoZAxUQrV+HNw2DbwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgyuCAoFQgWODKIJYgh+FdAWKBpYyPAKPWYR3knK?= =?us-ascii?q?MVogsAhEZAYE4AVeBDXcVSoUYHBmBDz92iHqBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,383,1500940800"; d="scan'208";a="2375942" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Sep 2017 14:10:55 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v8CEAtIH006432 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Sep 2017 14:10:55 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Sep 2017 09:10:54 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Tue, 12 Sep 2017 09:10:54 -0500 From: "Sri Gundavelli (sgundave)" To: "dickroy@alum.mit.edu" , "'Alexandre Petrescu'" , "its@ietf.org" CC: "wwhyte@onboardsecurity.com" Thread-Topic: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section Thread-Index: AQHTK9Dysp5l+xJufEyQP8ap6bny8w== Date: Tue, 12 Sep 2017 14:10:54 +0000 Message-ID: References: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> <7E28713FC0784C7E9253F6F5F66692E2@SRA6> In-Reply-To: <7E28713FC0784C7E9253F6F5F66692E2@SRA6> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: text/plain; charset="windows-1254" Content-ID: <2C22211D00E19E4387DE5B0F062C6ED4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:11:20 -0000 Hi Dick, Yes. The IETF version, or more precisely the concept of a =93link=94 that i= s implicitly present in IPv6 ND and other protocols. Regards Sri PS: It appears not all mails are showing up in the ITS archive, including this one. On 9/11/17, 6:22 PM, "Dick Roy" wrote: >H all, > >The real issue you do have to face is the one outlined by Sri below, that >being how to set up a local "link" with multiple mobile devices (e.g. >OBUs) >that are potentially in motion. This is what I was trying to explain >years >ago when I stressed the need for an ND-equivalent in very rapidly varying >network topologies. > >Note that while 1609 and friends have various definitions of "link", I >believe the one Sri is referring to is the IETF version which is that of a >collection of nodes (hosts and routers) that can communicate at layer 2 >and >below. =20 > >That said, the IETF link concept can still be found in ITS communications. >In ISO, the concept of an ITS-SU composed of many nodes (host and routers) >is alive and well. You will find pretty pictures of them in the annexes >of >ISO 21217! You can imagine use cases where nodes on these local networks >would like to communicate with similar nodes on other nearby networks >(e.g. >a back-seat host has a chat app and the kids want to video-chat with their >friends in the cars in our caravan to summer camp!). Here you have >several >static LANs (in the cars) that want to form a quasi-static (while we are >all >caravanning on the four hour trip to heaven (mom) / hell (dad):^) LAN (or >possibly a VLAN assuming we also have wide-area connectivity such as a 4G >interface or two), and the issues surrounding rapidly varying network >topology are not present while the ND issues are still present. > >Perhaps such use cases are useful... > >Cheers, > >RR =20 > > >-----Original Message----- >From: its [mailto:its-bounces@ietf.org] On Behalf Of Sri Gundavelli >(sgundave) >Sent: Monday, September 11, 2017 1:22 PM >To: Alexandre Petrescu >Cc: its@ietf.org >Subject: Re: [ipwave] Review comments on >draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section > >Hi Alex, > >> What kind of details would you see? Would you like to propose? > >Our starting point is still the link. Is there even possibility of >realizing a =93link=94 in this environment. For hosting a prefix, you need= a >link and when that link is based on dynamic grouping of random set of >802-11-OCB nodes, where the nodes are always changing groups, where is the >link. What defines a link? > >There is node mobility even in other types of wired/wireless links, but >the presence of a router on the link made a link a stable link where the >prefix stay with the link. But, in WAVE, we don=92t have that router and s= o >the question is what defines a link? Now, the second part is about the >prefixes? If the hosted prefix is a link-local prefix FE80://, or a >global prefix? A node is always moving between links/subnets, without ever >noticing that it changed the link. > >Unless we throw some light on the above, any discussion on subnet >structure is incomplete IMO. The below text does not seem to be addressing >these points. > > > >Sri > > > > > > >------------------------- > >5.6. Subnet Structure > > A subnet is formed by the external 802.11-OCB interfaces of vehicles > that are in close range (not their on-board interfaces). This > ephemeral subnet structure is strongly influenced by the mobility of > vehicles: the 802.11 hidden node effects appear. On another hand, > the structure of the internal subnets in each car is relatively > stable. > > For routing purposes, a prefix exchange mechanism could be needed > between neighboring vehicles. > > The 802.11 networks in OCB mode may be considered as 'ad-hoc' > networks. The addressing model for such networks is described in > [RFC5889]. > > An addressing model involves several types of addresses, like > Globally-unique Addresses (GUA), Link-Local Addresses (LL) and Unique > Local Addresses (ULA). The subnet structure in 'ad-hoc' networks may > have characteristics that lead to difficulty of using GUAs derived > from a received prefix, but the LL addresses may be easier to use > since the prefix is constant. > >----------------------------- > > > >On 9/11/17, 1:04 PM, "Alexandre Petrescu" >wrote: > >> >> >>Le 11/09/2017 =E0 05:58, Sri Gundavelli (sgundave) a =E9crit : >>[...] >> >>>>>> [Sri] Per my earlier comment, the link model, addressing ..etc needs >>>>>> to be explained in more detail. It is not clear what exactly the >>>>>> =B3subnet structure=B2 that is assumed in 802.11-OCB. >>>>> >>>>> Improved the subnet structure section. >>>=20 >>>=20 >>> May require few more details >> >>What kind of details would you see? Would you like to propose? >> >>Alex > >_______________________________________________ >its mailing list >its@ietf.org >https://www.ietf.org/mailman/listinfo/its > From nobody Tue Sep 12 07:17:43 2017 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 0ECC6133052 for ; Tue, 12 Sep 2017 07:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 zFXZcff9CwGL for ; Tue, 12 Sep 2017 07:17:40 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580EF1326DF for ; Tue, 12 Sep 2017 07:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3194; q=dns/txt; s=iport; t=1505225860; x=1506435460; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jkHsuHYOxdb+CkUV6WjHTqdJAIS8XdRmRUqEQpvjLpk=; b=lfJ4AAVATeusiMFeIMkqB/cJ31cSU/J+8/6hpxcB+ImMEM62jg2t7ldT DKByrmMFraAZLxNczR72rIGDfrqor6qsXbww9vJ5Xn5KRtQatXj+w/xXw aATWeynTs6Q21TB8i9VcVNa9cEUvK+eLQkarv3V/kQjLNrwvHshmgdIot I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAQAL7LdZ/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1uBUicHjhGQJIoujW4OLYFXCoU+AoQ+PxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?ZBnAJEAIBCEYhESUCBA4FihkDFa10hzcNg28BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEdgyuCAoFQgWODKIJYgWM8hXQBBKA4PAKPWYR3knKMVogsAhEZAYE4AR84gQ1?= =?us-ascii?q?3FYYXgU52iHqBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,383,1500940800"; d="scan'208";a="292520206" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2017 14:17:39 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v8CEHd0j007524 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Sep 2017 14:17:39 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Sep 2017 09:17:38 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Tue, 12 Sep 2017 09:17:38 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandre Petrescu CC: "its@ietf.org" Thread-Topic: Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section Thread-Index: AQHTK9HjJpIOCbfwc0SRIulLhBxx3g== Date: Tue, 12 Sep 2017 14:17:38 +0000 Message-ID: References: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1CB38E4A47FD504B96B3CF562CAA2C09@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:17:42 -0000 Hi Alex, Stepping away from the debates on the wordings or on semantics =8A the issu= e that I am raising is around ND. Before we can claim that IPv6 works on 802-11-OCB access, we need to make sure one can make ND work. That is the larger discussion point. I do realize there is text on the experimentation and packet captures of IPv6 packets on the 802.11-OCB medium, but I suspect that was in a contained environment, where two RSU=B9s with 802.11-OCB interfaces are sitting next to each other. I encourage repeating the same test with multiple RSU nodes and in a vehicular environment and see how the results compare. Its possible every thing works great and I may be missing something, but that is worth verifying it, IMO. Regards Sri On 9/11/17, 11:06 PM, "Alexandre Petrescu" wrote: > > >Le 11/09/2017 =E0 22:21, Sri Gundavelli (sgundave) a =E9crit : >> Hi Alex, >>=20 >>> What kind of details would you see? Would you like to propose? >>=20 >> Our starting point is still the link. Is there even possibility of >> realizing a =B3link=B2 in this environment. > >YEs, as pictured, two STAs next to each ohter have a link good enough >for IPv6 ND to work on it. > >Move them a little bit further from each other and there is no more link. > >I do not understand what do you mean by 'link'? > >> For hosting a prefix, you need a link and when that link is based on >> dynamic grouping of random set of 802-11-OCB nodes, where the nodes >> are always changing groups, where is the link. What defines a link? > >That's a good point, but do you think we can define a link in this >document? > >In OCB a 'link' is ephemeral: I see it created when a STA receives an NA >as response to its NS. Even then, after that reception we're not sure >the link is still there. Or it can. > >TCP will make sure that data gets across. > >In an RSU-to-OBUs communication there is a very stable link, as link as >these OBUs stay within the limits of coverage of that OBU. > >All this is also valid with WiFi links: ICB (_Inside_ the Context of a >BSS). > >> There is node mobility even in other types of wired/wireless links, >> but the presence of a router on the link made a link a stable link > >I dont think it's the router's presence that makes that link stable(?) >What makes a link stable is that nodes stay within radio range. > >> where the prefix stay with the link. But, in WAVE, we don=B9t have that >> router and so the question is what defines a link? Now, the second >> part is about the prefixes? If the hosted prefix is a link-local >> prefix FE80://, or a global prefix? A node is always moving between >> links/subnets, without ever noticing that it changed the link. > >On another hand, I think a prefix is attached to an interface, not >necessarily on a link. > >> Unless we throw some light on the above, any discussion on subnet >> structure is incomplete IMO. The below text does not seem to be >> addressing these points. > >Care to through some light with text you'd like to see in draft. > >Or maybe we learn to just live with the question. > >Alex From nobody Tue Sep 12 09:00:03 2017 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 1464C1326FE for ; Tue, 12 Sep 2017 09:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 D41Oeer3rJ7g for ; Tue, 12 Sep 2017 09:00:00 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 C006B126D0C for ; Tue, 12 Sep 2017 08:59:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8CFxtIj039108; Tue, 12 Sep 2017 17:59:55 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8DDB320B2D4; Tue, 12 Sep 2017 17:59:55 +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 80D0F20B222; Tue, 12 Sep 2017 17:59:55 +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 v8CFxtxp016785; Tue, 12 Sep 2017 17:59:55 +0200 To: "Sri Gundavelli (sgundave)" Cc: "its@ietf.org" References: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> From: Alexandre Petrescu Message-ID: <94edef24-fa85-24d1-0905-c29bfbd626d4@gmail.com> Date: Tue, 12 Sep 2017 17:59:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 16:00:02 -0000 Le 12/09/2017 16:17, Sri Gundavelli (sgundave) a crit : > Hi Alex, > > Stepping away from the debates on the wordings or on semantics the > issue that I am raising is around ND. Before we can claim that IPv6 > works on 802-11-OCB access, we need to make sure one can make ND > work. That is the larger discussion point. Agree, but can we go with the IP-over-OCB as it stands now or should we add/modify something in it? > I do realize there is text on the experimentation and packet captures > of IPv6 packets on the 802.11-OCB medium, but I suspect that was in a > contained environment, where two RSUs with 802.11-OCB interfaces are > sitting next to each other. It's not only packet captures and contained environments - we used IPv6, ND, and Mobile IPv6 on cars connecting to Road-Side Unit deployed at a particular parking and road that I could point. The issue was how OBU could measure the signal level of an RSU on OCB (to decide to hand over to it from 4G), because OCB has no Beacons. So we used Router Advertisements instead. And in the IP-over-OCB draft we do talk about what could be the handover indicators: RA, TSA, WRA. For Mobile IPv4 we used IPv4 Router Advertisements on OCB links - they work. We also performed a 'see-through' video-streaming on IPv6 on OCB between two vehicles following each other on road. The issue was how the IPv6 Ethernet camera from one vehicle could send UDPv6 packets to the Ethernet laptop inside the other car, through two IPv6 OBUs on OCB, w/o RSU. TO address that, we developped this prefix exchange mechanism with ND extensions on IPv6 over OCB. It worked fine. The issue was not the link, because the link is stable between two cars following each other. Others than what I claim, others used IP on OCB at other trials, on road (not on table). The distances are in the ranges of 10s of meters, 100s of meters. Measures were peformed. > I encourage repeating the same test with multiple RSU nodes and in a > vehicular environment and see how the results compare. YEs, thanks for encouragement. We and others have plans for that too. The issues that arise have to do with placement with RSUs, setting power levels, and deciding channel numbers. > Its possible every thing works great and I may be missing something, > but that is worth verifying it, IMO. Certainly yes worth verifying. What ND do you think will not work when two cars follow each other and stream one another's video? What ND do you think will not work when one car is handed over between rightly placed RSUs? Alex From nobody Tue Sep 12 09:22:41 2017 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 2EDE4133076 for ; Tue, 12 Sep 2017 09:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 hXtngNjlRAJo for ; Tue, 12 Sep 2017 09:22:38 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5411321B6 for ; Tue, 12 Sep 2017 09:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4180; q=dns/txt; s=iport; t=1505233358; x=1506442958; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pmSnybS+ubhjctm1Ph5P5AvXa4vIGGH0IGszlSY6zDg=; b=J0MS7m7VCt8T4Ws26dukgLARK7mdAMoPLCUSaDKgp475je2uMRcJTtdX o5/hvo8rSOH1b1nbTGckTNCLXlkihqMx4o/knsQBFTdSWJLnQ6ic2ee/Q 2sOtVsDC6trzfybkWOc7c8yHfaS/lJXK0NCEggoazz62RX8bwoFaXZtFm k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAwCNCLhZ/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1uBUicHg3CaRYF0iDqQAAqFPgIahCdXAQIBAQEBAQJrKIUZAQQ?= =?us-ascii?q?BIxE8CQULAgEIGgImAgICHxEVEAIEDgWKGQMNCKtjgieHNg2DcgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHoEOgh2CAoFQgWODKIJYggMcF4J8gmEFoDg8Ao9ZhHeScox?= =?us-ascii?q?WiCwCERkBgTgBV4ENdxWGF4FOdoh6gQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.42,383,1500940800"; d="scan'208";a="2442107" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Sep 2017 16:22:37 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8CGMb5S023715 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Sep 2017 16:22:37 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Sep 2017 11:22:36 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Tue, 12 Sep 2017 11:22:36 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandre Petrescu CC: "its@ietf.org" Thread-Topic: Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section Thread-Index: AQHTK+NYYUUXehT/uUiM9MeHwW95Mw== Date: Tue, 12 Sep 2017 16:22:36 +0000 Message-ID: References: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> <94edef24-fa85-24d1-0905-c29bfbd626d4@gmail.com> In-Reply-To: <94edef24-fa85-24d1-0905-c29bfbd626d4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 16:22:40 -0000 PiBBZ3JlZSwgYnV0IGNhbiB3ZSBnbyB3aXRoIHRoZSBJUC1vdmVyLU9DQiBhcyBpdCBzdGFuZHMg bm93IG9yIHNob3VsZCB3ZQ0KYWRkL21vZGlmeSBzb21ldGhpbmcgaW4gaXQ/DQoNCg0KSXQgaXMg eW91ciBjYWxsIGFuZCB1cCB0byB0aGUgY2hhaXJzLiBJIGFtIG5vdCBpbiB0aGUgYmxvY2tpbmcg cGF0aC4gQnV0LA0KSSBkbyBub3QgYmVsaWV2ZSBJRVNHIHdpbGwgYXBwcm92ZSB0aGlzIGluIHRo ZSBjdXJyZW50IGZvcm0uDQoNCg0KUmVnYXJkcw0KU3JpDQoNCg0KDQoNCk9uIDkvMTIvMTcsIDg6 NTkgQU0sICJBbGV4YW5kcmUgUGV0cmVzY3UiIDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29t Pg0Kd3JvdGU6DQoNCj5MZSAxMi8wOS8yMDE3IMOgIDE2OjE3LCBTcmkgR3VuZGF2ZWxsaSAoc2d1 bmRhdmUpIGEgw6ljcml0IDoNCj4+IEhpIEFsZXgsDQo+PiANCj4+IFN0ZXBwaW5nIGF3YXkgZnJv bSB0aGUgZGViYXRlcyBvbiB0aGUgd29yZGluZ3Mgb3Igb24gc2VtYW50aWNzIMWgIHRoZQ0KPj4g IGlzc3VlIHRoYXQgSSBhbSByYWlzaW5nIGlzIGFyb3VuZCBORC4gQmVmb3JlIHdlIGNhbiBjbGFp bSB0aGF0IElQdjYNCj4+ICB3b3JrcyBvbiA4MDItMTEtT0NCIGFjY2Vzcywgd2UgbmVlZCB0byBt YWtlIHN1cmUgb25lIGNhbiBtYWtlIE5EDQo+PiB3b3JrLiBUaGF0IGlzIHRoZSBsYXJnZXIgZGlz Y3Vzc2lvbiBwb2ludC4NCj4NCj5BZ3JlZSwgYnV0IGNhbiB3ZSBnbyB3aXRoIHRoZSBJUC1vdmVy LU9DQiBhcyBpdCBzdGFuZHMgbm93IG9yIHNob3VsZCB3ZQ0KPmFkZC9tb2RpZnkgc29tZXRoaW5n IGluIGl0Pw0KPg0KPj4gSSBkbyByZWFsaXplIHRoZXJlIGlzIHRleHQgb24gdGhlIGV4cGVyaW1l bnRhdGlvbiBhbmQgcGFja2V0IGNhcHR1cmVzDQo+PiBvZiBJUHY2IHBhY2tldHMgb24gdGhlIDgw Mi4xMS1PQ0IgbWVkaXVtLCBidXQgSSBzdXNwZWN0IHRoYXQgd2FzIGluIGENCj4+IGNvbnRhaW5l ZCBlbnZpcm9ubWVudCwgd2hlcmUgdHdvIFJTVcK5cyB3aXRoIDgwMi4xMS1PQ0IgaW50ZXJmYWNl cyBhcmUNCj4+IHNpdHRpbmcgbmV4dCB0byBlYWNoIG90aGVyLg0KPg0KPkl0J3Mgbm90IG9ubHkg cGFja2V0IGNhcHR1cmVzIGFuZCBjb250YWluZWQgZW52aXJvbm1lbnRzIC0gd2UgdXNlZCBJUHY2 LA0KPk5ELCBhbmQgTW9iaWxlIElQdjYgb24gY2FycyBjb25uZWN0aW5nIHRvIFJvYWQtU2lkZSBV bml0IGRlcGxveWVkIGF0IGENCj5wYXJ0aWN1bGFyIHBhcmtpbmcgYW5kIHJvYWQgdGhhdCBJIGNv dWxkIHBvaW50Lg0KPg0KPlRoZSBpc3N1ZSB3YXMgaG93IE9CVSBjb3VsZCBtZWFzdXJlIHRoZSBz aWduYWwgbGV2ZWwgb2YgYW4gUlNVIG9uIE9DQg0KPih0byBkZWNpZGUgdG8gaGFuZCBvdmVyIHRv IGl0IGZyb20gNEcpLCBiZWNhdXNlIE9DQiBoYXMgbm8gQmVhY29ucy4gIFNvDQo+d2UgdXNlZCBS b3V0ZXIgQWR2ZXJ0aXNlbWVudHMgaW5zdGVhZC4gIEFuZCBpbiB0aGUgSVAtb3Zlci1PQ0IgZHJh ZnQgd2UNCj5kbyB0YWxrIGFib3V0IHdoYXQgY291bGQgYmUgdGhlIGhhbmRvdmVyIGluZGljYXRv cnM6IFJBLCBUU0EsIFdSQS4NCj4gIEZvciBNb2JpbGUgSVB2NCB3ZSB1c2VkIElQdjQgUm91dGVy IEFkdmVydGlzZW1lbnRzIG9uIE9DQiBsaW5rcyAtIHRoZXkNCj53b3JrLg0KPg0KPldlIGFsc28g cGVyZm9ybWVkIGEgJ3NlZS10aHJvdWdoJyB2aWRlby1zdHJlYW1pbmcgb24gSVB2NiBvbiBPQ0IN Cj5iZXR3ZWVuIHR3byB2ZWhpY2xlcyBmb2xsb3dpbmcgZWFjaCBvdGhlciBvbiByb2FkLiAgIFRo ZSBpc3N1ZSB3YXMgaG93DQo+dGhlIElQdjYgRXRoZXJuZXQgY2FtZXJhIGZyb20gb25lIHZlaGlj bGUgY291bGQgc2VuZCBVRFB2NiBwYWNrZXRzIHRvDQo+dGhlIEV0aGVybmV0IGxhcHRvcCBpbnNp ZGUgdGhlIG90aGVyIGNhciwgdGhyb3VnaCB0d28gSVB2NiBPQlVzIG9uIE9DQiwNCj53L28gUlNV LiAgVE8gYWRkcmVzcyB0aGF0LCB3ZSBkZXZlbG9wcGVkIHRoaXMgcHJlZml4IGV4Y2hhbmdlIG1l Y2hhbmlzbQ0KPndpdGggTkQgZXh0ZW5zaW9ucyBvbiBJUHY2IG92ZXIgT0NCLiAgSXQgd29ya2Vk IGZpbmUuICBUaGUgaXNzdWUgd2FzIG5vdA0KPnRoZSBsaW5rLCBiZWNhdXNlIHRoZSBsaW5rIGlz IHN0YWJsZSBiZXR3ZWVuIHR3byBjYXJzIGZvbGxvd2luZyBlYWNoDQo+b3RoZXIuDQo+DQo+T3Ro ZXJzIHRoYW4gd2hhdCBJIGNsYWltLCBvdGhlcnMgdXNlZCBJUCBvbiBPQ0IgYXQgb3RoZXIgdHJp YWxzLCBvbiByb2FkDQo+KG5vdCBvbiB0YWJsZSkuDQo+DQo+VGhlIGRpc3RhbmNlcyBhcmUgaW4g dGhlIHJhbmdlcyBvZiAxMHMgb2YgbWV0ZXJzLCAxMDBzIG9mIG1ldGVycy4NCj5NZWFzdXJlcyB3 ZXJlIHBlZm9ybWVkLg0KPg0KPj4gSSBlbmNvdXJhZ2UgcmVwZWF0aW5nIHRoZSBzYW1lIHRlc3Qg d2l0aCBtdWx0aXBsZSBSU1Ugbm9kZXMgYW5kIGluIGENCj4+ICB2ZWhpY3VsYXIgZW52aXJvbm1l bnQgYW5kIHNlZSBob3cgdGhlIHJlc3VsdHMgY29tcGFyZS4NCj4NCj5ZRXMsIHRoYW5rcyBmb3Ig ZW5jb3VyYWdlbWVudC4gIFdlIGFuZCBvdGhlcnMgaGF2ZSBwbGFucyBmb3IgdGhhdCB0b28uDQo+ DQo+VGhlIGlzc3VlcyB0aGF0IGFyaXNlIGhhdmUgdG8gZG8gd2l0aCBwbGFjZW1lbnQgd2l0aCBS U1VzLCBzZXR0aW5nIHBvd2VyDQo+bGV2ZWxzLCBhbmQgZGVjaWRpbmcgY2hhbm5lbCBudW1iZXJz Lg0KPg0KPj4gSXRzIHBvc3NpYmxlIGV2ZXJ5IHRoaW5nIHdvcmtzIGdyZWF0IGFuZCBJIG1heSBi ZSBtaXNzaW5nIHNvbWV0aGluZywNCj4+IGJ1dCB0aGF0IGlzIHdvcnRoIHZlcmlmeWluZyBpdCwg SU1PLg0KPg0KPkNlcnRhaW5seSB5ZXMgd29ydGggdmVyaWZ5aW5nLg0KPg0KPldoYXQgTkQgZG8g eW91IHRoaW5rIHdpbGwgbm90IHdvcmsgd2hlbiB0d28gY2FycyBmb2xsb3cgZWFjaCBvdGhlciBh bmQNCj5zdHJlYW0gb25lIGFub3RoZXIncyB2aWRlbz8NCj4NCj5XaGF0IE5EIGRvIHlvdSB0aGlu ayB3aWxsIG5vdCB3b3JrIHdoZW4gb25lIGNhciBpcyBoYW5kZWQgb3ZlciBiZXR3ZWVuDQo+cmln aHRseSBwbGFjZWQgUlNVcz8NCj4NCj5BbGV4DQoNCg== From nobody Tue Sep 12 09:27:22 2017 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 4E7BB133075 for ; Tue, 12 Sep 2017 09:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 sCgtrTL5VQdV for ; Tue, 12 Sep 2017 09:27:18 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (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 AA718132D67 for ; Tue, 12 Sep 2017 09:27:18 -0700 (PDT) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-12v.sys.comcast.net with ESMTP id ro0ddfOBvPs3Pro1udSekS; Tue, 12 Sep 2017 16:27:18 +0000 Received: from [192.168.1.19] ([67.188.94.126]) by resomta-po-02v.sys.comcast.net with SMTP id ro1td3uoXVLADro1td2Xrb; Tue, 12 Sep 2017 16:27:18 +0000 From: Tony Li Message-Id: <7F94E3D3-36E9-4D1F-8F58-A1435405E6C3@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_EA517BD8-BE4F-4705-BDB9-46CB1174934D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 12 Sep 2017 09:27:16 -0700 In-Reply-To: Cc: Alexandre Petrescu , "its@ietf.org" To: "Sri Gundavelli (sgundave)" References: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> <94edef24-fa85-24d1-0905-c29bfbd626d4@gmail.com> X-Mailer: Apple Mail (2.3273) X-CMAE-Envelope: MS4wfMfyrhxldtRs3gkXjflBqAHd1mpZOPQKR+2UXZSQpeDLnycr3lUM8IjybNS4L9LAiGeWuGfQXrB2aWoLePncPtvo9ine1byKRm1ZVnUnLEIzXb5Zo/Ap mYMLTMTYmtKe5c2V8+7GrozR6iK02dXZaNPjy4SO7Mz6lzHlO4BlThPkTfI8ogPfSEvnAR2/xnoyjsMrpCtPyXgk1gL7teV0VOM9FO0Ap/gK4NopyeJAGnUZ Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 16:27:20 -0000 --Apple-Mail=_EA517BD8-BE4F-4705-BDB9-46CB1174934D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 12, 2017, at 9:22 AM, Sri Gundavelli (sgundave) = wrote: >=20 > It is your call and up to the chairs. I am not in the blocking path. = But, > I do not believe IESG will approve this in the current form. I think you overestimate the IESG. They will pretty much approve = anything that is reasonably clean and has WG consensus. They do not spend a lot of time worrying about wording details, = especially on concepts that are well grounded already. Tony --Apple-Mail=_EA517BD8-BE4F-4705-BDB9-46CB1174934D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Sep 12, 2017, at 9:22 AM, Sri Gundavelli (sgundave) <sgundave@cisco.com> = wrote:

It is your call and up to the = chairs. I am not in the blocking path. But,
I do not believe IESG will approve this in the = current form.


I think = you overestimate the IESG. They will pretty much approve anything that = is reasonably clean and has WG consensus.

They do not spend a lot of time = worrying about wording details, especially on concepts that are well = grounded already.

Tony

= --Apple-Mail=_EA517BD8-BE4F-4705-BDB9-46CB1174934D-- From nobody Tue Sep 12 09:32:50 2017 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 CD41313307D for ; Tue, 12 Sep 2017 09:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 04uvJkU0PycG for ; Tue, 12 Sep 2017 09:32:48 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89914133076 for ; Tue, 12 Sep 2017 09:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5742; q=dns/txt; s=iport; t=1505233968; x=1506443568; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sEysg2h+ZUn0+DB9tW1JzHPOKXX81HzvkRDutOEo6+k=; b=SK46IkaFW4CGEgPl+EVpjreZ62vXoWSzKmeBmzFqxoZEq+/Foem3NouG cCToh0nCkZOFe/MqE2Hk+fc2xLlDHRUqL9mbhFEUvPIjMe1u9aEb95n+/ qbZqpGFUUdtRclqjYHNb2wlXHhQvUuM8kJt+yftEznywDntnjvhECSwr+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAwBjC7hZ/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnBrgVInB541gXSIOogvhT+CEgqFPgKEQUAXAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQMBeQULAgEIEQMBAiQEByERFAkIAgQOBYlNTAMNCK4GhzYNg3IBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgyuCAoFQgWODKIJYgj+FVAWgODwCj1mEd5JyjFa?= =?us-ascii?q?ILAIRGQGBOAEhATWBDXcVhheBTnaIeoEPAQEB?= X-IronPort-AV: E=Sophos; i="5.42,383,1500940800"; d="scan'208,217"; a="76486613" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2017 16:32:47 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v8CGWlVV019067 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Sep 2017 16:32:47 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Sep 2017 11:32:46 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Tue, 12 Sep 2017 11:32:46 -0500 From: "Sri Gundavelli (sgundave)" To: Tony Li CC: Alexandre Petrescu , "its@ietf.org" Thread-Topic: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section Thread-Index: AQHTK+TEG+/rm3I4RkCLJodF6YK/3Q== Date: Tue, 12 Sep 2017 16:32:46 +0000 Message-ID: References: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> <94edef24-fa85-24d1-0905-c29bfbd626d4@gmail.com> <7F94E3D3-36E9-4D1F-8F58-A1435405E6C3@tony.li> In-Reply-To: <7F94E3D3-36E9-4D1F-8F58-A1435405E6C3@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: multipart/alternative; boundary="_000_D5DD5A6028A1E9sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 16:32:50 -0000 --_000_D5DD5A6028A1E9sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > They will pretty much approve anything that is reasonably clean and has W= G consensus. Ok! You can give it a try. Sri From: its > on behalf of = Tony Li > Date: Tuesday, September 12, 2017 at 9:27 AM To: Sri Gundavelli > Cc: Alexandre Petrescu >, "its@ietf.org" > Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211o= cb-04.txt - subnet structure section On Sep 12, 2017, at 9:22 AM, Sri Gundavelli (sgundave) > wrote: It is your call and up to the chairs. I am not in the blocking path. But, I do not believe IESG will approve this in the current form. I think you overestimate the IESG. They will pretty much approve anything t= hat is reasonably clean and has WG consensus. They do not spend a lot of time worrying about wording details, especially = on concepts that are well grounded already. Tony --_000_D5DD5A6028A1E9sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <86DC8C239EC43A479C9552FE588DD6BB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
> They will pretty much approve anything that is reasonably clean a= nd has WG consensus.

Ok! You can give it a try.

Sri

From: its <its-bounces@ietf.org> on behalf of Tony Li <tony.li@tony.li>
Date: Tuesday, September 12, 2017 a= t 9:27 AM
To: Sri Gundavelli <sgundave@cisco.com>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com&g= t;, "its@ietf.org" <its@ietf.org>
Subject: Re: [ipwave] Review commen= ts on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure sectio= n


On Sep 12, 2017, at 9:22 AM, Sri Gundavelli (sgundave) <= sgundave@cisco.com>= wrote:

It is your call and up to the chairs. I am not in the blocking path. But,
I do not believe IESG will approve this in the current form.


I think you overestimate the IESG. They will pretty much ap= prove anything that is reasonably clean and has WG consensus.

They do not spend a lot of time worrying about wording deta= ils, especially on concepts that are well grounded already.

Tony

 --_000_D5DD5A6028A1E9sgundaveciscocom_-- From nobody Tue Sep 12 10:03:21 2017 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 20709132EC1 for ; Tue, 12 Sep 2017 10:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 lOZBX0qVJzgC for ; Tue, 12 Sep 2017 10:03:17 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 B0DC6132D79 for ; Tue, 12 Sep 2017 10:03:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8CH3A8t043289; Tue, 12 Sep 2017 19:03:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 978CB20B49C; Tue, 12 Sep 2017 19:03:10 +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 852612017D3; Tue, 12 Sep 2017 19:03:10 +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 v8CH3AHd028265; Tue, 12 Sep 2017 19:03:10 +0200 To: "Sri Gundavelli (sgundave)" , "dickroy@alum.mit.edu" , "its@ietf.org" Cc: "wwhyte@onboardsecurity.com" References: <18d3c5b2-99c4-256d-6887-678d3230cbc6@gmail.com> <7E28713FC0784C7E9253F6F5F66692E2@SRA6> From: Alexandre Petrescu Message-ID: <088672d8-6c67-526c-be98-ade3803cb4cd@gmail.com> Date: Tue, 12 Sep 2017 19:03:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 17:03:19 -0000 Sri, Dick's emails dont appear in archive. Yours do. The issue with emails from Dick have to do about masquerading somewhere, and security. IETF ticketing tried looked at it a few months back. There is still internal debate about whose fault is it. Alex Le 12/09/2017 16:10, Sri Gundavelli (sgundave) a crit: > > Hi Dick, > > > Yes. The IETF version, or more precisely the concept of a link that is > implicitly present in IPv6 ND and other protocols. > > Regards > Sri > PS: It appears not all mails are showing up in the ITS archive, including > this one. > > > > > > > > On 9/11/17, 6:22 PM, "Dick Roy" wrote: > >> H all, >> >> The real issue you do have to face is the one outlined by Sri below, that >> being how to set up a local "link" with multiple mobile devices (e.g. >> OBUs) >> that are potentially in motion. This is what I was trying to explain >> years >> ago when I stressed the need for an ND-equivalent in very rapidly varying >> network topologies. >> >> Note that while 1609 and friends have various definitions of "link", I >> believe the one Sri is referring to is the IETF version which is that of a >> collection of nodes (hosts and routers) that can communicate at layer 2 >> and >> below. >> >> That said, the IETF link concept can still be found in ITS communications. >> In ISO, the concept of an ITS-SU composed of many nodes (host and routers) >> is alive and well. You will find pretty pictures of them in the annexes >> of >> ISO 21217! You can imagine use cases where nodes on these local networks >> would like to communicate with similar nodes on other nearby networks >> (e.g. >> a back-seat host has a chat app and the kids want to video-chat with their >> friends in the cars in our caravan to summer camp!). Here you have >> several >> static LANs (in the cars) that want to form a quasi-static (while we are >> all >> caravanning on the four hour trip to heaven (mom) / hell (dad):^) LAN (or >> possibly a VLAN assuming we also have wide-area connectivity such as a 4G >> interface or two), and the issues surrounding rapidly varying network >> topology are not present while the ND issues are still present. >> >> Perhaps such use cases are useful... >> >> Cheers, >> >> RR >> >> >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Sri Gundavelli >> (sgundave) >> Sent: Monday, September 11, 2017 1:22 PM >> To: Alexandre Petrescu >> Cc: its@ietf.org >> Subject: Re: [ipwave] Review comments on >> draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section >> >> Hi Alex, >> >>> What kind of details would you see? Would you like to propose? >> >> Our starting point is still the link. Is there even possibility of >> realizing a link in this environment. For hosting a prefix, you need a >> link and when that link is based on dynamic grouping of random set of >> 802-11-OCB nodes, where the nodes are always changing groups, where is the >> link. What defines a link? >> >> There is node mobility even in other types of wired/wireless links, but >> the presence of a router on the link made a link a stable link where the >> prefix stay with the link. But, in WAVE, we dont have that router and so >> the question is what defines a link? Now, the second part is about the >> prefixes? If the hosted prefix is a link-local prefix FE80://, or a >> global prefix? A node is always moving between links/subnets, without ever >> noticing that it changed the link. >> >> Unless we throw some light on the above, any discussion on subnet >> structure is incomplete IMO. The below text does not seem to be addressing >> these points. >> >> >> >> Sri >> >> >> >> >> >> >> ------------------------- >> >> 5.6. Subnet Structure >> >> A subnet is formed by the external 802.11-OCB interfaces of vehicles >> that are in close range (not their on-board interfaces). This >> ephemeral subnet structure is strongly influenced by the mobility of >> vehicles: the 802.11 hidden node effects appear. On another hand, >> the structure of the internal subnets in each car is relatively >> stable. >> >> For routing purposes, a prefix exchange mechanism could be needed >> between neighboring vehicles. >> >> The 802.11 networks in OCB mode may be considered as 'ad-hoc' >> networks. The addressing model for such networks is described in >> [RFC5889]. >> >> An addressing model involves several types of addresses, like >> Globally-unique Addresses (GUA), Link-Local Addresses (LL) and Unique >> Local Addresses (ULA). The subnet structure in 'ad-hoc' networks may >> have characteristics that lead to difficulty of using GUAs derived >> from a received prefix, but the LL addresses may be easier to use >> since the prefix is constant. >> >> ----------------------------- >> >> >> >> On 9/11/17, 1:04 PM, "Alexandre Petrescu" >> wrote: >> >>> >>> >>> Le 11/09/2017 05:58, Sri Gundavelli (sgundave) a crit : >>> [...] >>> >>>>>>> [Sri] Per my earlier comment, the link model, addressing ..etc needs >>>>>>> to be explained in more detail. It is not clear what exactly the >>>>>>> subnet structure that is assumed in 802.11-OCB. >>>>>> >>>>>> Improved the subnet structure section. >>>> >>>> >>>> May require few more details >>> >>> What kind of details would you see? Would you like to propose? >>> >>> Alex >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > > From nobody Tue Sep 12 10:21:39 2017 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 6F01A132ED2 for ; Tue, 12 Sep 2017 10:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 zOxLHW5LHUPu for ; Tue, 12 Sep 2017 10:21:36 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 8C8AA132EA7 for ; Tue, 12 Sep 2017 10:21:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8CHLWoh059593; Tue, 12 Sep 2017 19:21:32 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F3FF620B4E7; Tue, 12 Sep 2017 19:21:31 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DD1EC20B4B4; Tue, 12 Sep 2017 19:21:31 +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 v8CHLVC3007088; Tue, 12 Sep 2017 19:21:31 +0200 To: "Sri Gundavelli (sgundave)" , "its@ietf.org" References: From: Alexandre Petrescu Message-ID: Date: Tue, 12 Sep 2017 19:21:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - multicast address mappping on unicast - WiFi? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 17:21:38 -0000 Le 27/08/2017 16:44, Sri Gundavelli (sgundave) a crit: [...] > An IPv6 packet with a multicast destination address DST, consisting > of the sixteen octets DST[1] through DST[16], is transmitted to the > IEEE 802.11-OCB MAC multicast address whose first two octets are the > value 0x3333 and whose last four octets are the last four octets of > DST. > > [Sri] Please add a reference to Section 7, RFC4861 and also RFC6085. In > general, for both unicast and multicast, you may want to clearly say > that this is per the existing specs and duplicated here for convenience. RFC6085 tells there are some circumstances where a mcast IP address maps into a link-layer unicast address (instead of multicast link-layer address). Was that test on wired Ethernet 802.3 or on WiFi 802.11? Does that apply to 802.11-OCB. Depending on that I can add a reference to 6085. Alex From nobody Tue Sep 12 10:26:13 2017 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0A1132EA7; Tue, 12 Sep 2017 10:26:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150523716485.17906.11754896720939607569@ietfa.amsl.com> Date: Tue, 12 Sep 2017 10:26:04 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-06.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 17:26:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Alexandre Petrescu Nabil Benamar Jérôme Härri Christian Huitema Jong-Hyouk Lee Thierry Ernst Tony Li Filename : draft-ietf-ipwave-ipv6-over-80211ocb-06.txt Pages : 38 Date : 2017-09-12 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks run outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. In addition, the document lists what is different in 802.11-OCB (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, where IPv6 protocols operate without issues. Most notably, the operation outside the context of a BSS (OCB) has impact on IPv6 handover behaviour and on IPv6 security. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-06 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-06 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/ From nobody Tue Sep 12 10:29:43 2017 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 1D55B1330AC for ; Tue, 12 Sep 2017 10:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, 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 2v63Mbj6ujyk for ; Tue, 12 Sep 2017 10:29:31 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 731921330AB for ; Tue, 12 Sep 2017 10:29:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8CHTT2S001320 for ; Tue, 12 Sep 2017 19:29:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D303620B4D3 for ; Tue, 12 Sep 2017 19:29:29 +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 C77B820B437 for ; Tue, 12 Sep 2017 19:29:29 +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 v8CHTSSO011715 for ; Tue, 12 Sep 2017 19:29:29 +0200 References: <150523716506.17906.11734214091595214400.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <150523716506.17906.11734214091595214400.idtracker@ietfa.amsl.com> Message-ID: <1d0ce998-ca2c-0d8e-f336-3b31eaa08f2a@gmail.com> Date: Tue, 12 Sep 2017 19:29:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150523716506.17906.11734214091595214400.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------B6E206C39A469C09D53CEA1B" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-06.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 17:29:42 -0000 This is a multi-part message in MIME format. --------------B6E206C39A469C09D53CEA1B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This is the changelog    o  Updated references of 802.11-OCB document from -2012 to the IEEE       802.11-2016.    o  In the LL address section, and in SLAAC section, added text and refs       to 7217 opaque IIDs and 8064 stable IIDs. I am waiting for a confirmation whether RFC6085 applies to 802.11-OCB too (or just to EThenret 802.3); depending on that I may add a reference to RFC6085 too. Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-06.txt Date : Tue, 12 Sep 2017 10:26:05 -0700 De : internet-drafts@ietf.org Pour : Nabil Benamar , Christian Huitema , Jong-Hyouk Lee , Jérôme Härri , Alexandre Petrescu , Tony Li , Alexandre Petrescu , Jerome Haerri , Thierry Ernst , ipwave-chairs@ietf.org A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-06.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 06 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Document date: 2017-09-12 Group: ipwave Pages: 38 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-06 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-06 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks run outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. In addition, the document lists what is different in 802.11-OCB (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, where IPv6 protocols operate without issues. Most notably, the operation outside the context of a BSS (OCB) has impact on IPv6 handover behaviour and on IPv6 security. 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 --------------B6E206C39A469C09D53CEA1B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This is the changelog

   o  Updated references of 802.11-OCB document from -2012 to the IEEE
      802.11-2016.

   o  In the LL address section, and in SLAAC section, added text and refs
      to 7217 opaque IIDs and 8064 stable IIDs.

I am waiting for a confirmation whether RFC6085 applies to 802.11-OCB too (or just to EThenret 802.3); depending on that I may add a reference to RFC6085 too.

Alex



-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-06.txt
Date : Tue, 12 Sep 2017 10:26:05 -0700
De : internet-drafts@ietf.org
Pour : Nabil Benamar <benamar73@gmail.com>, Christian Huitema <huitema@huitema.net>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr>, Jérôme Härri <Jerome.Haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Tony Li <tony.li@tony.li>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Jerome Haerri <jerome.haerri@eurecom.fr>, Thierry Ernst <thierry.ernst@yogoko.fr>, ipwave-chairs@ietf.org 


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

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	06
Title:		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:	2017-09-12
Group:		ipwave
Pages:		38
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-06.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-06
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-06
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-06

Abstract:
   In order to transmit IPv6 packets on IEEE 802.11 networks run outside
   the context of a basic service set (OCB, earlier "802.11p") there is
   a need to define a few parameters such as the supported Maximum
   Transmission Unit size on the 802.11-OCB link, the header format
   preceding the IPv6 header, the Type value within it, and others.
   This document describes these parameters for IPv6 and IEEE 802.11-OCB
   networks; it portrays the layering of IPv6 on 802.11-OCB similarly to
   other known 802.11 and Ethernet layers - by using an Ethernet
   Adaptation Layer.

   In addition, the document lists what is different in 802.11-OCB
   (802.11p) links compared to more 'traditional' 802.11a/b/g/n links,
   where IPv6 protocols operate without issues.  Most notably, the
   operation outside the context of a BSS (OCB) has impact on IPv6
   handover behaviour and on IPv6 security.

                                                                                  


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
--------------B6E206C39A469C09D53CEA1B-- From nobody Tue Sep 12 17:33:34 2017 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 AAC671331BA for ; Tue, 12 Sep 2017 17:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 DWgCdctbx_Hp for ; Tue, 12 Sep 2017 17:33:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708DF1331BB for ; Tue, 12 Sep 2017 17:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=506; q=dns/txt; s=iport; t=1505262812; x=1506472412; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7ZNokn6aZ7kKjRZXdHqR3R+mYIWcQW3Hw1J6RwouNjE=; b=EU9nJITa7uluWH3XX/pM6z7ccZ970/6m6/1+zKatu9DYVQX1Otinu21r /wvnK+vm2StARBVwqMOwJkINnVU0ZulSZayumTjHjS502B8GMbgTl1f0I BIy39w42QhwZ76G1b04EZ0lORjkWOJlwsbRZEGNufyDskcjRpcPa4mJqn 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C0AAC9e7hZ/5ldJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBUicHjhGQJYoujW6CEgqFPgKERD8YAQIBAQEBAQEBayiFGQa?= =?us-ascii?q?BCQIBCDsLIRElAgQBEooZAxWubIc3DYN2AQEBAQEBAQECAQEBAQEBAQEBH4Mrg?= =?us-ascii?q?gKBUIULgliIEwEEkXKORjwCj1mEd4F7kHeMVogsAhEZAYE4AR84gQ13FYYXgU5?= =?us-ascii?q?2iHeBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,384,1500940800"; d="scan'208";a="292445437" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2017 00:33:31 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8D0XVRu029773 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Sep 2017 00:33:31 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Sep 2017 19:33:31 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Tue, 12 Sep 2017 19:33:31 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandre Petrescu , "its@ietf.org" Thread-Topic: Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - multicast address mappping on unicast - WiFi? Thread-Index: AQHTLCfsCKZlLd1sDUG6UQW8XOEwow== Date: Wed, 13 Sep 2017 00:33:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - multicast address mappping on unicast - WiFi? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 00:33:34 -0000 Hi Alex, On 9/12/17, 10:21 AM, "Alexandre Petrescu" wrote: > > >Was that test on wired Ethernet 802.3 or on WiFi 802.11? > >Does that apply to 802.11-OCB. > >Depending on that I can add a reference to 6085. This will be relevant in the V2I context where there is a router sending IPv6 RA=B9s. But, we have not had any discussions on that entire topic and so many things are not clear for me. So, I am OK to leave the reference out for now. Sri From nobody Wed Sep 13 00:30:32 2017 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 C99951341D7 for ; Wed, 13 Sep 2017 00:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Gkz41c9-WMem for ; Wed, 13 Sep 2017 00:30:24 -0700 (PDT) Received: from xenon41.um.es (xenon41.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id BCD9313303F for ; Wed, 13 Sep 2017 00:30:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id B171220237; Wed, 13 Sep 2017 09:30:21 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon41.um.es Received: from xenon41.um.es ([127.0.0.1]) by localhost (xenon41.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MryMWEHnib6d; Wed, 13 Sep 2017 09:30:21 +0200 (CEST) Received: from falamo-236-191.inf.um.es (falamo-236-191.inf.um.es [155.54.236.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: josesanta) by xenon41.um.es (Postfix) with ESMTPSA id 6940F2005B; Wed, 13 Sep 2017 09:30:20 +0200 (CEST) From: =?utf-8?Q?Jos=C3=A9_Santa_Lozano?= Message-Id: <87F29D79-A641-46ED-BED3-994A4375F8D4@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_12F71741-A45F-4D93-80DE-65881F89AC3D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Sep 2017 09:30:19 +0200 In-Reply-To: <116eeef6-83fb-0f5d-94ae-1ec58bcafada@cea.fr> Cc: its@ietf.org To: Alexandre PETRESCU References: <58D01021-E27E-44AC-BCDD-31800CDE38E4@um.es> <116eeef6-83fb-0f5d-94ae-1ec58bcafada@cea.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] Comments on draft-ietf-ipwave-ipv6-over-80211ocb-04 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 07:30:32 -0000 --Apple-Mail=_12F71741-A45F-4D93-80DE-65881F89AC3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Alexandre, Thanks for the clarifications and for applying the changes. Now the = document is in a better shape. Regards, Jose. > El 10 sept 2017, a las 16:00, Alexandre PETRESCU = escribi=C3=B3: >=20 > Hi Jos=C3=A9, >=20 > The comments helped improve the document. >=20 > You raise a question that I answer here. >=20 > Draft says: >=20 >> At the time of writing, the prohibition is explicit at higher >> layer protocols providing services to the application; these >> higher layer protocols are specified in IEEE 1609 documents. >=20 > Jos=C3=A9 said: >> Do you refer here to he WAVE stack, or this statement is also true = for the European case? >=20 > Yes, the text refers to WAVE stack because it says IEEE 1609. >=20 > For the European case: I heard people saying IPv6 is forbidden on the = control channel. But > I could not find a standardised agreed reference to that. Countries = restrict the control channel to "safety" use, > yet countries dont talk about forbidding IPv6 explicitely. This can = easily let think that in Europe > IPv6-used-as-safety is not forbidden on the control channel. >=20 > In Europe, some people say that IPv6 _is_ allowed on the CCH, _if_ it = runs on GeoNetworking. But > the country frequency regulators dont talk about GeoNetworking at all. >=20 > In America IEEE 1609 they say explicitly IPv6 forbidden on control = channel. But the FCC doesnt say so. >=20 > Add to that: the control channel value in terms of mega Hertz in = America is different than in Europe. > The channel considered as CCH in America falls in an SCH in Europe = (service channel). In that sense > one could say that where IPv6 is forbidden in America, is explicitely = permitted in Europe. >=20 > This makes little sense. Ideally, there would be one control channel = number in terms of mega Hertz > both in America and in Europe _and_ IPv6 would not be forbidden there. = But still restrict the > use of that channel to more like "safety". That "safety" could easily = be implemented in IPv6: it's > a Traffic Class, or a Flow Label, and in 802.11 it's also a "Traffic = Something". >=20 > Because of this doubt, I prefer to keep the text as is, and just add = "WAVE stack". >=20 > Draft says: >> Other aspects particular to 802.11-OCB which are also particular to >> 802.11 (e.g. the =E2=80=99hidden node=E2=80=99 operation) may have an = influence on >> the use of transmission of IPv6 packets on 802.11-OCB networks. The >> subnet structure which may be assumed in 802.11-OCB networks is >> strongly influenced by the mobility of vehicles. >=20 > Jos=C3=A9 says: >> ... but, for this reason there exist solutions like NEMO, isn't it? = I am not sure if you refer here to the posibility of an in-vehicle = network movement. >=20 >=20 > I reformulated to mean the car-external subnet. The NEMO protocols = deals with the in-vehicle stable network. > Mobile IPv6 and its handover management mechanism deal with such = varying subnet structure, but only when there > is an RSU. In this document we dont deal with handover, nor Mobile = IPv6, nor NEMO - it's other documents. >=20 > Draft says: >> There are considerations for 2 or more IEEE 802.11-OCB interface >> cards per vehicle. >=20 > Jos=C3=A9 says: >> or a transceiver supporting more than one channnel to be used = simultaneously. >=20 > There are no 802.11-OCB transceivers that can use more than one = channel simultaneously. So I dont include that text. >=20 > Yours, > -- > Alexandre Petrescu > alexandre.petrescu@cea.fr , t=C3=A9l = 0169089223 >=20 > Le 07/09/2017 =C3=A0 17:20, Jos=C3=A9 Santa Lozano a =C3=A9crit : >> Dear all, >>=20 >> Please, find attached a list of comments and suggestions embedded in = a PDF document of the draft, with the aim of make easier their = following. >>=20 >> Expecting that they result of interest and help. >>=20 >> Regards, >>=20 >>=20 >> --=20 >> Jos=C3=A9 Santa Lozano >> Department of Information and Communication Engineering >> Faculty of Computer Science >> University of Murcia >> 30100 Murcia, Spain >> Phone: +34-868-884616 / +34-868-884455 >> Fax: +34-868-884151 >> Web: http://ants.inf.um.es/~josesanta = >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_12F71741-A45F-4D93-80DE-65881F89AC3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Alexandre,

Thanks for the clarifications and for applying the changes. = Now the document is in a better shape.

Regards,

Jose.




El 10 sept 2017, a las 16:00, Alexandre PETRESCU <alexandre.petrescu@cea.fr> escribi=C3=B3:

=20 =20

Hi = Jos=C3=A9,

The comments helped improve the document.

You raise a = question that I answer here.

Draft = says:

At the time of writing, the = prohibition is explicit at higher
layer protocols providing services to the application; = these
higher layer protocols are specified in IEEE 1609 = documents.

Jos=C3=A9 said:
Do you refer here to he = WAVE stack, or this statement is also true for the European = case?

Yes, the text refers to WAVE stack because it says IEEE 1609.

For the European case: I heard people saying IPv6 is forbidden on the control channel.  But
I could not find a standardised agreed reference to that.  Countries restrict the control channel to "safety" use,
yet countries dont talk about forbidding IPv6 explicitely.  = This can easily let think that in Europe
IPv6-used-as-safety is not forbidden on the control channel.

In Europe, some people say that IPv6 _is_ allowed on the CCH, _if_ it runs on GeoNetworking.  But
the country frequency regulators dont talk about GeoNetworking at all.

In America IEEE 1609 they say explicitly IPv6 forbidden on control channel.  But the FCC doesnt say so.

Add to that: the control channel value in terms of mega Hertz in America is different than in Europe.
The channel considered as CCH in America falls in an SCH in Europe (service channel).  In that sense
one could say that where IPv6 is forbidden in America, is explicitely permitted in Europe.

This makes little sense.  Ideally, there would be one = control channel number in terms of mega Hertz
both in America and in Europe _and_ IPv6 would not be forbidden there.  But still restrict the
use of that channel to more like "safety".  That "safety" = could easily be implemented in IPv6: it's
a Traffic Class, or a Flow Label, and in 802.11 it's also a "Traffic Something".

Because of this doubt, I prefer to keep the text as is, and just add "WAVE stack".

Draft says:
Other aspects particular to = 802.11-OCB which are also particular to
802.11 (e.g. the =E2=80=99hidden node=E2=80=99 operation) may = have an influence on
the use of transmission of IPv6 packets on 802.11-OCB networks. The
subnet structure which may be assumed in 802.11-OCB networks is
strongly influenced by the mobility of vehicles.

Jos=C3=A9 says:
... but, for this reason = there exist solutions like  NEMO, isn't it? I am not sure if you = refer here to the posibility of an in-vehicle network = movement.


I reformulated to mean the car-external subnet.  The NEMO protocols deals with the in-vehicle stable network.
= Mobile IPv6 and its handover management mechanism deal with such varying subnet structure, but only when there
is an RSU.  In this document we dont deal with handover, = nor Mobile IPv6, nor NEMO - it's other documents.

Draft says:
There are considerations = for 2 or more IEEE 802.11-OCB interface
cards per vehicle.

Jos=C3=A9 says:
or a transceiver supporting = more than one channnel to be used simultaneously.

There are no 802.11-OCB transceivers that can use more than one channel simultaneously.  So I dont include that text.

Yours,

--
Alexandre Petrescu
alexandre.petrescu@cea.fr, =
t=C3=A9l 0169089223
Le 07/09/2017 =C3=A0 17:20, Jos=C3=A9 = Santa Lozano a =C3=A9crit :
Dear all,

Please, find attached a list of comments and suggestions embedded in a PDF document of the draft, with the aim of make easier their following.

Expecting that they result of interest and = help.

Regards,


-- 
Jos=C3=A9 Santa Lozano
Department of Information and Communication = Engineering
Faculty of Computer Science
University of Murcia
30100 Murcia, Spain
Phone: +34-868-884616 / +34-868-884455
Fax: +34-868-884151
Web: http://ants.inf.um.es/~josesanta







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

= --Apple-Mail=_12F71741-A45F-4D93-80DE-65881F89AC3D-- From nobody Wed Sep 13 09:28:20 2017 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 56A41133175 for ; Wed, 13 Sep 2017 09:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=niclabs-cl.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 cRfmFs_mVhpO for ; Wed, 13 Sep 2017 09:28:15 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 1B45613305E for ; Wed, 13 Sep 2017 09:28:14 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id b1so1815460qtc.4 for ; Wed, 13 Sep 2017 09:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niclabs-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bQrmE0h0hi/sAhvTLnpixD2vkwmKFd1GI9WxzdQSXN0=; b=h/qNsS051hEaflpjeO7IJni+NYL/SZp4YMjsLYJZkySDlq73PWqVmtgGD1PP2LtZ7M 5H1C9nACB4naqc7p19GEk8HYaPLh33pjrVrMs3qMdAwo2zUHd9q4mH+yrCyH398bbnfP RT6kpZbEAONWGEb/VPlMWP6OP0LcKHCkBMZ52j2TPr3pgjHCrMyylqkYP5cAiKFhpQJM r94CfpKkJZAkry4f8E37trw+/5NXO/+mv/+WdZeFzXs9+NB3JpiUIrw75WPNySP2DRPq J6JL/oTmMgn6umnKg0GqoUM9pPB5VXoNeznGtFDb3jQlT6NYDBzvZeOb9HvKNHkZT6o/ snKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=bQrmE0h0hi/sAhvTLnpixD2vkwmKFd1GI9WxzdQSXN0=; b=JQomAqqgGf1O+CEVwdeOc8MtCtesGf4Mwon/tKZwPXsGBLOez46niaomlakJ9Uw8ZX iKV/91IYe3foIKLffy4ViN3ADyIMTmSGSLKvm7KM4lKtzmwYE1S6ScuscORKtf7kQNsO r2ugCVWI93qyZ2DHM9/wtclAv/SnJMR2nrzDYZK6xPjB1dIEaxnLFK+n3K/nlDUOrFC2 rJH/1V6e+NvL388kozYLIbCvpXjRgemdGKPI4dMJ0P29O8FIdKTzwXMwzjyXqGv3/LTt uMaivpjnfVUP2UVs9TRnzPeImNId5YxMScEJqYScW49upCrtiJjFUg4swBfSm3XruwrZ rx1g== X-Gm-Message-State: AHPjjUjcqUFdx5ar/MPfPYZED6jZLzjsf4bIcFY190EKjDzRDVPi6YU4 ruxhoM0R3/+Ud1Au353SZVTDLT5WfrwLHmM0AMissA== X-Google-Smtp-Source: AOwi7QD0TGHkXt/85QnaQ6P+omwkq0lscZaruDJvKqXxuYtykeon9mXVuLQbGYJdoWRkCutC7h5yLB1WN1cn1+SOlVY= X-Received: by 10.200.51.69 with SMTP id u5mr16611599qta.204.1505320093924; Wed, 13 Sep 2017 09:28:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.44.34 with HTTP; Wed, 13 Sep 2017 09:28:13 -0700 (PDT) Reply-To: scespedes@ing.uchile.cl In-Reply-To: <74e2bc40-6c9e-5034-1425-45e38f877efb@gmail.com> References: <150307081500.14196.2111291351079489748@ietfa.amsl.com> <6f4dfdfc-e092-f610-40d6-58ddcff00299@ing.uchile.cl> <74e2bc40-6c9e-5034-1425-45e38f877efb@gmail.com> From: =?UTF-8?Q?Sandra_C=C3=A9spedes?= Date: Wed, 13 Sep 2017 13:28:13 -0300 Message-ID: To: Alexandre Petrescu Cc: its Content-Type: multipart/alternative; boundary="001a1143426478d0a2055914a52b" Archived-At: Subject: Re: [ipwave] Comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 16:28:18 -0000 --001a1143426478d0a2055914a52b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Alexandre Thanks for addressing my comments. The new version has improved significantly. Regards, Sandra L. C=C3=A9spedes, Ph.D. | Profesora Asistente Departamento de Ingenier=C3=ADa El=C3=A9ctrica Universidad de Chile Av. Tupper 2007, Santiago, Chile. 8370451 Tel.* +56 (2) 29784093 <%2B56%20%282%29%2029784093>* | Of. 504 URL:http://www.cec.uchile.cl/~scespedes On Sun, Sep 10, 2017 at 11:00 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Le 21/08/2017 =C3=A0 17:14, Sandra C=C3=A9spedes U. a =C3=A9crit : > [...] > >> 3. In page 4, there seems to be a contradiction. In the first >> paragraph is mentioned that "while there is no encryption applied >> below the network layer using 802.11p, 1609.2 [ieee1609.2] does >> provide security services for applications to use so that there can >> easily be data security over the air without invoking IPsec." >> However, in the fifth paragraph is mentioned that "the IP security >> mechanisms are necessary, since OCB means that 802.11 is stripped of >> all 802.11 link-layer security;". I understood that IPSec wasn't >> necessary but the last phrase seems to say the opposite. Am I wrong? >> > > No. > > I removed "so that there can easily be data security over the air > without invoking IPsec". > > > 5. In page 7, suggest to change "This band is "5.9GHz" which is different >> from the bands "2.4GHz" or "5GHz" used by Wireless LAN" to "The 5.9GHz b= and >> is different from the 2.4GHz and 5GHz bands used by Wireless LAN". >> > > Done. > > Same suggestion to other appearances in the same paragraph. >> > > I dont see where. > > 6. In page 7 you mention " In the list below, the only 802.11 OCB >> fundamental points which influence IPv6 are the OCB operation and the >> 12Mbit/s maximum which may be afforded by the IPv6 applications." I >> found the description for OCB operation but none for the 12Mbit/s >> maximum (not sure if you are referring to a maximum data rate? I >> thought it was actually 27 Mbps), so it is not clear how the second >> "fundamental point" influences the operation of IPv6. >> > > I reformulated. > > 7. In Appendix C.1, perhaps it should be mentioned that relaying on >> an identifier obtained from the MAC address might not be possible >> not only in the presence of multiple 802.11-OCB NICs, but also if >> there is randomization of MAC addresses. >> > > But if there is randomisation of the MAC address (a single MAC address), > it is still possible to identify one vehicle by that MAC address, even > if it is a number that is randomised. I suppose it is randomised only > once in a lifetime, not every time the machine boots. I suppose it is > randomised such that an privacy attacker is prevented from correlating > the OUI of a MAC address to the true organisation (obfuscation). > > Or maybe you assumed frequent MAC randomisation. In that case, I > reformulated. > > 8. Appendix C.2 defines several MUSTs for authentication, time >> synchronization, etc. Why is this defined as an appendix and not in the >> main document? >> > > It looks like these requirements should be outside the document > altogether. > > Thank you. > > Alex > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --001a1143426478d0a2055914a52b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Alexandre

Thanks for addressin= g my comments. The new version has improved significantly.

Reg= ards,


Sandra L. C=C3=A9spedes, Ph.D. | Profeso= ra Asistente
Departamento de Ingenier=C3=ADa El=C3=A9ctrica
Universidad de Chile
Av. Tupper 2007, Santiago, Chile. 8370451
Tel. +56 (2) 29784093 | Of. 504
URL:http://www.cec.uchile.cl/~scespedes
=

On Sun, Sep 10, 2017 at 11:00 AM, Alexandre = Petrescu <alexandre.petrescu@gmail.com> wrote:
Le 21/08/2017 =C3=A0 17:14, Sandra C=C3=A9s= pedes U. a =C3=A9crit :
[...]
3. In page 4, there seems to be a contradiction. In the first
paragraph is mentioned that "while there is no encryption applied
below the network=C2=A0 layer using 802.11p, 1609.2 [ieee1609.2] does
provide security services for applications to use so that there can
easily be data security over the air without invoking IPsec."
However, in the fifth paragraph is mentioned that "the IP security
mechanisms are necessary, since OCB means that 802.11 is stripped of
all 802.11 link-layer security;".=C2=A0 I understood that IPSec wasn&#= 39;t
necessary but the last phrase seems to say the opposite. Am I wrong?

No.

I removed "so that there can easily be data security over the air
without invoking IPsec".


5. In page 7, suggest to change "This band is "5.9GHz" which= is different from the bands "2.4GHz" or "5GHz" used by= Wireless LAN" to "The 5.9GHz band is different from the 2.4GHz a= nd 5GHz bands used by Wireless LAN".

Done.

Same suggestion to other appearances in the same paragraph.

 I dont see where.

6. In page 7 you mention " In the list below, the only 802.11 OCB fund= amental points which influence IPv6 are the OCB operation and the
12Mbit/s maximum which may be afforded by the IPv6 applications."=C2= =A0 I
found the description for OCB operation but none for the 12Mbit/s
maximum (not sure if you are referring to a maximum data rate? I
thought it was actually 27 Mbps), so it is not clear how the second
"fundamental point" influences the operation of IPv6.

I reformulated.

7. In Appendix C.1, perhaps it should be mentioned that relaying on
an identifier obtained from the MAC address might not be possible
not only in the presence of multiple 802.11-OCB NICs, but also if
there is randomization of MAC addresses.

But if there is randomisation of the MAC address (a single MAC address), it is still possible to identify one vehicle by that MAC address, even
if it is a number that is randomised.=C2=A0 =C2=A0I suppose it is randomise= d only
once in a lifetime, not every time the machine boots.=C2=A0 I suppose it is=
randomised such that an privacy attacker is prevented from correlating
the OUI of a MAC address to the true organisation (obfuscation).

Or maybe you assumed frequent MAC randomisation.=C2=A0 In that case, I
reformulated.

8. Appendix C.2 defines several MUSTs for authentication, time synchronizat= ion, etc. Why is this defined as an appendix and not in the main document?<= br>

It looks like these requirements should be outside the document
altogether.

Thank you.

Alex


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

--001a1143426478d0a2055914a52b-- From nobody Thu Sep 14 02:44:11 2017 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 3AB901331E3 for ; Thu, 14 Sep 2017 02:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9VAbg7zAiPF for ; Thu, 14 Sep 2017 02:44:07 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 AECA91331D7 for ; Thu, 14 Sep 2017 02:44:06 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id a128so6015431qkc.5 for ; Thu, 14 Sep 2017 02:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=JfX5sXc5YpqjDyJ5Vt6kkhT7APC5iC7vMD6FJW2rrZU=; b=O7MW0EnQLRHNOfBW/v8yRQYfNDY4y4VECqKrnfSu2dIRmqT+5SQIrhTAKX33loMKav zAbQfy8rtd4ojbSw8yNcz9nNYB01VMvI4bXHNg4ReNd+Wrd0H2S7q7CbinPWtmZQB0QC xOCYPIKnCv5PgZBjRnojJLSOBeCmkILhpFvIAq5axkS3myBcqi8zK/EVZBg35ol+FRnM FkxxouazlhKxyAnM6pvKfyb2Q7ijKAaWDdm8uOTitxz5wPQwqmFfg3877U6PQYOQaGbj 3DTocDq9ChvQl2bUw8EHKtmQCH+h0pWbd92JHfWV/7oHguObwwKnUa/C1yC3OcMaanWx 5NpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=JfX5sXc5YpqjDyJ5Vt6kkhT7APC5iC7vMD6FJW2rrZU=; b=nx1mLRx41gztlTHbSF/RfnXh6PqqsdmSumPdzCjCHh/nrf2LJAzJxcTMMa8Vn/P/zZ FugY63woVfDgIi+sIw8JA3d7aayW3yWUw1imZacj3rblvlsVH25ZZ8CyVvvKsAVCJMoJ yjrCMRCeqlSXh1zfQJ7Cd5W6lHLe4WURVZwj59gHFJ6kSD9mHT6kMSU9a7M/3QUWEbvb 0Cc/VWDkarGQA8Ttj5GSXyFZBX4zrRDD/XpRLXZwfReDWUhnowZ8eKDX7tsr1ZaAIJrO HSh18Ah+czT1jzxLSsXHr4PmHBOG4EkllBv+Q72shqevvs5twCcURvwMOZxJGfmbV/BT iyQA== X-Gm-Message-State: AHPjjUjDohLfnmeZJQgDe+/18i128/7n0vquK92fiLMBPGlUhu6QNjnK XXakRolA1fQfjQ== X-Google-Smtp-Source: AOwi7QBqApeVfQOOom5cXOiio11PEpATpfaGYeH1k/K0vc0GQLfu7DunlM1i2GWU/WcKsFaEYVC+/g== X-Received: by 10.55.113.198 with SMTP id m189mr1041168qkc.51.1505382245745; Thu, 14 Sep 2017 02:44:05 -0700 (PDT) Received: from FrancoisPC (pool-108-48-85-190.washdc.fios.verizon.net. [108.48.85.190]) by smtp.gmail.com with ESMTPSA id b77sm10702498qkg.26.2017.09.14.02.44.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Sep 2017 02:44:04 -0700 (PDT) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" Cc: , References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> In-Reply-To: <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> Date: Thu, 14 Sep 2017 05:44:03 -0400 Message-ID: <011101d32d3e$00cc7d20$02657760$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0112_01D32D1C.79BF9810" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIukhOZsx60BumPZtxqsZkYmsT8+wFgJMjwofJVERA= Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 09:44:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0112_01D32D1C.79BF9810 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0113_01D32D1C.79BF9810" ------=_NextPart_001_0113_01D32D1C.79BF9810 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mr. Petrescu, =20 Find attached comments on version 06 of the document. =20 Let me know if you have any questions. =20 Francois Yves Simon Lojik Technologies =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Sunday, September 10, 2017 9:58 AM To: its@ietf.org Subject: [ipwave] Fwd: New Version Notification for = draft-ietf-ipwave-ipv6-over-80211ocb-05.txt =20 Dear participants to IPWAVE WG, This is the new IPv6-over-802.11-OCB addressing all the Reviewers = comments. This is the ChangeLog: o Lengthened the title and cleanded the abstract. o Added text suggesting LLs may be easy to use on OCB, rather than GUAs based on received prefix. o Added the risks of spoofing and hijacking. o Removed the text speculation on adoption of the TSA message. o Clarified that the ND protocol is used. o Clarified what it means "No association needed". o Added some text about how two STAs discover each other. o Added mention of external (OCB) and internal network (stable), in the subnet structure section. o Added phrase explaining that both .11 Data and .11 QoS Data headers are currently being used, and may be used in the future. o Moved the packet capture example into an Appendix Implementation Status. o Suggested moving the reliability requirements appendix out into another document. o Added a IANA Consiserations section, with content, requesting for a new multicast group "all OCB interfaces". o Added new OBU term, improved the RSU term definition, removed the ETTC term, replaced more occurences of 802.11p, 802.11 OCB with 802.11-OCB. o References: * Added an informational reference to ETSI=E2=80=99s IPv6-over- GeoNetworking. * Added more references to IETF and ETSI security protocols. * Updated some references from I-D to RFC, and from old RFC to new RFC numbers. * Added reference to multicast extensions to IPsec architecture RFC. * Added a reference to 2464-bis. * Removed FCC informative references, because not used. o Updated the affiliation of one author. o Reformulation of some phrases for better readability, and correction of typographical errors. Alex -------- Message transf=C3=A9r=C3=A9 --------=20 Sujet :=20 New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt Date :=20 Sun, 10 Sep 2017 06:55:20 -0700 De :=20 internet-drafts@ietf.org =20 Pour :=20 Nabil Benamar , = Christian Huitema , = Jong-Hyouk Lee , = J=C3=A9r=C3=B4me H=C3=A4rri = , Alexandre Petrescu = , Tony Li = , Alexandre Petrescu = , Jerome = Haerri , = Thierry Ernst = , ipwave-chairs@ietf.org = =20 =20 A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. =20 Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 05 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks = operating in mode Outside the Context of a Basic Service Set = (IPv6-over-80211-OCB) Document date: 2017-09-10 Group: ipwave Pages: 37 URL: = https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb= -05.txt Status: = https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized: = https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211oc= b-05 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80211ocb-= 05 =20 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks run outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. =20 In addition, the document lists what is different in 802.11-OCB (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, where IPv6 protocols operate without issues. Most notably, the operation outside the context of a BSS (OCB) has impact on IPv6 handover behaviour and on IPv6 security. =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 ------=_NextPart_001_0113_01D32D1C.79BF9810 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Mr. = Petrescu,

 

Find attached = comments on version 06 of the document.

 

Let me know if you = have any questions.

 

Francois Yves = Simon

Lojik Technologies

 

From: its [mailto:its-bounces@ietf.org] On = Behalf Of Alexandre Petrescu
Sent: Sunday, September 10, = 2017 9:58 AM
To: its@ietf.org
Subject: [ipwave] Fwd: = New Version Notification for = draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

 

Dear participants = to IPWAVE WG,

This is the new = IPv6-over-802.11-OCB addressing all the Reviewers = comments.

This is the = ChangeLog:

o Lengthened the = title and cleanded the abstract.
o Added text suggesting LLs may be = easy to use on OCB, rather than
GUAs based on received prefix.
o = Added the risks of spoofing and hijacking.
o Removed the text = speculation on adoption of the TSA message.
o Clarified that the ND = protocol is used.
o Clarified what it means "No association = needed".
o Added some text about how two STAs discover each = other.
o Added mention of external (OCB) and internal network = (stable), in
the subnet structure section.
o Added phrase = explaining that both .11 Data and .11 QoS Data
headers are currently = being used, and may be used in the future.
o Moved the packet capture = example into an Appendix Implementation
Status.
o Suggested moving = the reliability requirements appendix out into
another document.
o = Added a IANA Consiserations section, with content, requesting for
a = new multicast group "all OCB interfaces".
o Added new OBU = term, improved the RSU term definition, removed the
ETTC term, = replaced more occurences of 802.11p, 802.11 OCB with
802.11-OCB.
o = References:
* Added an informational reference to ETSI=E2=80=99s = IPv6-over-
GeoNetworking.
* Added more references to IETF and ETSI = security protocols.
* Updated some references from I-D to RFC, and = from old RFC to
new RFC numbers.
* Added reference to multicast = extensions to IPsec architecture
RFC.
* Added a reference to = 2464-bis.
* Removed FCC informative references, because not = used.
o Updated the affiliation of one author.
o Reformulation of = some phrases for better readability, and
correction of typographical = errors.

Alex

-------- = Message transf=C3=A9r=C3=A9 --------

<= td nowrap valign=3Dtop style=3D'padding:0in 0in 0in 0in'>

Date :

Sujet :

New Version = Notification for = draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

Sun, 10 Sep 2017 = 06:55:20 -0700

De :

internet-drafts@ietf.org

Pour :

Nabil Benamar <benamar73@gmail.com>, = Christian Huitema <huitema@huitema.net>, = Jong-Hyouk Lee <jonghyouk@smu.ac.kr>, = J=C3=A9r=C3=B4me H=C3=A4rri <Jerome.Haerri@eurecom.fr>= , Alexandre Petrescu <Alexandre.Petrescu@cea.fr&g= t;, Tony Li <tony.li@tony.li>, Alexandre = Petrescu <alexandre.petrescu@cea.fr&g= t;, Jerome Haerri <jerome.haerri@eurecom.fr>= , Thierry Ernst <thierry.ernst@yogoko.fr>, ipwave-chairs@ietf.org

 

A new version =
of I-D, =
draft-ietf-ipwave-ipv6-over-80211ocb-05.txt
has =
been successfully submitted by Alexandre Petrescu and posted to =
the
IETF =
repository.
 
Name:=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
draft-ietf-ipwave-ipv6-over-80211ocb
Revision:=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =
05
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 Transmission of IPv6 Packets over IEEE 802.11 Networks operating in =
mode Outside the Context of a Basic Service Set =
(IPv6-over-80211-OCB)
Document date: =
2017-09-10
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =
ipwave
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 =
37
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-ipwave-i=
pv6-over-80211ocb-05.txt
Status:=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211=
ocb/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv=
6-over-80211ocb-05
Diff:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-ov=
er-80211ocb-05
 
Abstr=
act:
=C2=A0=C2=A0 In order to transmit IPv6 packets =
on IEEE 802.11 networks run outside
=C2=A0=C2=A0 =
the context of a basic service set (OCB, earlier "802.11p") =
there is
=C2=A0=C2=A0 a need to define a few =
parameters such as the supported =
Maximum
=C2=A0=C2=A0 Transmission Unit size on the =
802.11-OCB link, the header format
=C2=A0=C2=A0 =
preceding the IPv6 header, the Type value within it, and =
others.
=C2=A0=C2=A0 This document describes these =
parameters for IPv6 and IEEE =
802.11-OCB
=C2=A0=C2=A0 networks; it portrays the =
layering of IPv6 on 802.11-OCB similarly =
to
=C2=A0=C2=A0 other known 802.11 and Ethernet =
layers - by using an Ethernet
=C2=A0=C2=A0 =
Adaptation =
Layer.
 
=C2=A0=C2=A0 In =
addition, the document lists what is different in =
802.11-OCB
=C2=A0=C2=A0 (802.11p) links compared to =
more 'traditional' 802.11a/b/g/n =
links,
=C2=A0=C2=A0 where IPv6 protocols operate =
without issues.=C2=A0 Most notably, =
the
=C2=A0=C2=A0 operation outside the context of a =
BSS (OCB) has impact on IPv6
=C2=A0=C2=A0 handover =
behaviour and on IPv6 =
security.
 
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
 
 
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
 
------=_NextPart_001_0113_01D32D1C.79BF9810-- ------=_NextPart_000_0112_01D32D1C.79BF9810 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="AutoRecovery save of IETF_WAVE_DOC._V06_COMMENTS_091417.asd.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="AutoRecovery save of IETF_WAVE_DOC._V06_COMMENTS_091417.asd.docx" UEsDBBQABgAIAAAAIQAykW9XZgEAAKUFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lMtqwzAQRfeF/oPRtthKuiilxMmij2UbaPoBijRORPVCo7z+vuM4MaUkMTTJxiDP3HvPCDGD0dqa bAkRtXcl6xc9loGTXmk3K9nX5C1/ZBkm4ZQw3kHJNoBsNLy9GUw2ATAjtcOSzVMKT5yjnIMVWPgA jiqVj1YkOsYZD0J+ixnw+17vgUvvEriUp9qDDQcvUImFSdnrmn43JBEMsuy5aayzSiZCMFqKRHW+ dOpPSr5LKEi57cG5DnhHDYwfTKgrxwN2ug+6mqgVZGMR07uw1MVXPiquvFxYUhanbQ5w+qrSElp9 7Rail4BId25N0Vas0G7Pf5TDLewUIikvD9Jad0Jg2hjAyxM0vt3xkBIJrgGwc+5EWMH082oUv8w7 QSrKnYipgctjtNadEInWADTf/tkcW5tTkdQ5jj4grZX4j7H3e6NW5zRwgJj06VfXJpL12fNBvZIU qAPZfLtkhz8AAAD//wMAUEsDBBQABgAIAAAAIQAekRq37wAAAE4CAAALAAgCX3JlbHMvLnJlbHMg ogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAArJLBasMwDEDvg/2D0b1R2sEYo04vY9DbGNkHCFtJTBPb2GrX/v082NgCXelhR8vS05PQ enOcRnXglF3wGpZVDYq9Cdb5XsNb+7x4AJWFvKUxeNZw4gyb5vZm/cojSSnKg4tZFYrPGgaR+IiY zcAT5SpE9uWnC2kiKc/UYySzo55xVdf3mH4zoJkx1dZqSFt7B6o9Rb6GHbrOGX4KZj+xlzMtkI/C 3rJdxFTqk7gyjWop9SwabDAvJZyRYqwKGvC80ep6o7+nxYmFLAmhCYkv+3xmXBJa/ueK5hk/Nu8h WbRf4W8bnF1B8wEAAP//AwBQSwMEFAAGAAgAAAAhAFvcdqVcAQAA+wYAABwACAF3b3JkL19yZWxz L2RvY3VtZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3JVN boMwEIX3lXoH5D0Y0jZNq5Bs2kpZdNOmBzAwgBVjI3vyd/tOEiUhSoq6YMUKzVj+5r03CMbTTaW8 FVgnjY5ZFITMA52aTOoiZj/zD3/EPIdCZ0IZDTHbgmPTyf3d+AuUQLrkSlk7jyjaxaxErF85d2kJ lXCBqUHTSW5sJZBKW/BapAtRAB+E4ZDbJoNNLpjeLIuZnWU0f76t4T9sk+cyhTeTLivQeGMEL4lk ldQLggpbAB6wjrhojHKBBMz3rBIrxTMrcvR3PV/Wa7ECeqyGvqG8/FE4iCKTJn44PMI+TUY63zcI VgvF+G1DD10acoBIq3JnP8dOQKy/JDz3LdNBp5niVkEz0X3dlmfU5Xi9rBKwtMKzglOrTcQusl4t 9alvhqKwS0dId+HsZl8emlHba/LYpYY1JN9XX6BGs03IS5dCcqNxLhLVCOTUOorgF7+syS8AAAD/ /wMAUEsDBBQABgAIAAAAIQCf1ojztiUAAO7FAQARAAAAd29yZC9kb2N1bWVudC54bWzsPcty4ziS 943Yf0D4MnZESRZlya+e8oT8qqrY8rTHdnfHxGzHBkVBFscUoSEhu9yn/oe5zlz7M/awn9JfskgA lAiK75clmT5YEh8AMpEvZCYSf/zTt6mFnrHjmsT+uKO1OzsI2wYZmfbjx50fHq5bxzvIpbo90i1i 4487r9jd+dPZf/7HH19OR8SYT7FNEWvCdk9fZsbHnQmls9P9fdeY4Knutqem4RCXjGnbINN9Mh6b Bt5/Ic5ov9vROvzbzCEGdl3W34VuP+vujmzO+JautZGjv7CXocHevjHRHYq/LdvQMjfS3z/ZP15t qJujIQZhV1tt6iBzU4f7MKqVhnq5GmKjWmmpn6+lEOAO87XUXW3pKF9LB6stHedraYWcpqsETmbY ZjfHxJnqlP10HvenuvM0n7VYwzOdmkPTMukra7Nz6DWjm/ZTjhGxtxYtTA9GmVs42p+SEbYORl4r 5OPO3LFP5futxfsw9FPxvvzw3nDSwC9euZTCgUO+72CL4YLY7sScLTh8mrc1dnPiNfIcB8Tz1PKe e5lpKdklSjxdClQuG0wzfIn/qSVGHt+i1kkxI9DE4o00Q1D79EYyZVS47DgXanzI1VIKEK+B7koD h4aZkqS9NgQ2GTzsTV87Ls7WTN9rxn2dLln9ZfZYjFo+OWQ+W7ZmFmvty5L3X0ALZ2hLUp2fE9xi g7mf6DMmEqbG6ZdHmzj60GIjYjSEGBkgPgPwn80KAqbbOWOmwpCMXuFzhl5Omakxuvu402FUcHR8 dLDjXbrEY31uUbhzcqldHw/4mw78o2edk33tj/vwDf7zi46/rb520D++4m/Qs17ck+dXna4cFbdc Tt2ZbjAAZg52sfOMd872tSOktMD+z1ZGL9sJGb28s5/0yq2Tqh155zYw+Nkthw1Gz+aEPaSPKYYW Rcd/N9ilZ936uGMwuYkdcdURLw35D/cX75Husbjt/nLhqtcAAfAOoEC8u0CmMvxCjQOqHxzddqem C3YoImP05fb5EN3qxhOmLiLMQEVfrq6u0HGn29Y09GdMGU0+sTsz7DDNwhBg2gj0W/LEHWra0dXg 3SP8+zlljWJEJxhdEDbibxTwrqNz3TUNdM94gQkB9knRLkxGCyahxfCvaa3vL873gjxWdEDhvKgy YoCVfUxffs+tNF0nTU3WSWHmAtP2Zjags3aC6bhlzl70Z8w+lIklxrDVOXwDuNv0Gy1B5K4b51ZD mYxdp2AMu9uGsbUBobTBXxxqnYEWNnj1zroMng4t+SEpcGjd01cLe28/gLH3yWEGN2+Y3f6J3WLL kJNerw/A0NcZo9XRN33xwFdCnrzXO71BB54am45L7wh7j2PA0uWv5c0LYs2n4JDy7nsX+CM2+Xyu 26PFrx/FL02C5h8+DBa+PrJP1oYYraZ59pl6uXfcDbt8eHIYcrmv9Q+WHXr9UEVcDrSj7tGlN8sP XFoeXxz0+sK4pYb4L0drSGTy4QWRCd3IBxUSu+z3LwRWfRI5cNFHd+odTnfyko/uEvk7RNaFDiDi NRBbUoihL5chYowDG4eh3gmnjHeBoQcGZB4cHXY5FFuNo0titNEdHmMH20YeLPW77wBLkpKi0QMf 4tm1EF/Xg26/fxSGUvVOhNoMQ6kPewInqjuhLrFTB2RXI5O230RgZIJOuzw60A4F2arN+O+EE/Rg 6FJHN1SK9hAQYTX//us/UaQPSRm/r2O2NKIDy3y0Pby78xl2XMMxZ9RvSEGrbqbhRI0kgAB6NtMd /dHRZ5N4CHzvJWGzGFBRA42A0wVCZbI5D0VmEs6BpWl64hOA/v7rv37/9bd4+rg46hxfXfhRaQbQ 5XdS2Z6TypnbiAh3SwYK+f3Xf6dwQ171OleDUJZT7/ih5hqmQm5eIDSOdOTwvGeLYj4ch6HTkaen l9OJ+ThhPDOhHtO8YssiL0F+YXMdB/WJph33g/6Tgl3abIlYCfaiiDYEIG8a/x3N5fAhelMaWD8b Q5WiRTRxNxob0ZBVaGOUB9k62hgh0EXbGNfnvSvt0s8SZdkY6qSvdFxMHdujLMNRTQdwo6yDOo6f J4/OVuXUChGWorLDUSciIff3aBdiHWiiu8icsocoIraITU10e8TjUkM80Z9N4rChVKey02EmtLvi XOQPOWTE7tlO1PT44I15vQSTbDmVgZZmDiHjKwcaFBTNWGV6T3WHc11ZlMTpp1qbQ1BmHKJXg0aZ OlAjDRGYu7KlV7hU4CIkGwSusgOc3G5RYguTCsE2xZPbYStJNeqXFjktioNobERDVqU/pjTI1tIf Uxp0WiueZ5INrS82dchobkCCYCiv5PCgSE4RHST6TVS+kgP3NSGHWp7fxD+8RNstFCfxQEWhvjp3 1sKuDDOAkig9k2EZbT6FELUPBdkMywDsibaC9+JvKqevzEmyCpmJpKc0A8imcn2dRK33bZFlldS3 O2OquoCldHZPg+uY8D7KBlD6giCBaekP2sW6Y5lMZz/Z5MVGzNQXT8320N8AHZAbAy9B3urP7Qps /ExEGtpdcenvlxVZZ/PNbfzw2ZaMBFSdp/3U1rHPyRggrEr4KPW49PZTUBiVsuRJP4BsPP72qwqP 779DjhdSPq1QIqZGZDXishRkgVQ8TNB5q3ZISrjXdI0UMBd9glW9U8SsVnPYFcCjgciyHKoDiFpW PpkA8RnecqgzJcHtq+nSW8/yFrxk2iN218JjaFNcWgI/JJQ/5gNdpf2DI61/FRvL1lpxCyC1tf4h o+WV5O9kXg22KnpOsYQoexEUN8gYb3Xli4rQFaAUm3kpyydqPaSscMibrjTohOm4NN2XbYabLrIJ bNcwx6bBNwYyhfuPuengEaIEtiSEzHdqCztkcnx8k2pyygETIbFz2hm5pyJoIOzCsWljNGLQGtR6 FZtbfOYjJQTtvph0gvQVw7Vsl/XZ168XiLHaK3YqpYOzPVg3bcekJkORSSP510dZsRofAPPhqBTQ ubgI492SBlDMHsXfZoyfhAApZrJXNOwCVnytiPTyZeJmNXxRX6zfm8FF3ZR0xqQz+koeGSFb6CtI QfTVtJ+QOx9ymei2Mw9o1ULLudYJ7yxu3kIEE1yJXiqpAFSyVArgyCcK1TtFVhn9aMCjgciyVKoD CFgq5YEjy0opExxXV/2TSyXxIPtKyQelyiXlroqurrrnx3EhpsyrooQcnlUmryuHR42SljwwJ9PA QHZG7rQvYzh0kmU43lIxbFdkEhdlS2yK0UPpWKtiw1WahWOs07kw2AxiM/HC+IiZR8NXpKOxpfMd 8wVXWqnERqmwRa60bnRbf8RiR5ktyp+AaXquu7iN0MNEpwzoKGqNNmn8aAWUMeNXnzIsBkMe2azL 5L7YQnDAJN+zzizaVF2FG42JHYXjcyc0ipuaLEJCXJnIIrS7jGwnO6yRNPP4crJ38Vu7naaTwmsI f6+RkiSKn4oxc55WU5vZQYmXH0MFV1mxIqtKFESMZ/fmy/ke0il1zOGcBjyu1WNpJYj89uv1kmRw JchShQAILf4/ZrGnCsRKFntqFwnSOOc6Sc36VACPBiLLYq8OIOpY7GWCo1nsxXW4wI3soq7FnurY KHlg+VZXOai2pOS+EKo9HHS6Ryd+qg2xM1aYL2ZfYiG75acJtjHEcgKtl589V4JiKmahMUPQxZSH 6py5KCG2sBEp4sU+sctuf0DEYT/5mzZ1P0BEy0u2k7k23otF40Mha45M5BHeXRYZ6uuuJDQzSn2/ RJWHR4uZwEDGTbJXbEwI4tMuZSQCs6V75NKOn6tVPZU/JBI3xhDxAVdiTOKLg+vuwntQjUmsdKFI EOVOfmuSF8/C9gg7eHTL1pPnDtaf+ITTs6NolESDl8lYjgRP62sn5Ww1fsDGxIYIXR5gMlnMkcCo bqZNs5g7DCrtIKa1zBazSlcrHa5KoOoMU9ViTohH1Dmwt7eYQ6jWty0yvcUcDuCAqeoJ0wIzYtpU xhLQ4kgIpqEMSBAx6StUlZ1i12WyyUUvE9OYoKn+CpYhfNiEoiFGcxcz5oCkJ54n5U7I3BrBDf2Z mCOmYhLsASluIiASdFvQO5umi9/apFAiVWIfEcQGCpUZiTxpYYlsd85wrbt8Zv4gy/rqY8ym5EY8 8ge0Kyfuh/s9bqzzRy+ILKv8jNHgRXeYCeq6K+9ETUiAzjLBUXCSI12tVz/4wPtp8OMVuiNzXjZ6 MAIRYLrcD/sHvrsHBEkI1xZZimTiu/Dusiin6A374SjMYJFBZJEhUp/NLJn+5aKRTvWI9ZsUdfAh mlDIRGomeakSA0ztwo839U4RC+U4GvBoILKYWXUAUZuZlQkYn+3yvsysFlKpKkV3dRlZCVsGig0s 367jHDRbkpEVT7MSqESX4yrOgrbFA9NcsPqWmpnY3F9CGQpnoMbIeIx0y0L4G2MIuCAX7JZpP7WE WeBiY+6APTZlnK7bpjtdTW+MwTVoxrLVogSbs20pMmKJrEWmMn5m9iNsIaGQA+LzY4wImEiAQaTb r8yWtR9VfCh0BB+i9bXWYKvyMpXwP8nBQNVpsJxANBrsj1k1GH8mQrausQbqMgS9H9HPVto+c1ss 8j7wpQz3VmuHnZN2d7n0FjULxNWfhZRja1CQgksVAGg1DXZnzGx5g82aztZ0ik1PCazJQ6fobMXW 9wHlQ1ncfIbM2hoqkojBD2wfBiVuR0gfkmcRC7sZXOzDxqoRnuqOnDXpJnGhpmaLjFuuwTQ5Rz/3 oniz144mZ/gQw1ofDXQ90A4v+cEPRYW31snByCWpoPKggMQO4phvqYJSAVOrCuq20AN2pqZNLPK4 kjMYx2gt9P35DzlQWVY9oVhUSujSFKGUDflwFJTxBmFaWndeQe7qNrq7V8H2tZhOwFZTjDKHmE2D w4jZlxuzrNcPgA8mTcemzXNPfe7hmcXe8steRjC+J7OLU3W8lYhTtQs/so67/YOrRc3UQuK08uMN 6oCiNoteHbIq2fJCmKewRIgE9SEldHgRrwG+IhPb+Otd7Vpbzl/aNlsP8aIuuYUIVRAqnQoSWSE1 x0e7noopBPhuX7u4Phd4F3hOo5j8b4UrJlGIgCILQz0O+kLQl1tkAseOGVLc75BuueTD8gliY+UJ OPzAhfAguFzggE4IBwovTBuhL5QHASHOB2WVkcOsY+yoUjt+KirQchIpq1ouEzX6UJuypMcDLATY EiEAfUIAMY5MXTLFL+D2YubFeA5n97YRdySeJyc5RQVDA7DRMzaBGeYLIXc+mxEn6OYtAKUgnSXF MRNKrs64RWCLQKZ/Cb0rS7SJtTRfq90Pbvf4lkYd9dsn6NPnX9Dd9bLRuLKW8CEGGIYkeakSS0Lt wk+QqnQvZElUfohBDVCEU87CvMhTXiiTfRGnbNPBLS/54F4D+6IVta4LFcKZ5rkMeNNRAVPmweVW OgooSZmfXx4dHagngfp1hwRAflyzdSKc5Wm4TLRNWbeAfufzwHZNgQSDTQZMJEdSh/+JG+4EsCP4 hKlqBzrkD3/c0eeUwM+xabG71/xPwhJPIofnmtZVTp5LHqDIN6himDCBzOiBteLuHdFH6B58nj+w leDeKVgakLKKfjIdbEE6iyBdoQ9uuXNu96eH270PkDDDF5BsWcnMlr/dXV/0e1r/Z54/wlTNwDDg dfnKAN5QbsijyXmCCXbYE3++2ws2eHDUP2ANctsKDKYn/Aoebmoac0sHB+0p11zs78Ub7u3nv+5D hRQRyxM7Mcfm41yWzBJhQQwd+EpJrRyIXsoMVjR3kfZdu/S445ryVyhgxyed7kWwtK+ctkaa1EqL YDqP5zaPpLnIYhpo4XoymAAYcvYDmxsZpmPMp1D9DUIEjFUZlJCgDcJlKZqu/jE3Zzxms3t3f7XX Rp/JC2z2YBLFtl6lHxDtMgDZanPP43G+mgoweZr9+hkJSX1829nm5Lx3daJGg2QLDdsUZZsBJ+Oh w+je0F0q8gVBaTGqdkF54m+QkAIZq/wOV4v8HiN0kwL/TKdzMNQF4/3CVGYbDQR3RKm3JBpYB3SF LZ03bG6L7pVap9mQkdxE/0vs7qv1nzHgNRtbTBW55qMN6sfljg+ZWWZDYSCXOiJhhCcCJPAiM2Qn eFnBtb3JLBmBM9D8Q0igj4NtNel93cDwjJdAQGU75mhoEeOJ6ZMNmaKzsWfg6StFmLdgOk5rsUh9 aJDGkd8JdNCTZx2nRJEHFAx2zU2tmF2f4fPRirWUVPM3N7R+8uaucyZpQGPMuCuEKVLwkCSeVlys 3+8augtgJPKAtmpmPiqDEztT3eZ7AylxGMmyNfNMH5qWSUs3ght6WH96YMoPRMQjuDRG6NPtPTMg DWxCrQvIipwRl2fwgD0K1ik1p28iOOjQkh/yuaEl3f8+3z+X10L6Dq0LWPAwcGHkIlLEIxtKlGDx 4I0uWiVAkFHPAhXF3B4SSsk05gFHbuwLvw9Qq4MZWl8JeUKezuqJk8XGpsN0DoFG4CfXQPBrefOC WPOp7bvvXeCP2OTzOZvJxa8fxS9tgY9LLDLFwSMv+/5kEdfVndflOBez8MkxR/D1kX2yfgR4veO+ ZDXl8jHvRDTgvacGa8MDdMpFEcH10RiVpANdDcag4eSolyCloQUYlkeE4YGmUEp7VhLtldBnhhCk ejGrkAOuFqDpAL8cqWXabKTd3uLH3dxShq7IRs8cCnKs7hqm+XHnwZxiCKq8oDvC9Ac0CXkmA9fU Q29OgLVD7xju6uUEC+0X72r3yLtyAWPzXXsfsrpKuWuvBYi+9BFImJFJKi6CA56gJkGPayFenMAg to2h9g2zXD5w89YydWbXcL8lOOYP9MjDX8tAWDtEUXGul7KEP1WadNtoKZYqsSCnFNsSgaXQTzN5 Gzx5kvnhQxitCvIDkjQ+9rVMgYwXLIPz3vlgcZ5RNYctKl0o9HHSPThWTZRc2WFxFbS0yo+lj4FP yQ/biG1JmSar5BQvr1MpVirclgRbUJcB+Bw4LSlzLAynS7BDcfr54ebrrYNFtXG28BZonXlUfw53 cLSEfFixTZAUgqF3Ip2iPlnXDZF18pqlc8HOr2EuPoPyz5utwFgj+608+SxIRgGiFBNWOXoFmEWR DJAsyZynuS1/niKKv/G6X4uNx/5zsOFUYGFJmy4/beRRHD2yMyJU0/y1Rnf48RxYNOc9GfIY68qw 5iOmUH39iB20/5jr4EWEnQUy8fuDvP93NpBOjz800a1xCxkQJMKLYCeEMMGu3+VZ8i+6K8+Ax7JI re7uLQvVskZ81TdE3SwvV3zIU8dtnuHHdzmwsYdtk96cqU8X768eoJpAEYI7tegNSSp8Z6I3FGEB /a9IvRAs1qrAalQKBVTXZvDO/ZyJaZcGgrwvb6XvytB0ycp7xaJ8ewkeU7Yv17z61T1XY1BkSpTy FNnrZdTH3i5EFq7X/R7oSjELebYYGE83X859Bw4pJp8JQUFGfFAKPootAXnaeff6Khi6fQ8YlVbz YletzL5zY9M8AjvO3g+2qKPb7tR0XTDd2TIhtwR7J1g8+wu5zynU3jWdiQT2saOD43e3+DHk74HU ih2L/n5JTXpAknAXt4//PZDX3gfEfT9p8NSQmEJirRVvWSPTGplWvUz7O+zCtkdQgBKMNc/HOgYb F9vGK/e2tlMYupUjqxzHQ47C+ee966XjrJqij0oXSmqY6EjeKVRbRD2vRYE8GopMRR9rgKK+oo9Z gCm9YEhKp6Y3OiG1fETpa8pP/r3IFLe4FpKYagBeKwq71kTxYxF9ov4VMyVS3IRMWwDxKnrVgaWb DR8UZcS6fdiIx0Nm5MY3l3C+0mpzSRWhkzpcrRJdCIAItbPAfA4OLqukW3aaWZOAUjkRxwwSZO3D /DFD3qRYLxsMPz/CX2wCQuSlBwQ2Dl+Fff5bQiGL3Ijdh5s9BN79DkJ/C2BmwtDhcDpyTs3Rxx3n y4gndeq2MQGWYxKsxUvWy8Z4MxxeE3aKvcJ+ijdH4Yos8QK96XA79y7A7kcLpyGxFZQEddMCr9tL Xz9DvRzdRvoU2yOeY8SMtkbiNBJnIXA6Rx8QNakFOWODBZUcni7rvMmybExV/YgnosAaurKfTYeI 2heQf3ZvigOCsA3nakCduEVTE0aBQ4wh4Yunny2VnhgJDESENVPIPe7TiZB7vJFG7AUxEiv1Mp7g uXlc//OHKEsT4DnSOoNLcdLfhsCzWpA6gx9+88BtR83eptLj1me07oe5fzKlgb7LVXso2gLuygq8 ZhUkg1bhNPCwtHXcUgdApRjPXrpqousmpkDUJsYh2aCWO5s3D/L8C4TqnFUbh6fCS8ftogzFWZVi zca1e0FfVb0Y3DBf1ZaQV2W+qkbgbLbAKddXldVV9a7MnYBfjgv5Lk8lWvUlbS3VpdBpxzE6LaUf 8h2ptGQ/5AI3PjfVhhPX2c9R3FKnK64kn2OeFDt1GitJsQtQis8Xot4plGLXj4Y8GoosKXZ1QFFb il0mYHxc0KTYFUyxC5Wa0c7COmYjBPO+J+KR01LZLgXKm0y5lD73HFP/PjLl6lLKSdl1qeCrOgev XmSUYad88ZXS8RmesBXila302Ku8zg33ZUqvJj8dHfwOOwFkZPUxbB62/LWBUgEf5WzYONDDJfMO r8+0Q+bUhaPFQA0bDAwoqkTGSBenlyzOxXUx3cl9AvCmkgycrqwbdA5Mkwb2LacYxBQidhwQLHDG D7PZ9FWLbmHBhRWz8tDi09cbj5QQuya1ZRKSDfAuLZNQtIUa+KUut9YEl29nGK2JZViO0+ZfRewh 9teYRI1JlMEkYuotIVayjlgpECthJiBo9yHmNZYgmASRo4TC9dti+kDcTFqCBc0goevgSrQr+eL6 8PjkytNllbiS1S6UtLrB0cHBoiRjIVfyShCkbFdyHVDU5kpWh5wAjLzkA+YduZLDmTTcv1x+93Hl 30Fn5PFmZyLkUuc+1ayneh5gbCXEzLfRjR3PxkmBiTp4u9CMArkzo4fJRzuQEppOBpa13z0VnkLW blQfuvLTgxLwBC3NiPtx50STJ4BFPaAdH0jLIeqJ7lHvOP6Jg8PDXvwTvf6xnLioJ/q9k4SRHva0 hJEeHXQTRnrc7SWMlCEsYaQaM/ySkNo5OUkYq6addBIGq3XZcBMeOTjqJQ23dyhOgQOqlNQStFZj T3VJMEvzKNYladczkli1Fi4U2ZL7919/86+SoiSxj7PrhChi3Hwtd35/L87f+v768gbpFPXbvU+f fwFzPclkqH9q6tqJ1MjTRp5uhTzNYJgVXHQ1DNIwSGNwvJXBEafKeRr3m6jyAk5WWbpy/SyQswhH ZiNj455oZOxay1gegvi4c0HmjokdYBZ4Pc0BnoFX4PBO/yU+Ml80QoKjRCPktZzGTMBhmMRo6uOb l2lQf4w8/cwAgUXHcrTr3kG32liO2oV/2tU7hWI5RyHCX0IeDUWWWE4NUESULcTGxIZUgLD1dCKI WSI8mUCUlyL5s9kskD688naILzm8cpIV11sXXglMZVJ4pQ7GKjSjaxJeSYenxhKPf6KxxMMeWQdv R1in623+gyRI3LXi49F6UAqDYQY8murfzOl8yk/WeDFHdILYXLvm0IL6Qf6aOqaLtO7N0KT7bhQo PslUKyBRXibY/lt2bKURpo0w3eLYSqhVVtTqbhikYZA1YpDcdkbdaQEbYjUEx7gGqEswZN4Eq0Wi ST0UbnmtAarDzCwfSt/KJjwLVkNaC46ubkzxyOh20M3nX5Ax0W0bW9+hGzKaW+Jgx4/osNf6y+Dm O3RBRrAZ4k6nGO3e7bE7//e/7VrnNR4ItTCRMF/gSrTP/lDrdwYn0CVcqsRnr3bht406R0dHncVh joV89sfRkEdDkcVnXwcU9Z2Wpww5CRhxyQdM453P650PUJEYWMHZkEPNgVNfW4mNAGSt68Uxo3fs wTAfbjyhlQlvbkrKDPWNORpZ/LjVWajz3vuXmqjS57gmcX0ml3gmEdYsUptFapOcklGQ1ATRyhbg Il731XNnEsHMbd0zucFVZ6DDrPUHco0INiym6jdq63+JeEBj8xuvQTx2GEk4c4POHRxSjFPVLPkc JP9Ed3iGqcmXMkyHsSlnmGA9taP1DXyIZhc4AAxcHvZO+rxAbmWLBbULv45S7xRaLKipBek0babF Qh1QLHJ58gCTZbGQCRh5yQdMs1jIu1gIIF4MLBtplbl0yzEPPmpIZ2rfOmRiDhey6svsOU9hhZIS RXKQ9/uoprk6rWte6gTsnCBp3T4fIvbVJVPsef1cBIcNPOs2RWCp+Ermg1v8A1RPIjNm1YqqJ7wF m1A0xOAUnMn22U3WrG6/eq3Cz5eJaUxkW/r+cP9x30bO3HZPg1Joo3CaYpdEpsyBd8ldaUT/Vgil EsXR5nBJyiiHN9H1yteSSvOCffPD/Qdu4+zKg11uBhd8V9rt57/uoRFhi12QlJ6M5Io9ICbddmZp kmQRba6IqVS4hGIxkxl0fNQ7ODyPxmKIXRmGQns+FW+b1rPlvSuNTnbvy2Ini6ZJ4BZvNI7HxvGY 8MibOx7LcdNFWuE+JgzCVXuCw7/uFTNadzCSd0fclHb1MaZM1JPpdA5OC7DC3e+45uBmNGvxCbOh uxMyt0bSquZ7BUBLsMfcZeurhUvKkHJhRUIaKddIuUbK1Srl0qyGkqLIjcHSsHLDyo3BArjOtf4u faA5hvjADzB13Tn0Qic6RffChtJnM8uzoNDLwlyaMwsJVtXfFQ2u1gv8GXYcYpN5MG83W2h2HSZM TNYM5iXMkwFXoiOrVwfaxaDa0glqF0r2z6GmHS7ygorEJLsrp1uXHVmtA4raIqsBYKQ767J3dBy6 wVu9I9xZ4pIPwoA7C+uQsSxVXJPB1dglpdolixdkE3liiUsKfnOPql8vDWYzbI/Mb2gYtBUi4U9W EZCNE9NcNZAHJykjJsJBuZ28uryQzFf9lZmQGwFUYvZBEIq3odQqQIN6gTm0WVmJFDkU15YmUmzI iIFSEvdW1sUQ5YH0AAU1J+YMTeeuWDKBB/p7h07II7GZNFtucLhhtGvOGEEODAO7qbYVblMEeuOm dhdE3B5icyf26EGyXXu7Z03I8NRSOCwa/h6lcCjaAquuKpZiWXG5HvqkMloGWXz7+a+MY6lJX5E7 0S0Lgn66vSayqfJj5shS74wXemdkPpsu5ChOpQL6BtJMSLfaxVl1gsx9dSmeqgI6XJ6F+kiiU36U x4UXSDiGymPMzRFygN2Y7RyKEKtmO0cWCZrX6RiWSi8hj4Yi03aOGqCobe93DZqucTo2TsfYR/I5 HcmcWqaNvy5D7zzKvgY6MMQwQ2H8tVaDBTHTeDk9TKgOzRxC+N37yqrbbrRxzoi1cZ2V7zTjaZkU CoaxBdu4xfc0OlAPiX/bZeOA3Y/YgVWNYRHjqXZJsO0+szLmdLneNF2+5BzJraovZGWVublQhmyn 31xg2tvKSEK9plaQm+vGrNOB2UTfwuyKDWaZ+/njI3bpaWJ636OjT/3ZfZsA8xbGGiOm8SG5CA1M YFSi47aggZ9fKHzAiCEA7A8X6RsYlCzg/mc0z01obiXjEexqIjPsiJqjcxfc/ppSlBQBHtllN75M 0LovjlRDRigzuLL9jupuNOTRUKybo7q+ukONo7pxVEc80jiq89lhnhz2cTV6Ex3bOKobR3XjqM4J QJPjmdpdDTmeIzyCDXN45CtQYI+8WgM62Os8D5Q9u2XIeCe5n2SMYB2GHYSnpsuzp2bkBTtuGyG+ j3KqvyLweJsOj1OY48UGSkqaKd/EKQd+dfAjHNFBnFc0IlPdZNPpzC3sfkDmGJh5UXzzCTuwfKYE YZupmMDho82cbzKUFgFbCOquAldvGcxwYu4ds3uxg0e3npnE36Jnqum3BSyNXeqYBhfLTG7fz41J QFZzhc4mHmrsNhy8qVIbGBbms7XgWUt/CRT/2wJQ38JH2wRsNzdguw47TpoobsV8dLm6Eg0Iie0I 55qJ5VzUIOfmziivvTPCY9Nmk8pWoLiNFhVxV5aa+c4+2YgZX6zFTJy1lM8GTz5fbqLd64uLPUik A1qwzCdsvarmjJD/cGXLY5xx65XuQTROouHbyG06Q0KeprrzxLmYNWqOwNvPvtg60KcuYxmtK0F5 FQRLm7hoExcNf6SJixawPJFkr03LHh5bo4uJDsOX3x64TBniR3Px5EYDaNoudR7wtyhF/fmvt1d3 X7/8+b/QzoTSmXu6v08Jsdy2iem4TZzH/QmdWvsjRx/TFlxrmbMX/Rmzj+fDFnnGTuu409U0Ygxb UHT2vy3kF+PcqFuMYQvwGUEwLoYTUCnORjOqbmENOUwKPEnOrwQBBrEIjIv32OF/ZWHGl4pwFTB0 t222sTDRPfA8q+aKnxAmbBoxh5sKNz1rI/RlOrNY+zYViZfMZqOBaqTCuos3uJrstMYKa6ywkhK+ 3tziWiCzzOqCapmKDYONWUB0YJmPtnfDnTM97hqOOZN+qnjo3TWJ2FUwsxEm5+I4gRBdAldKS9Hr HfcHR5fweBMzaBL1NgakmLL3LuZpAEUr2W/eLI8wSNQhXklEzFYOf0toQRyIniL2HC0B1TtNzcMm At1okzyidwMgLrATcyF2t0zFggSNAsknHTcKoGBWVVisjYcMRaztfz6Rc92QzsZVD5Z3TNdKeBY+ hha8pIjMi0OtM+DN++ji/KrTFWHYoMhUH+ciUz7MWxZQyV29gPQxxdCiGG1YPHKBCh8ypSNBQSa/ FqUEgMdvFUKIA4uP9PEe+oOgZLfb40uTCfveP/b8D7PHG+4/pGQGTgfxiAPcuPw5JJSS6fI3OCqW vyZYHwHwR2LlMyaE40L+fJxTP2oMYgGsUoTBM/zyiBifHBPmFhwctyY1JuCf8naDCbj51yEZvfIv 7JU5OP/O/h8AAP//AwBQSwMEFAAGAAgAAAAhADDdQykCBgAApBsAABUAAAB3b3JkL3RoZW1lL3Ro ZW1lMS54bWzsWUtvE0ccv1fqdxjtHfyIHZIIB8WODS0EosRQcRzvjncHz+6sZsYJvlVwrFSpKq16 KFJvPVRtkUDqhX6atFQtlfgK/c/ser1jj8GQVKAWH7zz+P3fj52xL166GzN0RISkPGl5tfNVD5HE 5wFNwpZ3s987t+EhqXASYMYT0vImRHqXtj/84CLeUhGJCQL6RG7hlhcplW5VKtKHZSzP85QksDfk IsYKpiKsBAIfA9+YVerV6nolxjTxUIJjYHtjOKQ+QX3N0tueMu8y+EqU1As+E4eaNbEoDDYY1fRD TmSHCXSEWcsDOQE/7pO7ykMMSwUbLa9qPl5l+2KlIGJqCW2Jrmc+OV1OEIzqhk6Eg4Kw1mtsXtgt +BsAU4u4brfb6dYKfgaAfR8szXQpYxu9jVp7yrMEyoaLvDvVZrVh40v81xbwm+12u7lp4Q0oGzYW 8BvV9cZO3cIbUDZsLurf3ul01i28AWXD9QV878LmesPGG1DEaDJaQOt4FpEpIEPOrjjhGwDfmCbA DFUpZVdGn6hluRbjO1z0AGCCixVNkJqkZIh9wHVwPBAUawF4i+DSTrbky4UlLQtJX9BUtbyPUwwV MYO8ePrji6eP0cm9Jyf3fjm5f//k3s8Oqis4CctUz7//4u+Hn6K/Hn/3/MFXbrws43//6bPffv3S DVRl4LOvH/3x5NGzbz7/84cHDviOwIMyvE9jItF1cowOeAyGOQSQgXg9in6EaZliJwklTrCmcaC7 KrLQ1yeY5dGxcG1ie/CWgBbgAl4e37EUPozEWFEH8GoUW8A9zlmbC6dNV7WsshfGSegWLsZl3AHG Ry7Znbn4dscp5PI0LW1oRCw19xmEHIckIQrpPT4ixEF2m1LLr3vUF1zyoUK3KWpj6nRJnw6sbJoR XaExxGXiUhDibflm7xZqc+Ziv0uObCRUBWYuloRZbryMxwrHTo1xzMrIa1hFLiUPJ8K3HC4VRDok jKNuQKR00dwQE0vdqxh6kTPse2wS20ih6MiFvIY5LyN3+agT4Th16kyTqIz9SI4gRTHa58qpBLcr RM8hDjhZGu5blFjhfnVt36ShpdIsQfTOWLhKgnC7HidsiIlhXpnr1TFNXta4GYXOnUk4u8YNrfLZ tw/dnfWdbNk78PZy1cx8o16Gm2/PHS4C+u535108TvYJFIQD+r45v2/O//nmvKyez74lz7qwOYJP D9qGTbz01D2kjB2qCSPXpOnfEswLerBoJoaoOOSnEQxzcRYuFNiMkeDqE6qiwwinIKZmJIQyZx1K lHIJVwuz7OStN+D9obK15vRSCWis9niQLa+VL5sFGzMLzYV2KmhNM1hV2NqF0wmrZcAVpdWMaovS CpOd0swj9ybUDcL6p4Taej0TDYmCGQm03zMG07CceYhkhAOSx0jbvWhIzfhtBbfpi+Pq0jY121NI WyVIZXGNJeKm0TtNlKYMZlHSdTtXjiyxZ+gYtGrWmx7ycdryhnDcgmGcAj+pWxVmYdLyfJWb8spi njfYnZa16lKDLRGpkGoXyyijMls5EUtm+tebDe2HszHA0Y1W02Jto/YWtTCPcmjJcEh8tWRlNs33 +FgRcRgFx2jAxuIAg946VcGegEp4VZhc0xMBFWp2YGZXfl4F87/55NWBWRrhvCfpEp1amMHNuNDB zErqFbM53d/QFFPyZ2RKOY3/Z6bozIUD7lqghz4cAwRGOkdbHhcq4tCF0oj6PQEHByML9EJQFlol xPQv2FpXcjTrWxkPU1BwYlEHNESCQqdTkSBkX+V2voJZLe+KeWXkjPI+U6gr0+w5IEeE9XX1rmv7 PRRNu0nuCIObD5o9z50xCHWhvqsnnyxtXvd4MBOU0a8qrNT0S6+CzdOp8Jqv2qxjLYirN1d+1aZw TUH6Cxo3FT6bnW/7/ACij9j0RIkgEc9lBw+kSzEbDUDnbDGTplllEv6tY9QsBIXcOWeXi+MMnV0c l+ac/XJxb+7sfGT5upxHDldXFku0UrrImNnCP1l8cAdk78L9aMyUNPaRu3Ap7Uz/gwA+mURDuv0P AAAA//8DAFBLAwQUAAYACAAAACEAaXeNX0UFAABLEAAAEQAAAHdvcmQvc2V0dGluZ3MueG1stFjb bts4EH1fYP/B8PM6Fqm7ULfQtU3RbBd1+gG0RNtEJFEg6Thusf++owtjJ2WLdIu+JNScuRwOZ8hJ Xr15aOrZPRWS8XY1R1fWfEbbkles3a3mn2+LRTCfSUXaitS8pav5icr5m9d//vHqGEmqFKjJGbho ZdSUq/leqS5aLmW5pw2RV7yjLYBbLhqi4FPslg0Rd4duUfKmI4ptWM3UaYkty5tPbvhqfhBtNLlY NKwUXPKt6k0ivt2ykk6/tIV4SdzRJOPloaGtGiIuBa2BA2/lnnVSe2v+rzcA99rJ/Y82cd/UWu+I rBds98hF9WjxEnq9QSd4SaWEA2pqTZC158DON44eY19B7GmLgyswR9awumTu/pwD/I0Dr2TVz/nw Jh9LsLzwI+nPuXG1G3lq6IN2JOuXpHaEPrCNIGIs3CmvTRld71ouyKYGOpDfGaRoNrDrf/aMX0PT fOG8mR2jjooSKgc6zrLmyx7Ys4quO1rXcGK5EFzIR/FbQRogwEpSXyBwwHy7VkSB/0hOlqt5WVMC dI7RbrASWjLYVHRLDrW6JZu14h0o3RPYtY8nDuWeCFIqKtYdKcFbylsleK31Kv43Vyl0roDCmiyG Pj6v1uOdABYtaSAPT/r8hle0Z3YQ7OUH1hsM0ZF7GfJ5IA53mIBc3fb5X6tTTQsgv2ZfaNxW7w9S MfA4dPsvMPgRAdr2kT9CxdyeOlpQog6Qpt8UbDiJombdDesL4rqtoJh+WzC23VIBARjU2g2UDxP8 OOT5HSUVPB2/GHd5WUbwEFVSLz5xrrSqZSW5hZEzMu3RM2J5CHmhEfF9H94WE5I4RTDV/TOkwCmy TQjCfuCbEReFyBgHJbjIjXFQ5tvfsSkcG+cmBDsYZcadYhelRWJEfC9FRgY2RoVuq2eIj9zcyM0O sW3Om2PbPjZ6cwI39jMT4iLbDYw7dT0rSI2nDYft57EZca3YmB3PQ0kaGJEYEmS2SRDSN+NTxEdW nBm5+aFfeMYKCbBr58adBp5vucbsBL5je8YzDUILp0ZuQezbttlbajuuMW+h5RexkXWIUOAaWYeJ k4dmmwwVgTFOjHxsroM4cZLYiCSZD21iRL57H6SWl8bG0049ODqjt9S3gjw1IoUXhMYcZLbvmbOT uW4aG88n85zQNXLLMsc35y23URob4+SOlce+EUltuMeMSI6TwJjrPHfDzNj1hYsDuzAiMfIyY9cX MXZdI7cCagcZGRSZU2RDnOUIwVvQRP1o/Y/Qq/5hnzWjRUqajWBkdtMP38teYyPuEtZqfENheKOX yPqw0eBiMQKyIXVdwOSjgeHgmqhissvodljXN0Tszn4nDWGUwpT1/tFXP+ZR8VbwQzeiR0G68cHW KshxJkvWqg+s0XJ52Ky1VQvj5gV0aKuP92LI0zk9x0jBwzsMPh/I8IAPurRdfF6PyS5rse4fZ3pD um584zc7tJrXbLdXqH+WFXxV8Dfa8LHZ4QnDA4ZHbPggZb8z0J4WZxnWsgs9W8vss8zRMucsc7XM Pcs8LfN62R6mKwGj7h2MG3rZy7e8rvmRVu/O+DeiMQlyTzqajZMwlBcfBdNoLGf3EX2AwZxWTMGf vh2rGvLQz+l4aIxJuyYnflBPdHusV+6eeqiIInrQeWI8lPgzLv2EXjIox/Wp2ZwH76uReM0kDGcd zOiKC439NWDIiSpeXkMnwWqQezjw7CIYb2jkDrO9uoUiv4Nz/0S3CZG0mjBt6o6mX600j9Mg8RdJ GGcLx8vQIixQvAgKHMZeZttB6v07Nan+L8Dr/wAAAP//AwBQSwMEFAAGAAgAAAAhAPJmbkgqAwAA ezYAABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbOybXW+bMBSG7yftPyDu2xwff2BHTSt1VadJ3Ye2 bvcEnAYNMMK0afrrZyBp03YXzcUWX1iJgjnGL7aPHw4HkZOz+6qM7nRrC1PPYnIMcaTrzORFfTOL f15fHsk4sl1a52lpaj2L19rGZ6fv352spis9/6G7zh1pI6dS22mVzeJl1zXTycRmS12l9tg0unaV C9NWaed225tJlba/b5ujzFRN2hXzoiy69QQBRLyRad+iYhaLItMXJrutdN0N7SetLp2iqe2yaOxW bfUWtZVp86Y1mbbWjacqR70qLepHGcJeCVVF1hprFt2xG8ymR4OUa05gKFXlkwDfTwBfCYisyPfT EBuNiWu5o2P1fjJ8K2PXlb6PoyqbfrqpTZvOS6fkpiZyo4sG4f63P9mpWyF5cWc322g17ftOJEGQ iaBD/dzk64uh7i4tXWU86a1ufVzpRbe1wqP1e3Gz/Iv52jSvjeem60z1wu76cZ63fal7alO7dR27 HfvQH9cXmjTTm3JmSuOWY3rbmVGi3OnZfi3nz3q0X9t2d+T7NJ3sDrp3x4dlUeYvfIKICQFF2eCU MP3/ZPrH4na79cPW+pwRyhFByMCIP4wwhoowKkVgxAdGkAJSTiUPjHgURxKZcIRkdEqY/kMzIlxk l5yFOOIPI5IpQI5JCCNeIEITJIoiG90REPEijCjpPpzywIgXjAhw+SEFBYERj9IRQiUCVeNzlDD9 h2bEBRKVCAy3Wv4wgowSToGOPgmzf2hEEnTeECFj9ymMcAZSKUpDxu4FIy6CCOAgMTDiDSPSXbOk gJCMeEGIkkS6L4QbLX8IYcQl7AKSkIv4gYhiElCgCoj4c6MlkBOCjI2RPUz/gRkhSEEyksD4ykOA xAdIkEhBRUhGfGGEJlQyjoGRw3npeQwBAEVDYPcqsCsmGLpPeHfuP+DwhotWQrggHJNw0fIqsCcE GIYE0Q9GpEQE6jAJjPgTSJCDEokQ4UGjF5AgCK6gfz0oQOINJJRTQjgACYwcipGNtT+ZabqiKh70 pWnPW7Oyuh37oMv11/rX56thLy1Ls/r25eN4jp2/jJ3+AQAA//8DAFBLAwQUAAYACAAAACEAtzOe A74NAAC2fwAADwAAAHdvcmQvc3R5bGVzLnhtbNSdS3PbOBLH71u134Gl0+4hsfWy7NQ4U44dr1Nj J57ImZwhErKwIQktH7E9n34BEJRINUGyQYyr5pJYIvsHEN3/Bpri45dfn6PQ+0mTlPH4fDR+ezzy aOzzgMWP56NvD9dvTkdempE4ICGP6fnohaajX9//8x+/PL1Ls5eQpp4AxOm7yD8fbbJs++7oKPU3 NCLpW76lsdi45klEMvExeTyKSPIj377xebQlGVuxkGUvR5Pj45ORxiR9KHy9Zj694n4e0ThT9kcJ DQWRx+mGbdOS9tSH9sSTYJtwn6apOOgoLHgRYfEOM54BUMT8hKd8nb0VB6N7pFDCfHys/orCPWCO A0wA4MRnAY5xohlHwrLCSSkOMy8x6UtEn0de5L/79BjzhKxCQRJD44mj8xRY/isbey+CI+D+FV2T PMxS+TG5T/RH/Un9d83jLPWe3pHUZ+xBdEYQIybgNxdxykZiCyVpdpEy0rhxI/9o3OKnWeXrDyxg oyPZYvqn2PiThOejyaT85lL2oPZdSOLH8jsav/m2rPak8tVKcM9HJHmzvJCGR/rAiv8rh7s9/KQa 3hKfqXbIOqMi7kXYSWjIpMwmi5Pyw9dcDjTJM64bUYDi/x32CIy4kIMQx7LQqNhK17fc/0GDZSY2 nI9UW+LLb5/uE8YTocPz0dmZ/nJJI3bDgoDGlR3jDQvo9w2Nv6U02H//+7XSkv7C53ks/p4u5ioK wjT4+OzTrVSm2BoT6ZPP0iCUe+ds37gy/18JG2tPNNlvKJHpyRsfIlT3UYiJtEgrR9vMzA+OXe2F amj6Wg3NXquh+Ws1pITwGg0tXquh09dqSGH+yoZYHNDnQoiwGUDt4hjUiOYYxIbmGLSE5hikguYY lIDmGAIdzTHEMZpjCFMEJ+O+KQorwT41RHs7t3uOsON2Twl23O4ZwI7bnfDtuN353Y7bnc7tuN3Z 247bnazx3GKp5X0SMouzwSpbc57FPKNeRp+H00gsWKpmc8OTkx5NnBykA0yR2fREPJjmE/W5O0KU SO3n80xWdR5fe2v2mCei1B/acRr/pKEouj0SBILnEJjQLE8MI2IT0wld04TGPnUZ2O6gshL04jxa OYjNLXl0xqJx4Hj4SqKTpLALaFE/b6RImIOgjoif8OFd48RZfrhl6fCxkhDvQx6G1BHrs5sQU6zh tYHCDC8NFGZ4ZaAwwwuDis9cDZGmORopTXM0YJrmaNyK+HQ1bprmaNw0zdG4adrwcXtgWahSfHXV Me5/7u4y5PIs++B+LNljTMQCYPh0o8+ZevckIY8J2W48eVa6GVs9Zmw7H3jw4j24mNN2JFfrehUi l+KoWZwPH9AazZW4djxH8trxHAlsxxsusTuxTJYLtBs39cwyX2WNolWkXqJdkjAvFrTD1Uay4RG2 F8A1S1JnMmjGOojgz3I5K93pIvPtezm8Y3vWcFkdZiWn3dNIB70Muf/DTRq+ednSRJRlPwaTrnkY 8icauCMus4QXsVaV/ES5pJfkP0bbDUmZqpVqiP5Tffn7vHdHtoMP6D4kLHbjt49vIsJCz90K4ubh 7tZ74FtZZsqBcQP8wLOMR86Y+kzgv77T1b/ddPBCFMHxi6OjvXB0ekjBLpmDSaYg8cARSSwzWcyc zKGK9xt9WXGSBG5o9wktLonJqCPikkTbYtHhQFsiLz6J/ONgNaR4f5CEyfNCrkT14ARWOW2Y5qv/ Un94qvvMPSdnhr7kmTr/qJa6ytodbvgyoYYbvkRQ3hTTg4xfBwdbww0/2BrO1cFehiRNmfEnVGue q8Mtea6Pd3jxp3k85Mk6D90NYAl0NoIl0NkQ8jCP4tTlESuewwNWPNfH6zBkFM/BKTnF+0/CAmfO UDBXnlAwV25QMFc+UDCnDhh+hU4FNvwynQps+LU6BczREqACcxVnTqd/R7/yVGCu4kzBXMWZgrmK MwVzFWfTK4+u12IR7G6KqSBdxVwF6W6iiTMabXlCkhdHyI8hfSQOTpAWtPuEr+W9EjwuLuJ2gJTn qEOHi+0C58rJ3+nKWdcky2W/HJwRJWHIuaNza/sJR1lWThzOzzrN1J0cg7twHxKfbngY0MRwTGZb US8vi9syDruvutHrtOcte9xk3nKzO9tfxZwcd1qWBXvNrLvBpjE/Ke9naTK7owHLo7Kj8GaKk2l/ YxXRNeNZt/F+JVGznPe0hG2edFvuV8k1y0VPS9jmaU9LpdOaZZserkjyozEQFm3xs6vxDMG3aIui nXFjs22BtLNsCsFFWxTVpOJd+L78tQB6p59mzPb9xGO2x6jITMHIyUzprSszok1gX+lPJmd2TNJU 7e2unjhsbqoW0b0y5+85L87b135w6n9T1yexcIpT6jVypv1/uKplGfM49k43ZkTvvGNG9E5AZkSv TGQ0R6UkM6V3bjIjeicpMwKdreCMgMtW0B6XraC9TbaCFJtsNWAVYEb0Xg6YEWihQgRaqANWCmYE SqjA3EqokIIWKkSghQoRaKHCBRhOqNAeJ1RobyNUSLERKqSghQoRaKFCBFqoEIEWKkSghWq5tjea WwkVUtBChQi0UCECLVS1XhwgVGiPEyq0txEqpNgIFVLQQoUItFAhAi1UiEALFSLQQoUIlFCBuZVQ IQUtVIhACxUi0EItbjW0Fyq0xwkV2tsIFVJshAopaKFCBFqoEIEWKkSghQoRaKFCBEqowNxKqJCC FipEoIUKEWihqh8LBwgV2uOECu1thAopNkKFFLRQIQItVIhACxUi0EKFCLRQIQIlVGBuJVRIQQsV ItBChYi2+NQ/UZousx/jz3oar9jv/9OV7tTX6q3cVdS0P6rslZnV/16ED5z/8BpvPJyqeqMfhK1C xtUpasPP6lWuuiQC9cPnl8v2O3yq9IEPXdL3QqjfTAF81tcSnFOZtYV81RIUebO2SK9aglXnrC37 Vi3BNDhrS7pKl+VFKWI6AsZtaaZiPDaYt2Xrijkc4rYcXTGEI9yWmSuGcIDb8nHFcO7J5HxoPe85 Tie760sBoS0cK4SFmdAWltBXZTqGwujrNDOhr/fMhL5uNBNQ/jRi8I41o9AeNqPsXA1lhnW1vVDN BKyrIcHK1QBj72qIsnY1RNm5GiZGrKshAetq++RsJli5GmDsXQ1R1q6GKDtXw6kM62pIwLoaErCu HjghGzH2roYoa1dDlJ2r4eIO62pIwLoaErCuhgQrVwOMvashytrVEGXnalAlo10NCVhXQwLW1ZBg 5WqAsXc1RFm7GqLaXK3OotRcjfJwxRy3CKsY4ibkiiEuOVcMLaqlirVltVQhWFZL0Felz3HVUtVp ZkJf75kJfd1oJqD8acTgHWtGoT1sRtm5GlctNbnaXqhmAtbVuGrJ6GpctdTqaly11OpqXLVkdjWu WmpyNa5aanK1fXI2E6xcjauWWl2Nq5ZaXY2rlsyuxlVLTa7GVUtNrsZVS02uHjghGzH2rsZVS62u xlVLZlfjqqUmV+OqpSZX46qlJlfjqiWjq3HVUqurcdVSq6tx1ZLZ1bhqqcnVuGqpydW4aqnJ1bhq yehqXLXU6mpctdTqaly1dCdMmINHQC0jkmSeu+fF3ZB0k5HhDyf8Fic05eFPGnjoQz16qr2zSrah 3jAn9s/EgcrHllfuMQqKx7ZqoNrxU7B7t5Q0lj3y9Fu89Neq4/o31qJFZdjR1A6uf+CdAPz+dVKq hRURR/VFjgpoXHqr/L7EXW5IUmzdx1G5j1bKvs9P75JUFO968/Hx1dVscXpR7AXeLLaST/UShzMu Xi1WfLzIM6530aOnX0Cm91Kf4E7Fe8l2ryjTbyXLbuV70YrmefEcptufYdm90q+6Y42vfZOXU+QJ o4n3mT5J+v5Faw8soqn82vvKI6JCSb3yDZj4af2rwgvFv5ep+r/y5jf9m3PtzW/qu8oL3Axx4QtX EV8/iMwQgvqBwrs74tTjhA8jxvDUYUMUaMntdVTsV1NRazxnMnu19Fllt1btFAnQGKY6Trt6KPqz CosoEH98imUgP+moKnoaPJMCJbZf0jC8I8XefGveNaTrrNg6PlbPnzjYvioepWi0T9ScawQc1TtT fGyPk+LlCvpiEGOqkhNLw3CrK5OGjnSPWKh7X54TBJ0pZj21qSmzVcPG0N/yvv+DrDWfX17o6dv0 PsTq2xBnh3nn4G2I9bj6wJOAJmoGKeJGtSqfO64P/E+xBlF/iDbLpObLiX1P3kWVle0u4qysy3i0 MmYiQQb0Zpj5H3bmhTR2w99HKc0zrVTA/pbiw6hUC7L95qbIbA/KqZ4CzNPqxXgxWVzVApSpbCWj Ql4eqIPXl09rec5yEuoHR1SCEr28eLi7rT2I8/C45Q71R3V2HXptuXGAb112aNU2JPD6OE3PJtPT upBFfimkR1blfnLQ5KFuuZioz8a6iDHtMD6d6oWUaY/JoixCTHtMT8oLe017zOZlv017zGdnHT09 mY07erqYTjp6ejopL4JrGbCOnoqV26JrUI/Pzjr6Oh6fHXd0djw5LZdPxl2mi/LyOuMus5O56q5M EDpaBqb/111a/gWLST9PxYyhSp/DhUKjcDtzg7fX90GCaFygdqaLrlRhzgt/e9/sPbEruMHw77bg RnzIUro+4qeX09lcF4J6xNXsvN/j+Pj6Wrdafqmnd7fhWi1rwTiVlfLg8CxrcdMwNkVltVj++xWj 5V/p+/8DAAD//wMAUEsDBBQABgAIAAAAIQArkfcDbgEAAPMCAAARAAgBZG9jUHJvcHMvY29yZS54 bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACckktvgzAMgO+T9h9Q7hBo9yoC Km1TT6s0aZ027ZYlbpuVPJSkpf33C1DoUHvazY4/fxgn2XQvymAHxnIlc5REMQpAUsW4XOXofTEL H1BgHZGMlEpCjg5g0bS4vsqoTqky8GqUBuM42MCbpE2pztHaOZ1ibOkaBLGRJ6QvLpURxPnUrLAm dENWgEdxfIcFOMKII7gWhro3oqOS0V6pt6ZsBIxiKEGAdBYnUYJPrAMj7MWGpvKHFNwdNFxEu2JP 7y3vwaqqomrcoH7+BH/OX96aXw25rHdFARUZo6njroQiw6fQR3b7/QPUtcd94mNqgDhlipnxBsVt 8MaFkg3Wleqlb+BQKcOsFwwyjzGw1HDt/FW2+sGBp0ti3dzf7ZIDezycfemcqJsM7Hj9OopRQ/Rp dlx1Ox2wwK8obRfaVT7GT8+LGSpGcXIfxpMwuVnEk3R8m8bxVz3goP8kFMcB/m3sBO2Ohs+0+AUA AP//AwBQSwMEFAAGAAgAAAAhALUeJTpVBwAAXYIAABIAAAB3b3JkL251bWJlcmluZy54bWzsnd1u o0YUx+8r9R0sS73MwvAxgLXZFf6g3Wq7qrqpek3wJEbLlwDbyW1fpo/Qx+ordAYMxotNmHHckO65 iWOYczznP+eMf5zg+O37hzAYbUia+XF0PUZv5PGIRF689KP76/HvN86VOR5luRst3SCOyPX4kWTj 9+++/+7tdhKtw1uS0oEj6iPKJtvEux6v8jyZSFLmrUjoZm9C30vjLL7L33hxKMV3d75HpG2cLiVF RnLxW5LGHsky6mfmRhs3G+/ceQ/9vC1Td0uNmUNN8lZumpOHvQ/E7USXLMlsO1IEHNEIFdR2pXK7 whKbVcuRJuSIzqrlSRfzdCQ4LOZJaXsyxDypbU+mmKdWOoXtBI8TEtGTd3Eaujl9mt5LoZt+WSdX 1HHi5v6tH/j5I/Up48qN60dfBGZErWoPobrk9mBIYbwkgbqsvMTX43UaTXb2V7U9m/qktN89VBZp n/hLk3nsrUMS5UXkUkoCqkUcZSs/qSs8FPVGT64qJ5uuIDZhUI3bJqhnuZzanuallHuHfaa/0z8M ypl3e0RyjxVhLmqLPlM4fM1qJiHNwv0LC0nTEBf13EAqB0rLAfb8nild+SjVpPFQy4afjPC50Ss3 2WO4L/Vtcn9etvyYxutk780/z9uHfe1v2dswh69d1jUrITtvMp9XbkK3hNCbfLiP4tS9DeiMaA6N aBqMihVgP+mqjFjRjd9RVnBvszx1vfzTOhwdPPtAF50yB7WcpISCRsoOllhh3+UknabE/cKGMC9R xnxONm5AUWWmImWqW2OJnQnXQe5/JBsS3DwmpBqzerxN/eUv7FzAzpVj8zAJqhFTW8cLx9HKM8GG nfDpQzmpSZ4EdMs3F4apWLpdzKGYYz2J0o6SkBPWB2/XQUDy2uMNeahPXdVHf/aqYwG52w1Ofk3Z gx+xINnh67GhFPNYudF9QWQqltlYqR6c7h6cOMozJm3m+TTXZm7g09iZLXGz3M5894auNF2n0KdL 9pNNpSwcs18OhnvZwdOVH9FpLMmdS1XcvXTxmlIRxteqob1qsiZbsiyrxRG6ddP9f0PYiLNVjHlV RJomKGO8Tn2Sjj6RbVOtw6OFYl8N5FNNaammP79q//z5F69uCsJiuv1BR7NLiKyh2uExPoHKJGoK VCbaMwv0N7dApikm0OfH8DYOGuo0DvBJow2y4qgOg664sr6GV3GaKrjhP3fF4YFWnC4LbuXPV3HG ICtONwT36v+o4syBVhzWBLfw8ytOOiBh9hqdmMwKkB+TF0hDtjUt4xfFZNleLKaOhmtx62VtYDKe 25qtItxexh1eAyYDJgMmAyYDJlfCACaLVRxgMmCyWMUBJotV3OvBZEYJ3JismLaJLUUp4xfFZFW1 Z7Y5n9Xi1svawOR6n3iJfUEUlJ9vWwD0BfQF9AX0BfQVqzhAX0BfsYoD9BWruNeDvizL+NF3IU9l yzLK+EXR15ZnpmUqi1rcelkb6KtqtmIu5mZ7GTXOZYQOMWDyEdUAkwGTAZMBkwGTnxQIMPmUMIDJ /3NMZjs9NyZrMrYUB+96u6KYPJ8pC1O3uzHZMnTTsPWXuJGCrZlQ7gMmNzFZFiyFbxyTkSkIO98M Jusv/vebgWKyMuwL06FismoN5MJ0qJis4Re/MB0oJmvDvjAdLCajF7sw5cRkphc/JmMHy4Zz5sfy 0BTNdCx330gB9xtDNxm6yYDJRwSCbvJxYaCbLFZx0E2GbrJYxUE3WaziXk83mZUkNybrczQ31Or/ Tgjfb6zNTRsvdl6ay9q86cJ0bG2KyjlAN/kVYjJ0k6GbfIk3begmnxAGusliFQfdZOgmi1UcdJPF Ku71dJNZ3nFjMnYUWZ/bZ34sb2YjrJuL7psuDN3ChmEfuTeZdxmhm/wymAzdZOgmX+JNG7rJJ4SB brJYxUE3GbrJYhUH3WSxins93WSmoAAmzww8VbQyflFMdmRV0Uxt56W5rA1MRtoCK/b0JbrJgMnP sYUAJottIYDJgMliFQeYLFZxgMmAyWIVB5gsVnGvB5OtsQAmG7qzwDY68yN8KpIVg/0dpxK3XtYG JpuUkh1kLHou45J4fujuXuyrdfwBXZ6UzyVbxNZDJH+DeEvSjySny3Y8eOUNb/BPAW5P7ETTc0L6 LQ7d6HhE6rGIUv9+xcGeqEy/7pDaoOgIhtSZnhr3Cj1Fij3h7nJJp3OH9BTj9SSviyUd5k+6Fn71 Sro2K10k6QzuFXoKlnryzeWSzuQP6QnM6QkfF0s6iz/pWgRyIuk4cQExp/y8MNNlHZtnfnfC3EQz VbfsWot6JRq8MLexNjOQ3VZeO6Y8tNWgrQZtNWirdQkEbTVoq/XiOmir8ZEitNWgrcal26DaalHB x1H1lWLs0AEsVxEVn+CXipEtM+W0WRXYMTP1tJnRYdb6BuG9WXFj6Akz/bRZ8T1mJ8zKfydw1Ax1 BWectlM7zMr7TY+aFeR/wsw6bWZ2mO0+BXY8ui67jkTRm3blY3lx9e5fAAAA//8DAFBLAwQUAAYA CAAAACEACQLnYEkCAAClCAAAEgAAAHdvcmQvZm9udFRhYmxlLnhtbLyUS4+bMBRG95X6H5D3EwyB vDRk1E4nUjdddKbq2jEmsYpt5Ete/77XPJLMhKihi4CE4LN9jI98/fi0V7m3FRak0QkJBpR4QnOT Sr1KyK+3xcOEeFAynbLcaJGQgwDyNP/86XE3y4wuwcPxGmaKJ2RdlsXM94GvhWIwMIXQ2JgZq1iJ n3blK2b/bIoHblTBSrmUuSwPfkjpiDQYewvFZJnk4pvhGyV0WY33rciRaDSsZQEtbXcLbWdsWljD BQCuWeU1TzGpj5ggugApya0Bk5UDXEzzRxUKhwe0elP5CRD3A4QXgBGXaT/GqGH4OPKMA6IfJm4x cFBiTzzFZ99X2li2zJGEajxcnVeB3dNNNm/2hrebaaaw1zPL5dLKqqFg2oAIsG3L8oTQkC5ojE93 R3TonsR3HfmaWRAOUnekdZwxJfNDm8JOAtQNhSz5us23zEr3h3UTyBU2bGBJE/JCKQ2/LBakTgL8 O5dE469NErq5qmvaJMNjQl3CK071GdQcXnGOfXBOvzZwacJsrBTW+yF2V2yM0cG0suGsRL1sKJMK qzt0ZHIv0isuXj66GE+i4T1cvEklwJnwfhrF9BUfIR2hkRhNOB/DXj5sxe29OzqMxHfZHb/xAHIH L3S6iFvE6ep2EXa5YJvS9FJxvqhaRfA+Oalok04Vk/fJjSpeD2pp8iseYjxi3TE7xr3h6mTcw0P/ PfFhkXcW8cwUHp3sSnW4qqirw1VJv7Pz/6qDhufVEbkkOiY3mqg+g+m/qqN5gflfAAAA//8DAFBL AwQUAAYACAAAACEAVZ/HYd8BAADhAwAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcU8Fu2zAMvQ/YPxi6N3LSLQsCRcWQYuhhWwvEbc+aTCfC ZEmQ2KDZ14+yF0/ZdppPj0/04xNJiZvX3lZHiMl4t2HzWc0qcNq3xu037LH5dLViVULlWmW9gw07 QWI38u0b8RB9gIgGUkUSLm3YATGsOU/6AL1KMzp2dNL52CukMO657zqj4dbrlx4c8kVdLzm8IrgW 2qswCbJRcX3E/xVtvc7+0lNzCqQnRQN9sApBfs1/2lnrsRd8YkXjUdnG9CBroqdAPKg9JPle8BGI Zx/bJOeL65XgIxbbg4pKI7VQfqiXc8ELQnwMwRqtkLorvxgdffIdVveD5SoLCF6mCLrGDvRLNHjK TspQfDYue6HKIyJzUe2jCgdytMwWp1DstLKwpRbITtkEgv8mxB2oPN4HZbLDI66PoNHHKpkfNOAF q76pBLlxG3ZU0SiHbEwbgwHbkDDKxqAl7SkeYJlWYvNOzocEApeJQzB4IHzpbqiQ7ju6G/7D7Lw0 O3gYrRZ2SmfnGn+obn0flKMO8wlRh7+nx9D427wev3p4SRaDfzZ42AWlaSirxeq6XIHiSOyIhZZm Og1lIsQdXSHaXID+dXtozzl/H+SlehpfLM19VtM3bNGZo02YnpL8CQAA//8DAFBLAQItABQABgAI AAAAIQAykW9XZgEAAKUFAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhAB6RGrfvAAAATgIAAAsAAAAAAAAAAAAAAAAAnwMAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAFvcdqVcAQAA+wYAABwAAAAAAAAAAAAAAAAAvwYAAHdvcmQvX3JlbHMvZG9j dW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAn9aI87YlAADuxQEAEQAAAAAAAAAAAAAAAABd CQAAd29yZC9kb2N1bWVudC54bWxQSwECLQAUAAYACAAAACEAMN1DKQIGAACkGwAAFQAAAAAAAAAA AAAAAABCLwAAd29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAGl3jV9FBQAASxAA ABEAAAAAAAAAAAAAAAAAdzUAAHdvcmQvc2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAPJmbkgq AwAAezYAABQAAAAAAAAAAAAAAAAA6zoAAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgA AAAhALczngO+DQAAtn8AAA8AAAAAAAAAAAAAAAAARz4AAHdvcmQvc3R5bGVzLnhtbFBLAQItABQA BgAIAAAAIQArkfcDbgEAAPMCAAARAAAAAAAAAAAAAAAAADJMAABkb2NQcm9wcy9jb3JlLnhtbFBL AQItABQABgAIAAAAIQC1HiU6VQcAAF2CAAASAAAAAAAAAAAAAAAAANdOAAB3b3JkL251bWJlcmlu Zy54bWxQSwECLQAUAAYACAAAACEACQLnYEkCAAClCAAAEgAAAAAAAAAAAAAAAABcVgAAd29yZC9m b250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAFWfx2HfAQAA4QMAABAAAAAAAAAAAAAAAAAA1VgA AGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAAwADAABAwAA6lsAAAAA ------=_NextPart_000_0112_01D32D1C.79BF9810-- From nobody Sun Sep 17 11:28:19 2017 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FEC13209C; Sun, 17 Sep 2017 11:28:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150567289723.617.7244560866673936699@ietfa.amsl.com> Date: Sun, 17 Sep 2017 11:28:17 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-07.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 18:28:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Alexandre Petrescu Nabil Benamar Jérôme Härri Christian Huitema Jong-Hyouk Lee Thierry Ernst Tony Li Filename : draft-ietf-ipwave-ipv6-over-80211ocb-07.txt Pages : 38 Date : 2017-09-17 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. In addition, the document lists what is different in 802.11-OCB (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, where IPv6 protocols operate without issues. Most notably, the operation outside the context of a BSS (OCB) impacts IPv6 handover behaviour and IPv6 security. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-07 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-07 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/ From nobody Sun Sep 17 11:29:32 2017 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 D727C13263F for ; Sun, 17 Sep 2017 11:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 te3I30bBRlR8 for ; Sun, 17 Sep 2017 11:29:26 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 53A3B1321CB for ; Sun, 17 Sep 2017 11:29:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8HITKwM067201; Sun, 17 Sep 2017 20:29:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D30DA206EC7; Sun, 17 Sep 2017 20:29:20 +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 C4A05206C09; Sun, 17 Sep 2017 20:29:20 +0200 (CEST) Received: from [132.166.84.94] ([132.166.84.94]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8HITJcw030416; Sun, 17 Sep 2017 20:29:20 +0200 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= Cc: its@ietf.org References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> <011101d32d3e$00cc7d20$02657760$@gmail.com> From: Alexandre Petrescu Message-ID: <75e59482-38b7-c1c7-a09d-67de78588ad4@gmail.com> Date: Sun, 17 Sep 2017 20:29:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <011101d32d3e$00cc7d20$02657760$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] -06 comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 18:29:31 -0000 Mr. Simon, We received your comments and tried to resolve them. 1. This is the changelog that solves simple things. I invite you to look how they are solved in the new version, -07. o Added new terms: OBRU and RSRU ('R' for Router). Refined the existing terms RSU and OBU, which are no longer used throughout the document. o Improved definition of term "802.11-OCB". o Clarified that OCB does not "strip" security, but that the operation in OCB mode is "stripped off of all .11 security". o Clarified that theoretical OCB bandwidth speed is 54mbits, but that a commonly observed bandwidth in IP-over-OCB is 12mbit/s. o Corrected typographical errors, and improved some phrasing. 2. I would like to ask you three questions: Do you know whether there is an EtherType allocated by IEEE for WAVE messages? I noticed in packets BSM-over-802.11-OCB that the used type is 0x88DC. Packet available upon request. This value is in LLC Header, Type Field. It is understood by the Wireshark tool. But I dont see it listed at IANA, IEEE 802 Numbers: https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml But on that page I do see 0x8947 for GeoNetworking and 0x86DD for IPv6. Do you think this existing text is wrong?: > At the time of writing, the prohibition [of IPv6] is explicit at > higher layer protocols providing services to the application; these > higher layer protocols are specified in IEEE 1609 documents, i.e. > the "WAVE" stack. Finally, in your review, when you read the -06 text saying "Some channels are reserved for safety communications; the IPv6 packets should not be sent on these channels." you are commenting in your review that "This assumes that Safety applications would not use IPv6; erroneous assumption." My question is the following: do you want text deleted? Which one? Or is it just a comment? Know that some WG members already suggested that "IPv6 packets should be sent on the channels reserved for safety". Alex Le 14/09/2017 à 11:44, François Simon a écrit : > Mr. Petrescu, > > Find attached comments on version 06 of the document. > > Let me know if you have any questions. > > Francois Yves Simon > > Lojik Technologies > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre > Petrescu *Sent:* Sunday, September 10, 2017 9:58 AM *To:* > its@ietf.org *Subject:* [ipwave] Fwd: New Version Notification for > draft-ietf-ipwave-ipv6-over-80211ocb-05.txt > > Dear participants to IPWAVE WG, > > This is the new IPv6-over-802.11-OCB addressing all the Reviewers > comments. > > This is the ChangeLog: > > o Lengthened the title and cleanded the abstract. o Added text > suggesting LLs may be easy to use on OCB, rather than GUAs based on > received prefix. o Added the risks of spoofing and hijacking. o > Removed the text speculation on adoption of the TSA message. o > Clarified that the ND protocol is used. o Clarified what it means "No > association needed". o Added some text about how two STAs discover > each other. o Added mention of external (OCB) and internal network > (stable), in the subnet structure section. o Added phrase explaining > that both .11 Data and .11 QoS Data headers are currently being used, > and may be used in the future. o Moved the packet capture example > into an Appendix Implementation Status. o Suggested moving the > reliability requirements appendix out into another document. o Added > a IANA Consiserations section, with content, requesting for a new > multicast group "all OCB interfaces". o Added new OBU term, improved > the RSU term definition, removed the ETTC term, replaced more > occurences of 802.11p, 802.11 OCB with 802.11-OCB. o References: * > Added an informational reference to ETSI’s IPv6-over- GeoNetworking. > * Added more references to IETF and ETSI security protocols. * > Updated some references from I-D to RFC, and from old RFC to new RFC > numbers. * Added reference to multicast extensions to IPsec > architecture RFC. * Added a reference to 2464-bis. * Removed FCC > informative references, because not used. o Updated the affiliation > of one author. o Reformulation of some phrases for better > readability, and correction of typographical errors. > > Alex > > -------- Message transféré -------- > > *Sujet : * > > > > New Version Notification for > draft-ietf-ipwave-ipv6-over-80211ocb-05.txt > > *Date : * > > > > Sun, 10 Sep 2017 06:55:20 -0700 > > *De : * > > > > internet-drafts@ietf.org > > *Pour : * > > > > Nabil Benamar , > Christian Huitema , > Jong-Hyouk Lee , > Jérôme Härri > , Alexandre Petrescu > , Tony > Li , Alexandre Petrescu > , > Jerome Haerri > , Thierry Ernst > , > ipwave-chairs@ietf.org > > A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt > > has been successfully submitted by Alexandre Petrescu and posted to > the > > IETF repository. > > Name: draft-ietf-ipwave-ipv6-over-80211ocb > > Revision: 05 > > Title: Transmission of IPv6 Packets over IEEE 802.11 Networks > operating in mode Outside the Context of a Basic Service Set > (IPv6-over-80211-OCB) > > Document date: 2017-09-10 > > Group: ipwave > > Pages: 37 > > URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-05.txt > > > Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ > > > Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05 > > > Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-05 > > > Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-05 > > Abstract: > > In order to transmit IPv6 packets on IEEE 802.11 networks run > outside > > the context of a basic service set (OCB, earlier "802.11p") there is > > a need to define a few parameters such as the supported Maximum > > Transmission Unit size on the 802.11-OCB link, the header format > > preceding the IPv6 header, the Type value within it, and others. > > This document describes these parameters for IPv6 and IEEE > 802.11-OCB > > networks; it portrays the layering of IPv6 on 802.11-OCB similarly > to > > other known 802.11 and Ethernet layers - by using an Ethernet > > Adaptation Layer. > > In addition, the document lists what is different in 802.11-OCB > > (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, > > where IPv6 protocols operate without issues. Most notably, the > > operation outside the context of a BSS (OCB) has impact on IPv6 > > handover behaviour and on IPv6 security. > > > > 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 > From nobody Sun Sep 17 12:33:11 2017 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 5B8C913330C for ; Sun, 17 Sep 2017 12:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 bPUYxUdaCQI8 for ; Sun, 17 Sep 2017 12:33:05 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 5A663132D42 for ; Sun, 17 Sep 2017 12:33:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8HJX2Dp005160 for ; Sun, 17 Sep 2017 21:33:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D155E20D119 for ; Sun, 17 Sep 2017 21:33:02 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C81DD20D0F7 for ; Sun, 17 Sep 2017 21:33:02 +0200 (CEST) Received: from [132.166.84.94] ([132.166.84.94]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8HJX2C2014265 for ; Sun, 17 Sep 2017 21:33:02 +0200 To: its@ietf.org References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> <011101d32d3e$00cc7d20$02657760$@gmail.com> <75e59482-38b7-c1c7-a09d-67de78588ad4@gmail.com> From: Alexandre Petrescu Message-ID: <541905b5-3c4b-337b-21a2-d421d9cd28bc@gmail.com> Date: Sun, 17 Sep 2017 21:33:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <75e59482-38b7-c1c7-a09d-67de78588ad4@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] -06 comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 19:33:10 -0000 Le 17/09/2017 à 20:29, Alexandre Petrescu a écrit : [...] > Finally, in your review, when you read the -06 text saying "Some > channels are reserved for safety communications; the IPv6 packets should > not be sent on these channels." you are commenting in your review that > "This assumes that Safety applications would not use IPv6; erroneous > assumption."  My question is the following: do you want text deleted? > Which one?  Or is it just a comment?  Know that some WG members already > suggested that "IPv6 packets should be sent on the channels reserved for > safety". I meant "_not_ be sent on the channels reserved for safety", obviously. Alex > > Alex > > > > > Le 14/09/2017 à 11:44, François Simon a écrit : >> Mr. Petrescu, >> >> Find attached comments on version 06 of the document. >> >> Let me know if you have any questions. >> >> Francois Yves Simon >> >> Lojik Technologies >> >> *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre >> Petrescu *Sent:* Sunday, September 10, 2017 9:58 AM *To:* >> its@ietf.org *Subject:* [ipwave] Fwd: New Version Notification for >> draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >> >> Dear participants to IPWAVE WG, >> >> This is the new IPv6-over-802.11-OCB addressing all the Reviewers >> comments. >> >> This is the ChangeLog: >> >> o Lengthened the title and cleanded the abstract. o Added text >> suggesting LLs may be easy to use on OCB, rather than GUAs based on >> received prefix. o Added the risks of spoofing and hijacking. o >> Removed the text speculation on adoption of the TSA message. o >> Clarified that the ND protocol is used. o Clarified what it means "No >> association needed". o Added some text about how two STAs discover >> each other. o Added mention of external (OCB) and internal network >> (stable), in the subnet structure section. o Added phrase explaining >> that both .11 Data and .11 QoS Data headers are currently being used, >> and may be used in the future. o Moved the packet capture example >> into an Appendix Implementation Status. o Suggested moving the >> reliability requirements appendix out into another document. o Added >> a IANA Consiserations section, with content, requesting for a new >> multicast group "all OCB interfaces". o Added new OBU term, improved >> the RSU term definition, removed the ETTC term, replaced more >> occurences of 802.11p, 802.11 OCB with 802.11-OCB. o References: * >> Added an informational reference to ETSI’s IPv6-over- GeoNetworking. * >> Added more references to IETF and ETSI security protocols. * >> Updated some references from I-D to RFC, and from old RFC to new RFC >> numbers. * Added reference to multicast extensions to IPsec >> architecture RFC. * Added a reference to 2464-bis. * Removed FCC >> informative references, because not used. o Updated the affiliation >> of one author. o Reformulation of some phrases for better >> readability, and correction of typographical errors. >> >> Alex >> >> -------- Message transféré -------- >> >> *Sujet : * >> >> >> >> New Version Notification for >> draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >> >> *Date : * >> >> >> >> Sun, 10 Sep 2017 06:55:20 -0700 >> >> *De : * >> >> >> >> internet-drafts@ietf.org >> >> *Pour : * >> >> >> >> Nabil Benamar , >> Christian Huitema , >>  Jong-Hyouk Lee , >> Jérôme Härri >> , Alexandre Petrescu >> , Tony >> Li , Alexandre Petrescu >> , >> Jerome Haerri >> , Thierry Ernst >> , >> ipwave-chairs@ietf.org >> >> A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >> >> has been successfully submitted by Alexandre Petrescu and posted to >> the >> >> IETF repository. >> >> Name:          draft-ietf-ipwave-ipv6-over-80211ocb >> >> Revision:      05 >> >> Title:         Transmission of IPv6 Packets over IEEE 802.11 Networks >> operating in mode Outside the Context of a Basic Service Set >> (IPv6-over-80211-OCB) >> >> Document date: 2017-09-10 >> >> Group:         ipwave >> >> Pages:         37 >> >> URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >> >> >> >> Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ >> >> >> >> Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05 >> >> >> >> Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-05 >> >> >> >> Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-05 >> >> >>  Abstract: >> >> In order to transmit IPv6 packets on IEEE 802.11 networks run >> outside >> >> the context of a basic service set (OCB, earlier "802.11p") there is >> >> a need to define a few parameters such as the supported Maximum >> >> Transmission Unit size on the 802.11-OCB link, the header format >> >> preceding the IPv6 header, the Type value within it, and others. >> >> This document describes these parameters for IPv6 and IEEE >> 802.11-OCB >> >> networks; it portrays the layering of IPv6 on 802.11-OCB similarly >> to >> >> other known 802.11 and Ethernet layers - by using an Ethernet >> >> Adaptation Layer. >> >> In addition, the document lists what is different in 802.11-OCB >> >> (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, >> >> where IPv6 protocols operate without issues.  Most notably, the >> >> operation outside the context of a BSS (OCB) has impact on IPv6 >> >> handover behaviour and on IPv6 security. >> >> >> >> 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 >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Mon Sep 18 03:42:13 2017 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 18850134220 for ; Mon, 18 Sep 2017 03:42:11 -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=onboardsecurity.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 58Iih6SqeNNR for ; Mon, 18 Sep 2017 03:42:08 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 A86211321C7 for ; Mon, 18 Sep 2017 03:42:07 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id 13so1391382wmq.2 for ; Mon, 18 Sep 2017 03:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uvHKB5RACTSeQ+rfBmmxGuYx8IFU6KVqR6Npqpbm4y0=; b=EcIX5SH/8ny/1OLH4OBgIjf6PjpDArPMHo5YHsITz2PRI0k+2EkFz/mCfXb26fsAYh NvAqZZ8EO0QN38XMxsP01M6T5EofW/A/2eYTOYLpaPxNKza7V9tj/pYq6LHDCa5ddOmN 9i67ON6+MLh//YpaFuAs4MXX32KZzb2czhR4o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uvHKB5RACTSeQ+rfBmmxGuYx8IFU6KVqR6Npqpbm4y0=; b=pUiELO+wR6Z8ly5eijn2VXJHyxOb0wGsV/AKtHR4wT04R7T1SzJ6ElEj/yD6/f/c0b AVFqmLMLrxWzTNipJLtsrnYXLAypL+9NaOZ97FcM1I8SDGZUWt/O9g8wODdKr0e+xTcw ve6f3xFgxkQq0OIQZJH9AHUEGxdFpt70nbRJmvjewp7uaAlT0+O/JMvvOClycMGT8LnX OmdUfb7VxBnpGH6xbVkSKP6Mcjl48tIEl4WDca4davDYIb2OP4sy+x+F9lqm0RUSuOtu 84F2k8GHK5lc73AHe2YeQbqOJsV1JRg1iv33SK3MTdOKy49EaK9+CEihrtr6vckoniTA qO8A== X-Gm-Message-State: AHPjjUiwRqCfM7EdJuyDPPrMpnuftzanNWR9+RMsHvj1HPp3ZTHuYrTc SWc1hESuPGojjeQvrhGLGJSmaSgBe2ZvA70U0hk/Ng== X-Google-Smtp-Source: AOwi7QAtW00FKTmS0lK4msBK2SAw7K6LQ9gOZJ8/XaaS1uNhDN7m8SGAW5HtBAav3oViGkZ7qIMIaQb8wYi4BJsy9GY= X-Received: by 10.28.29.71 with SMTP id d68mr2767371wmd.114.1505731325840; Mon, 18 Sep 2017 03:42:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.150.83 with HTTP; Mon, 18 Sep 2017 03:41:44 -0700 (PDT) In-Reply-To: <541905b5-3c4b-337b-21a2-d421d9cd28bc@gmail.com> References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> <011101d32d3e$00cc7d20$02657760$@gmail.com> <75e59482-38b7-c1c7-a09d-67de78588ad4@gmail.com> <541905b5-3c4b-337b-21a2-d421d9cd28bc@gmail.com> From: William Whyte Date: Mon, 18 Sep 2017 06:41:44 -0400 Message-ID: To: Alexandre Petrescu Cc: "its@ietf.org" Content-Type: multipart/alternative; boundary="001a114b879acde1210559746432" Archived-At: Subject: Re: [ipwave] -06 comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 10:42:11 -0000 --001a114b879acde1210559746432 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, > Do you know whether there is an EtherType allocated by IEEE for WAVE mess= ages? The IANA listing isn't the definitive listing of ethertype values. The definitive listing is at http://standards-oui.ieee.org/ethertype/eth.txt, which assigns 88dc to "Wireless Access in a Vehicle Environment (WAVE) Short Message Protocol (WSM) as defined in IEEE P1609.3." BTW, note that "WAVE messages" isn't the best terminology to use -- this is an identifier for WAVE *Short* Messages, or WSMs. "WAVE messages" is a term with no defined meaning. Cheers, William On Sun, Sep 17, 2017 at 3:33 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 17/09/2017 =C3=A0 20:29, Alexandre Petrescu a =C3=A9crit : > [...] > >> Finally, in your review, when you read the -06 text saying "Some >> channels are reserved for safety communications; the IPv6 packets should >> not be sent on these channels." you are commenting in your review that >> "This assumes that Safety applications would not use IPv6; erroneous >> assumption." My question is the following: do you want text deleted? >> Which one? Or is it just a comment? Know that some WG members already >> suggested that "IPv6 packets should be sent on the channels reserved for >> safety". >> > > I meant "_not_ be sent on the channels reserved for safety", obviously. > > Alex > > > >> Alex >> >> >> >> >> Le 14/09/2017 =C3=A0 11:44, Fran=C3=A7ois Simon a =C3=A9crit : >> >>> Mr. Petrescu, >>> >>> Find attached comments on version 06 of the document. >>> >>> Let me know if you have any questions. >>> >>> Francois Yves Simon >>> >>> Lojik Technologies >>> >>> *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre >>> Petrescu *Sent:* Sunday, September 10, 2017 9:58 AM *To:* >>> its@ietf.org *Subject:* [ipwave] Fwd: New Version Notification for >>> draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>> >>> Dear participants to IPWAVE WG, >>> >>> This is the new IPv6-over-802.11-OCB addressing all the Reviewers >>> comments. >>> >>> This is the ChangeLog: >>> >>> o Lengthened the title and cleanded the abstract. o Added text >>> suggesting LLs may be easy to use on OCB, rather than GUAs based on >>> received prefix. o Added the risks of spoofing and hijacking. o >>> Removed the text speculation on adoption of the TSA message. o >>> Clarified that the ND protocol is used. o Clarified what it means "No >>> association needed". o Added some text about how two STAs discover >>> each other. o Added mention of external (OCB) and internal network >>> (stable), in the subnet structure section. o Added phrase explaining >>> that both .11 Data and .11 QoS Data headers are currently being used, >>> and may be used in the future. o Moved the packet capture example >>> into an Appendix Implementation Status. o Suggested moving the >>> reliability requirements appendix out into another document. o Added >>> a IANA Consiserations section, with content, requesting for a new >>> multicast group "all OCB interfaces". o Added new OBU term, improved >>> the RSU term definition, removed the ETTC term, replaced more >>> occurences of 802.11p, 802.11 OCB with 802.11-OCB. o References: * >>> Added an informational reference to ETSI=E2=80=99s IPv6-over- GeoNetwor= king. * >>> Added more references to IETF and ETSI security protocols. * >>> Updated some references from I-D to RFC, and from old RFC to new RFC >>> numbers. * Added reference to multicast extensions to IPsec >>> architecture RFC. * Added a reference to 2464-bis. * Removed FCC >>> informative references, because not used. o Updated the affiliation >>> of one author. o Reformulation of some phrases for better >>> readability, and correction of typographical errors. >>> >>> Alex >>> >>> -------- Message transf=C3=A9r=C3=A9 -------- >>> >>> *Sujet : * >>> >>> >>> >>> New Version Notification for >>> draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>> >>> *Date : * >>> >>> >>> >>> Sun, 10 Sep 2017 06:55:20 -0700 >>> >>> *De : * >>> >>> >>> >>> internet-drafts@ietf.org >>> >>> *Pour : * >>> >>> >>> >>> Nabil Benamar , >>> Christian Huitema , >>> Jong-Hyouk Lee , >>> J=C3=A9r=C3=B4me H=C3=A4rri , >>> Alexandre Petrescu >> Alexandre.Petrescu@cea.fr>, Tony >>> Li , Alexandre Petrescu < >>> alexandre.petrescu@cea.fr> , >>> Jerome Haerri >>> , Thierry Ernst >>> , >>> ipwave-chairs@ietf.org >>> >>> A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>> >>> has been successfully submitted by Alexandre Petrescu and posted to >>> the >>> >>> IETF repository. >>> >>> Name: draft-ietf-ipwave-ipv6-over-80211ocb >>> >>> Revision: 05 >>> >>> Title: Transmission of IPv6 Packets over IEEE 802.11 Networks >>> operating in mode Outside the Context of a Basic Service Set >>> (IPv6-over-80211-OCB) >>> >>> Document date: 2017-09-10 >>> >>> Group: ipwave >>> >>> Pages: 37 >>> >>> URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave- >>> ipv6-over-80211ocb-05.txt >>> >>> >>> Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave- >>> ipv6-over-80211ocb/ >>> >>> >>> Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6- >>> over-80211ocb-05 >>> >>> >>> Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ip >>> wave-ipv6-over-80211ocb-05 >>> >>> >>> Diff:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave- >>> ipv6-over-80211ocb-05 >>> >>> Abstract: >>> >>> In order to transmit IPv6 packets on IEEE 802.11 networks run >>> outside >>> >>> the context of a basic service set (OCB, earlier "802.11p") there is >>> >>> a need to define a few parameters such as the supported Maximum >>> >>> Transmission Unit size on the 802.11-OCB link, the header format >>> >>> preceding the IPv6 header, the Type value within it, and others. >>> >>> This document describes these parameters for IPv6 and IEEE >>> 802.11-OCB >>> >>> networks; it portrays the layering of IPv6 on 802.11-OCB similarly >>> to >>> >>> other known 802.11 and Ethernet layers - by using an Ethernet >>> >>> Adaptation Layer. >>> >>> In addition, the document lists what is different in 802.11-OCB >>> >>> (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, >>> >>> where IPv6 protocols operate without issues. Most notably, the >>> >>> operation outside the context of a BSS (OCB) has impact on IPv6 >>> >>> handover behaviour and on IPv6 security. >>> >>> >>> >>> 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 >>> >>> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --001a114b879acde1210559746432 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,

>=C2=A0Do you know whether there is an EtherType allocated by IEEE fo= r WAVE=C2=A0messages? =C2=A0=

The IANA listing isn't the definitive listing= of ethertype values. The definitive listing is at=C2=A0http://standards-oui.ieee.org/ethe= rtype/eth.txt, which assigns 88dc to "Wireless Access in a Vehicle= Environment (WAVE) Short Message Protocol (WSM) as defined in IEEE P1609.3= ."

BTW, note that "WAVE messages" i= sn't the best terminology to use -- this is an identifier for WAVE *Sho= rt* Messages, or WSMs. "WAVE messages" is a term with no defined = meaning.

Cheers,

Will= iam

On= Sun, Sep 17, 2017 at 3:33 PM, Alexandre Petrescu <alexandre.pe= trescu@gmail.com> wrote:

Le 17/09/2017 =C3=A0 20:29, Alexandre Petrescu a =C3=A9crit=C2=A0:
[...]
Finally, in your review, when you read the -06 text saying "Some
channels are reserved for safety communications; the IPv6 packets should not be sent on these channels." you are commenting in your review that=
"This assumes that Safety applications would not use IPv6; erroneous assumption."=C2=A0 My question is the following: do you want text dele= ted?
Which one?=C2=A0 Or is it just a comment?=C2=A0 Know that some WG members a= lready
suggested that "IPv6 packets should be sent on the channels reserved f= or
safety".

 I meant "_not_ be sent on the channels reserved for safety", obvi= ously.

Alex



Alex




Le 14/09/2017 =C3=A0 11:44, Fran=C3=A7ois Simon a =C3=A9crit :
Mr. Petrescu,

Find attached comments on version 06 of the document.

Let me know if you have any questions.

Francois Yves Simon

Lojik Technologies

*From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre
Petrescu *Sent:* Sunday, September 10, 2017 9:58 AM *To:*
its@ietf.org *Subject= :* [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-8= 0211ocb-05.txt

Dear participants to IPWAVE WG,

This is the new IPv6-over-802.11-OCB addressing all the Reviewers
comments.

This is the ChangeLog:

o Lengthened the title and cleanded the abstract. o Added text
suggesting LLs may be easy to use on OCB, rather than GUAs based on
received prefix. o Added the risks of spoofing and hijacking. o
Removed the text speculation on adoption of the TSA message. o
Clarified that the ND protocol is used. o Clarified what it means "No<= br> association needed". o Added some text about how two STAs discover
each other. o Added mention of external (OCB) and internal network
(stable), in the subnet structure section. o Added phrase explaining
that both .11 Data and .11 QoS Data headers are currently being used,
and may be used in the future. o Moved the packet capture example
into an Appendix Implementation Status. o Suggested moving the
reliability requirements appendix out into another document. o Added
a IANA Consiserations section, with content, requesting for a new
multicast group "all OCB interfaces". o Added new OBU term, impro= ved
the RSU term definition, removed the ETTC term, replaced more
occurences of 802.11p, 802.11 OCB with 802.11-OCB. o References: *
Added an informational reference to ETSI=E2=80=99s IPv6-over- GeoNetworking= . * Added more references to IETF and ETSI security protocols. *
Updated some references from I-D to RFC, and from old RFC to new RFC
numbers. * Added reference to multicast extensions to IPsec
architecture RFC. * Added a reference to 2464-bis. * Removed FCC
informative references, because not used. o Updated the affiliation
of one author. o Reformulation of some phrases for better
readability, and correction of typographical errors.

Alex

-------- Message transf=C3=A9r=C3=A9 --------

*Sujet : *



New Version Notification for
draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

*Date : *



Sun, 10 Sep 2017 06:55:20 -0700

*De : *



internet-draf= ts@ietf.org <mailto:internet-drafts@ietf.org>

*Pour : *



Nabil Benamar <= benamar73@gmail.com> <mailto:benamar73@gmail.com>, Christian Huitema <huitema@huitema.net> <mailto:= huitema@huitema.net>,
=C2=A0Jong-Hyouk Lee <jonghyouk@smu.ac.kr> <mailto:jonghyouk@smu.ac.kr>, J=C3=A9r=C3=B4me H= =C3=A4rri <Jerome.Haerri@eurecom.fr> <mailto:Jerome.Haerri@eurecom.fr>, Alex= andre Petrescu <Alexandre.Petrescu@cea.fr> <mailto:Alexandre.Petrescu@cea.fr&= gt;, Tony
Li <tony.li@tony.li= > <mailto:to= ny.li@tony.li>, Alexandre Petrescu <alexandre.petrescu@cea.fr> <mai= lto:alexandr= e.petrescu@cea.fr>,
Jerome Haerri <jerome.haerri@eurecom.fr>
<mailto:je= rome.haerri@eurecom.fr>, Thierry Ernst
<thierry.er= nst@yogoko.fr> <mailto:thierry.ernst@yogoko.fr>,
ipwave-chairs@i= etf.org <mailto:ipwave-chairs@ietf.org>

A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

has been successfully submitted by Alexandre Petrescu and posted to
the

IETF repository.

Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-ietf-ipwa= ve-ipv6-over-80211ocb

Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 05

Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Transmission of IPv6= Packets over IEEE 802.11 Networks
operating in mode Outside the Context of a Basic Service Set
(IPv6-over-80211-OCB)

Document date: 2017-09-10

Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ipwave

Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 37

URL:https://www.ietf= .org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-05.txt<= /a>


Status:https://datatracker.iet= f.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/


Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05


Htmlized:https://datatr= acker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-05


Diff:https://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80211ocb-05

=C2=A0Abstract:

In order to transmit IPv6 packets on IEEE 802.11 networks run
outside

the context of a basic service set (OCB, earlier "802.11p") there= is

a need to define a few parameters such as the supported Maximum

Transmission Unit size on the 802.11-OCB link, the header format

preceding the IPv6 header, the Type value within it, and others.

This document describes these parameters for IPv6 and IEEE
802.11-OCB

networks; it portrays the layering of IPv6 on 802.11-OCB similarly
to

other known 802.11 and Ethernet layers - by using an Ethernet

Adaptation Layer.

In addition, the document lists what is different in 802.11-OCB

(802.11p) links compared to more 'traditional' 802.11a/b/g/n links,=

where IPv6 protocols operate without issues.=C2=A0 Most notably, the

operation outside the context of a BSS (OCB) has impact on IPv6

handover behaviour and on IPv6 security.



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


_______________________________________________
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



--
=


PLEASE UPDATE YOUR ADDRESS BOOKS WIT= H MY NEW ADDRESS: wwhyte@onboardsecurity.com
--001a114b879acde1210559746432-- From nobody Mon Sep 18 03:50:35 2017 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 A9918132031 for ; Mon, 18 Sep 2017 03:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 TPjB-_dHiovF for ; Mon, 18 Sep 2017 03:50:31 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 B50CA13305E for ; Mon, 18 Sep 2017 03:50:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8IAoTBo043781; Mon, 18 Sep 2017 12:50:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EDCF820D7AE; Mon, 18 Sep 2017 12:50:28 +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 E017C20D7BC; Mon, 18 Sep 2017 12:50:28 +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 v8IAoSSh024579; Mon, 18 Sep 2017 12:50:28 +0200 To: William Whyte Cc: "its@ietf.org" References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> <011101d32d3e$00cc7d20$02657760$@gmail.com> <75e59482-38b7-c1c7-a09d-67de78588ad4@gmail.com> <541905b5-3c4b-337b-21a2-d421d9cd28bc@gmail.com> From: Alexandre Petrescu Message-ID: <20e2b3e5-70e3-36ac-dec1-6bbefcb4c453@gmail.com> Date: Mon, 18 Sep 2017 12:50:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] -06 comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 10:50:33 -0000 Hi William, Le 18/09/2017 à 12:41, William Whyte a écrit : > Hi Alex, > >> Do you know whether there is an EtherType allocated by IEEE for >> WAVE > messages? > > The IANA listing isn't the definitive listing of ethertype values. I agree, the IANA listing is just echoing the IEEE listing with respect to EtherTypes. But it is very useful. > The definitive listing is at > http://standards-oui.ieee.org/ethertype/eth.txt, which assigns 88dc > to "Wireless Access in a Vehicle Environment (WAVE) Short Message > Protocol (WSM) as defined in IEEE P1609.3." > > BTW, note that "WAVE messages" isn't the best terminology to use -- > this is an identifier for WAVE *Short* Messages, or WSMs. "WAVE > messages" is a term with no defined meaning. I agree. To clarify myself, Wireshark calls 0x88DC "(WAVE) Short Message Protocol (WSM)". Maybe this is more in-line with what is expected. Alex > > Cheers, > > William > > On Sun, Sep 17, 2017 at 3:33 PM, Alexandre Petrescu > > > wrote: > > > > Le 17/09/2017 à 20:29, Alexandre Petrescu a écrit : [...] > > Finally, in your review, when you read the -06 text saying "Some > channels are reserved for safety communications; the IPv6 packets > should not be sent on these channels." you are commenting in your > review that "This assumes that Safety applications would not use > IPv6; erroneous assumption." My question is the following: do you > want text deleted? Which one? Or is it just a comment? Know that > some WG members already suggested that "IPv6 packets should be sent > on the channels reserved for safety". > > > I meant "_not_ be sent on the channels reserved for safety", > obviously. > > Alex > > > > Alex > > > > > Le 14/09/2017 à 11:44, François Simon a écrit : > > Mr. Petrescu, > > Find attached comments on version 06 of the document. > > Let me know if you have any questions. > > Francois Yves Simon > > Lojik Technologies > > *From:*its [mailto:its-bounces@ietf.org > ] *On Behalf Of *Alexandre Petrescu > *Sent:* Sunday, September 10, 2017 9:58 AM *To:* its@ietf.org > *Subject:* [ipwave] Fwd: New Version > Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt > > Dear participants to IPWAVE WG, > > This is the new IPv6-over-802.11-OCB addressing all the Reviewers > comments. > > This is the ChangeLog: > > o Lengthened the title and cleanded the abstract. o Added text > suggesting LLs may be easy to use on OCB, rather than GUAs based on > received prefix. o Added the risks of spoofing and hijacking. o > Removed the text speculation on adoption of the TSA message. o > Clarified that the ND protocol is used. o Clarified what it means > "No association needed". o Added some text about how two STAs > discover each other. o Added mention of external (OCB) and internal > network (stable), in the subnet structure section. o Added phrase > explaining that both .11 Data and .11 QoS Data headers are currently > being used, and may be used in the future. o Moved the packet > capture example into an Appendix Implementation Status. o Suggested > moving the reliability requirements appendix out into another > document. o Added a IANA Consiserations section, with content, > requesting for a new multicast group "all OCB interfaces". o Added > new OBU term, improved the RSU term definition, removed the ETTC > term, replaced more occurences of 802.11p, 802.11 OCB with > 802.11-OCB. o References: * Added an informational reference to > ETSI’s IPv6-over- GeoNetworking. * Added more references to IETF and > ETSI security protocols. * Updated some references from I-D to RFC, > and from old RFC to new RFC numbers. * Added reference to multicast > extensions to IPsec architecture RFC. * Added a reference to > 2464-bis. * Removed FCC informative references, because not used. o > Updated the affiliation of one author. o Reformulation of some > phrases for better readability, and correction of typographical > errors. > > Alex > > -------- Message transféré -------- > > *Sujet : * > > > > New Version Notification for > draft-ietf-ipwave-ipv6-over-80211ocb-05.txt > > *Date : * > > > > Sun, 10 Sep 2017 06:55:20 -0700 > > *De : * > > > > internet-drafts@ietf.org > > > > *Pour : * > > > > Nabil Benamar > > >, Christian > Huitema > > >, Jong-Hyouk > Lee > > >, Jérôme > Härri > > >, > Alexandre Petrescu > > >, Tony Li > >, Alexandre Petrescu > > > >, Jerome Haerri > > > >, > Thierry Ernst > >, ipwave-chairs@ietf.org > > > > A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt > > has been successfully submitted by Alexandre Petrescu and posted to > the > > IETF repository. > > Name: draft-ietf-ipwave-ipv6-over-80211ocb > > Revision: 05 > > Title: Transmission of IPv6 Packets over IEEE 802.11 > Networks operating in mode Outside the Context of a Basic Service > Set (IPv6-over-80211-OCB) > > Document date: 2017-09-10 > > Group: ipwave > > Pages: 37 > > URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-05.txt > > > > > > Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ > > > > > > Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05 > > > > > > Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-05 > > > > > > Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-05 > > > > > Abstract: > > In order to transmit IPv6 packets on IEEE 802.11 networks run > outside > > the context of a basic service set (OCB, earlier "802.11p") there is > > a need to define a few parameters such as the supported Maximum > > Transmission Unit size on the 802.11-OCB link, the header format > > preceding the IPv6 header, the Type value within it, and others. > > This document describes these parameters for IPv6 and IEEE > 802.11-OCB > > networks; it portrays the layering of IPv6 on 802.11-OCB similarly > to > > other known 802.11 and Ethernet layers - by using an Ethernet > > Adaptation Layer. > > In addition, the document lists what is different in 802.11-OCB > > (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, > > where IPv6 protocols operate without issues. Most notably, the > > operation outside the context of a BSS (OCB) has impact on IPv6 > > handover behaviour and on IPv6 security. > > > > 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 > > > _______________________________________________ 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 > > > > > > -- > > > PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: > wwhyte@onboardsecurity.com From nobody Mon Sep 18 05:00:34 2017 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 8F2DE1321C9 for ; Mon, 18 Sep 2017 05:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.067 X-Spam-Level: X-Spam-Status: No, score=0.067 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, 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 AjKMJDuO_qMh for ; Mon, 18 Sep 2017 05:00:31 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 3E328132193 for ; Mon, 18 Sep 2017 05:00:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8IC0Tt1019023 for ; Mon, 18 Sep 2017 14:00:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 411B32019E5 for ; Mon, 18 Sep 2017 14:00:29 +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 2E76020198B for ; Mon, 18 Sep 2017 14:00:29 +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 v8IC0TKk003267 for ; Mon, 18 Sep 2017 14:00:29 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: Date: Mon, 18 Sep 2017 14:00:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: fr Archived-At: Subject: [ipwave] correction X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 12:00:32 -0000 I know that some WG members already suggested that "IPv6 packets should not be sent on the channels reserved for safety". Alex From nobody Tue Sep 19 04:42:45 2017 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 6A13E134217 for ; Tue, 19 Sep 2017 04:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 zGZVmiIua_Lt for ; Tue, 19 Sep 2017 04:42:40 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 25053134211 for ; Tue, 19 Sep 2017 04:42:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8JBgZ52017416; Tue, 19 Sep 2017 13:42:35 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B9C17207709; Tue, 19 Sep 2017 13:42:35 +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 A9863207140; Tue, 19 Sep 2017 13:42:35 +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 v8JBgZrs021249; Tue, 19 Sep 2017 13:42:35 +0200 To: dickroy@alum.mit.edu, "'William Whyte'" Cc: its@ietf.org References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> <011101d32d3e$00cc7d20$02657760$@gmail.com> <75e59482-38b7-c1c7-a09d-67de78588ad4@gmail.com> <541905b5-3c4b-337b-21a2-d421d9cd28bc@gmail.com> <20e2b3e5-70e3-36ac-dec1-6bbefcb4c453@gmail.com> <7C012720BADE47279874D36436256947@SRA6> From: Alexandre Petrescu Message-ID: <23930411-16f8-a80e-64d6-d029b4f6f55f@gmail.com> Date: Tue, 19 Sep 2017 13:42:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <7C012720BADE47279874D36436256947@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] -06 comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 11:42:43 -0000 Le 19/09/2017 à 00:19, Dick Roy a écrit : > Alex et.al., > > To clarify, there is NO IANA listing for messages of any kind But there is this listing there: https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml It does say 0x86DD for IPv6 and 0x8947 for GeoNetworking. Do you think 0x88DC does not fit there too? ("(WAVE) Short Message Protocol (WSM)") If I want to build a unique box (not multiple boxes one per Region) I'd have to write the code such that it multiplexes based on that EtherType. It might be that code is an IP code. As such I'd look at IANA to see the EtherTypes. Alex , WSMs > included. The IANA listings to which you refer below are the ethertype > listings. Ethertypes identify protocols, not messages. 0x88DC is assigned > to the WAVE Short Message Protocol which specifies how to construct a > transport layer header and a network layer header for exchanging TSDUs > between peer entities where there is NO network layer addressing at all! > Note that in ISO, the equivalent protocol used to be called NNTP > (Null-Network & Transport layer Protocol) for just that reason! > > Cheers, > > RR > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Monday, September 18, 2017 3:50 AM > To: William Whyte > Cc: its@ietf.org > Subject: Re: [ipwave] -06 comments > > Hi William, > > Le 18/09/2017 à 12:41, William Whyte a écrit : >> Hi Alex, >> >>> Do you know whether there is an EtherType allocated by IEEE for >>> WAVE >> messages? >> >> The IANA listing isn't the definitive listing of ethertype values. > > I agree, the IANA listing is just echoing the IEEE listing with respect > to EtherTypes. But it is very useful. > >> The definitive listing is at >> http://standards-oui.ieee.org/ethertype/eth.txt, which assigns 88dc >> to "Wireless Access in a Vehicle Environment (WAVE) Short Message >> Protocol (WSM) as defined in IEEE P1609.3." >> >> BTW, note that "WAVE messages" isn't the best terminology to use -- >> this is an identifier for WAVE *Short* Messages, or WSMs. "WAVE >> messages" is a term with no defined meaning. > > I agree. To clarify myself, Wireshark calls 0x88DC "(WAVE) Short > Message Protocol (WSM)". Maybe this is more in-line with what is expected. > > Alex > >> >> Cheers, >> >> William >> >> On Sun, Sep 17, 2017 at 3:33 PM, Alexandre Petrescu >> > >> wrote: >> >> >> >> Le 17/09/2017 à 20:29, Alexandre Petrescu a écrit : [...] >> >> Finally, in your review, when you read the -06 text saying "Some >> channels are reserved for safety communications; the IPv6 packets >> should not be sent on these channels." you are commenting in your >> review that "This assumes that Safety applications would not use >> IPv6; erroneous assumption." My question is the following: do you >> want text deleted? Which one? Or is it just a comment? Know that >> some WG members already suggested that "IPv6 packets should be sent >> on the channels reserved for safety". >> >> >> I meant "_not_ be sent on the channels reserved for safety", >> obviously. >> >> Alex >> >> >> >> Alex >> >> >> >> >> Le 14/09/2017 à 11:44, François Simon a écrit : >> >> Mr. Petrescu, >> >> Find attached comments on version 06 of the document. >> >> Let me know if you have any questions. >> >> Francois Yves Simon >> >> Lojik Technologies >> >> *From:*its [mailto:its-bounces@ietf.org >> ] *On Behalf Of *Alexandre Petrescu >> *Sent:* Sunday, September 10, 2017 9:58 AM *To:* its@ietf.org >> *Subject:* [ipwave] Fwd: New Version >> Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >> >> Dear participants to IPWAVE WG, >> >> This is the new IPv6-over-802.11-OCB addressing all the Reviewers >> comments. >> >> This is the ChangeLog: >> >> o Lengthened the title and cleanded the abstract. o Added text >> suggesting LLs may be easy to use on OCB, rather than GUAs based on >> received prefix. o Added the risks of spoofing and hijacking. o >> Removed the text speculation on adoption of the TSA message. o >> Clarified that the ND protocol is used. o Clarified what it means >> "No association needed". o Added some text about how two STAs >> discover each other. o Added mention of external (OCB) and internal >> network (stable), in the subnet structure section. o Added phrase >> explaining that both .11 Data and .11 QoS Data headers are currently >> being used, and may be used in the future. o Moved the packet >> capture example into an Appendix Implementation Status. o Suggested >> moving the reliability requirements appendix out into another >> document. o Added a IANA Consiserations section, with content, >> requesting for a new multicast group "all OCB interfaces". o Added >> new OBU term, improved the RSU term definition, removed the ETTC >> term, replaced more occurences of 802.11p, 802.11 OCB with >> 802.11-OCB. o References: * Added an informational reference to >> ETSI's IPv6-over- GeoNetworking. * Added more references to IETF and >> ETSI security protocols. * Updated some references from I-D to RFC, >> and from old RFC to new RFC numbers. * Added reference to multicast >> extensions to IPsec architecture RFC. * Added a reference to >> 2464-bis. * Removed FCC informative references, because not used. o >> Updated the affiliation of one author. o Reformulation of some >> phrases for better readability, and correction of typographical >> errors. >> >> Alex >> >> -------- Message transféré -------- >> >> *Sujet : * >> >> >> >> New Version Notification for >> draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >> >> *Date : * >> >> >> >> Sun, 10 Sep 2017 06:55:20 -0700 >> >> *De : * >> >> >> >> internet-drafts@ietf.org >> > >> >> *Pour : * >> >> >> >> Nabil Benamar > >> >, Christian >> Huitema > >> >, Jong-Hyouk >> Lee > >> >, Jérôme >> Härri > >> >, >> Alexandre Petrescu > > >> > >, Tony Li > > > >, Alexandre Petrescu >> > >> > >, Jerome Haerri >> > >> >, >> Thierry Ernst > > > >, ipwave-chairs@ietf.org >> > > >> >> A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >> >> has been successfully submitted by Alexandre Petrescu and posted to >> the >> >> IETF repository. >> >> Name: draft-ietf-ipwave-ipv6-over-80211ocb >> >> Revision: 05 >> >> Title: Transmission of IPv6 Packets over IEEE 802.11 >> Networks operating in mode Outside the Context of a Basic Service >> Set (IPv6-over-80211-OCB) >> >> Document date: 2017-09-10 >> >> Group: ipwave >> >> Pages: 37 >> >> > URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211oc > b-05.txt >> >> > 5.txt> >> >> >> >> > Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb > / >> >> > >> >> >> >> > Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05 >> >> > >> >> >> >> > Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-8 > 0211ocb-05 >> >> > 05> >> >> >> >> > Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb- > 05 >> >> > >> >> >> Abstract: >> >> In order to transmit IPv6 packets on IEEE 802.11 networks run >> outside >> >> the context of a basic service set (OCB, earlier "802.11p") there is >> >> a need to define a few parameters such as the supported Maximum >> >> Transmission Unit size on the 802.11-OCB link, the header format >> >> preceding the IPv6 header, the Type value within it, and others. >> >> This document describes these parameters for IPv6 and IEEE >> 802.11-OCB >> >> networks; it portrays the layering of IPv6 on 802.11-OCB similarly >> to >> >> other known 802.11 and Ethernet layers - by using an Ethernet >> >> Adaptation Layer. >> >> In addition, the document lists what is different in 802.11-OCB >> >> (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, >> >> where IPv6 protocols operate without issues. Most notably, the >> >> operation outside the context of a BSS (OCB) has impact on IPv6 >> >> handover behaviour and on IPv6 security. >> >> >> >> 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 >> >> >> _______________________________________________ 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 >> >> >> >> >> >> -- >> >> >> PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: >> wwhyte@onboardsecurity.com > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Tue Sep 19 04:44:51 2017 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 94B261342ED for ; Tue, 19 Sep 2017 04:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 P8MxKQAmuQbl for ; Tue, 19 Sep 2017 04:44:39 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 B9751134235 for ; Tue, 19 Sep 2017 04:44:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8JBiYO2093960; Tue, 19 Sep 2017 13:44:34 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6372720764C; Tue, 19 Sep 2017 13:44:34 +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 55C99207200; Tue, 19 Sep 2017 13:44:34 +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 v8JBiXtd022467; Tue, 19 Sep 2017 13:44:34 +0200 To: dickroy@alum.mit.edu, its@ietf.org References: <2E8AAA2242ED4122B30FFE4C49BFF5E8@SRA6> From: Alexandre Petrescu Message-ID: <64f88cf4-685a-9dff-4a3a-a7a8cf771781@gmail.com> Date: Tue, 19 Sep 2017 13:44:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2E8AAA2242ED4122B30FFE4C49BFF5E8@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] correction X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 11:44:42 -0000 So, should I remove this paragraph: > o Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB, > as opposed to IPv6 not being prohibited on any channel on which > 802.11a/b/g/n runs: > > * Some channels are reserved for safety communications; the IPv6 > packets should not be sent on these channels. > > * At the time of writing, the prohibition is explicit at higher > layer protocols providing services to the application; these > higher layer protocols are specified in IEEE 1609 documents, > i.e. the "WAVE" stack. > > * National or regional specifications and regulations specify the > use of different channels; these regulations must be followed. Alex Le 19/09/2017 à 00:06, Dick Roy a écrit : > Alex et.al., > > The simple fact is that how physical resources are to be used (aka "what > apps are allowed on which channels") is a topic/issue way outside the scope > of the IETF's work. I highly recommend you make no statements on such > issues nor make any recommendations along those lines. Stick to IPv6 > networking and the network (and transport) layer functions required to > implement it. Leave channel allocation issues to the appropriate entities > ... the regulators and system integrators. > > MTC ... > > RR > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Monday, September 18, 2017 5:00 AM > To: its@ietf.org > Subject: [ipwave] correction > > I know that some WG members already suggested that "IPv6 packets should not > be sent on the channels reserved for safety". > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Tue Sep 19 05:47:21 2017 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 F38AE134355 for ; Tue, 19 Sep 2017 05:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.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 y3G6y79JXVDX for ; Tue, 19 Sep 2017 05:47:15 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 E2D62134358 for ; Tue, 19 Sep 2017 05:45:42 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id 13so4904407wmq.2 for ; Tue, 19 Sep 2017 05:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BXwMbDIpDt7TM31Jbs+NJcU4IFt923+/u9tPtG2BAmo=; b=I1Qo8NcIozv2+TBCTHXBoiENcUMDDFRKx066xcIPQaydqFk9/ZJjGyMrgI1J0+EQvi hDbwwnivS0p1ysP7Ky25g2jei6LyLhRLBkAiOzQL3wcEgIEig0Glkv1vFTMn9hwq3stV gQa41PvGcK5VQM1hhpDu5CbXgvgNg/GteW2os= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BXwMbDIpDt7TM31Jbs+NJcU4IFt923+/u9tPtG2BAmo=; b=cGohL5InCUsmzAu5VS5TnZ+KilYdnk2jpuF86EDvXWYxH6r+rL5PE2KYZBtDGEMREs AzE5l55I8VHzlbROwnYKtah5gLkL1jKbFJBrX+2fsNHcSx8w0ICTKpHbSE0tBZYibViP Rnrj1woTWy/I6GMFGDGunJ4LJxSBr18eC2i9G1RkvAePx7zZlIW7/Zl5UdoNHrDnS3d/ Ei5mMsNTuEklhRBzag9xXatkHGnL/E2kSf7pjMe/7Og7oNmEnScBFoXzYiOL5TBBGale j3f53btSqgdaHaQ13coYBGtuVUVq/KT8Ft+kwsz/9NFpmyRFuQfCE6KvqGpmRta0L1hA dR6Q== X-Gm-Message-State: AHPjjUh+8qrvkxBQtKj71Y8YetiFo8gTZAFkT8Nji2G3e8G2Y+esmTi/ JjOGaLC8rH55M4B3shs128RDStjrZhzpEaPk4zhkIA== X-Google-Smtp-Source: AOwi7QBHB76xW3HDhCDZzLkBuGArPl8aygV1VnY4RkFg7ogJKO6LkcExJ42371PE5hg/WyS6kV0GvEGIHE1JcDTGLMw= X-Received: by 10.28.214.212 with SMTP id n203mr906183wmg.10.1505825141201; Tue, 19 Sep 2017 05:45:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.150.83 with HTTP; Tue, 19 Sep 2017 05:45:19 -0700 (PDT) In-Reply-To: <23930411-16f8-a80e-64d6-d029b4f6f55f@gmail.com> References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> <011101d32d3e$00cc7d20$02657760$@gmail.com> <75e59482-38b7-c1c7-a09d-67de78588ad4@gmail.com> <541905b5-3c4b-337b-21a2-d421d9cd28bc@gmail.com> <20e2b3e5-70e3-36ac-dec1-6bbefcb4c453@gmail.com> <7C012720BADE47279874D36436256947@SRA6> <23930411-16f8-a80e-64d6-d029b4f6f55f@gmail.com> From: William Whyte Date: Tue, 19 Sep 2017 08:45:19 -0400 Message-ID: To: Alexandre Petrescu Cc: Dick Roy , "its@ietf.org" Content-Type: multipart/alternative; boundary="001a11468c92a2bb7705598a3c4c" Archived-At: Subject: Re: [ipwave] -06 comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 12:47:19 -0000 --001a11468c92a2bb7705598a3c4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dick's point is that messages are application-layer data objects; what an ethertype identifies is a protocol. Cheers, William On Tue, Sep 19, 2017 at 7:42 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 19/09/2017 =C3=A0 00:19, Dick Roy a =C3=A9crit : > >> Alex et.al., >> >> To clarify, there is NO IANA listing for messages of any kind >> > > But there is this listing there: > https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml > > It does say 0x86DD for IPv6 and 0x8947 for GeoNetworking. Do you think > 0x88DC does not fit there too? ("(WAVE) Short Message Protocol (WSM)") > > If I want to build a unique box (not multiple boxes one per Region) I'd > have to write the code such that it multiplexes based on that EtherType. > It might be that code is an IP code. As such I'd look at IANA to see the > EtherTypes. > > Alex > > > , WSMs > >> included. The IANA listings to which you refer below are the ethertype >> listings. Ethertypes identify protocols, not messages. 0x88DC is >> assigned >> to the WAVE Short Message Protocol which specifies how to construct a >> transport layer header and a network layer header for exchanging TSDUs >> between peer entities where there is NO network layer addressing at all! >> Note that in ISO, the equivalent protocol used to be called NNTP >> (Null-Network & Transport layer Protocol) for just that reason! >> >> Cheers, >> >> RR >> >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu >> Sent: Monday, September 18, 2017 3:50 AM >> To: William Whyte >> Cc: its@ietf.org >> Subject: Re: [ipwave] -06 comments >> >> Hi William, >> >> Le 18/09/2017 =C3=A0 12:41, William Whyte a =C3=A9crit : >> >>> Hi Alex, >>> >>> Do you know whether there is an EtherType allocated by IEEE for >>>> WAVE >>>> >>> messages? >>> >>> The IANA listing isn't the definitive listing of ethertype values. >>> >> >> I agree, the IANA listing is just echoing the IEEE listing with respect >> to EtherTypes. But it is very useful. >> >> The definitive listing is at >>> http://standards-oui.ieee.org/ethertype/eth.txt, which assigns 88dc >>> to "Wireless Access in a Vehicle Environment (WAVE) Short Message >>> Protocol (WSM) as defined in IEEE P1609.3." >>> >>> BTW, note that "WAVE messages" isn't the best terminology to use -- >>> this is an identifier for WAVE *Short* Messages, or WSMs. "WAVE >>> messages" is a term with no defined meaning. >>> >> >> I agree. To clarify myself, Wireshark calls 0x88DC "(WAVE) Short >> Message Protocol (WSM)". Maybe this is more in-line with what is >> expected. >> >> Alex >> >> >>> Cheers, >>> >>> William >>> >>> On Sun, Sep 17, 2017 at 3:33 PM, Alexandre Petrescu >>> > >>> wrote: >>> >>> >>> >>> Le 17/09/2017 =C3=A0 20:29, Alexandre Petrescu a =C3=A9crit : [...] >>> >>> Finally, in your review, when you read the -06 text saying "Some >>> channels are reserved for safety communications; the IPv6 packets >>> should not be sent on these channels." you are commenting in your >>> review that "This assumes that Safety applications would not use >>> IPv6; erroneous assumption." My question is the following: do you >>> want text deleted? Which one? Or is it just a comment? Know that >>> some WG members already suggested that "IPv6 packets should be sent >>> on the channels reserved for safety". >>> >>> >>> I meant "_not_ be sent on the channels reserved for safety", >>> obviously. >>> >>> Alex >>> >>> >>> >>> Alex >>> >>> >>> >>> >>> Le 14/09/2017 =C3=A0 11:44, Fran=C3=A7ois Simon a =C3=A9crit : >>> >>> Mr. Petrescu, >>> >>> Find attached comments on version 06 of the document. >>> >>> Let me know if you have any questions. >>> >>> Francois Yves Simon >>> >>> Lojik Technologies >>> >>> *From:*its [mailto:its-bounces@ietf.org >>> ] *On Behalf Of *Alexandre Petrescu >>> *Sent:* Sunday, September 10, 2017 9:58 AM *To:* its@ietf.org >>> *Subject:* [ipwave] Fwd: New Version >>> Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>> >>> Dear participants to IPWAVE WG, >>> >>> This is the new IPv6-over-802.11-OCB addressing all the Reviewers >>> comments. >>> >>> This is the ChangeLog: >>> >>> o Lengthened the title and cleanded the abstract. o Added text >>> suggesting LLs may be easy to use on OCB, rather than GUAs based on >>> received prefix. o Added the risks of spoofing and hijacking. o >>> Removed the text speculation on adoption of the TSA message. o >>> Clarified that the ND protocol is used. o Clarified what it means >>> "No association needed". o Added some text about how two STAs >>> discover each other. o Added mention of external (OCB) and internal >>> network (stable), in the subnet structure section. o Added phrase >>> explaining that both .11 Data and .11 QoS Data headers are currently >>> being used, and may be used in the future. o Moved the packet >>> capture example into an Appendix Implementation Status. o Suggested >>> moving the reliability requirements appendix out into another >>> document. o Added a IANA Consiserations section, with content, >>> requesting for a new multicast group "all OCB interfaces". o Added >>> new OBU term, improved the RSU term definition, removed the ETTC >>> term, replaced more occurences of 802.11p, 802.11 OCB with >>> 802.11-OCB. o References: * Added an informational reference to >>> ETSI's IPv6-over- GeoNetworking. * Added more references to IETF and >>> ETSI security protocols. * Updated some references from I-D to RFC, >>> and from old RFC to new RFC numbers. * Added reference to multicast >>> extensions to IPsec architecture RFC. * Added a reference to >>> 2464-bis. * Removed FCC informative references, because not used. o >>> Updated the affiliation of one author. o Reformulation of some >>> phrases for better readability, and correction of typographical >>> errors. >>> >>> Alex >>> >>> -------- Message transf=C3=A9r=C3=A9 -------- >>> >>> *Sujet : * >>> >>> >>> >>> New Version Notification for >>> draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>> >>> *Date : * >>> >>> >>> >>> Sun, 10 Sep 2017 06:55:20 -0700 >>> >>> *De : * >>> >>> >>> >>> internet-drafts@ietf.org >>> > >>> >>> *Pour : * >>> >>> >>> >>> Nabil Benamar > >>> >, Christian >>> Huitema > >>> >, Jong-Hyouk >>> Lee > >>> >, J=C3=A9r=C3= =B4me >>> H=C3=A4rri > >>> >, >>> Alexandre Petrescu >> > >>> >> >, Tony Li >> > >> >, Alexandre Petrescu >>> > >>> >> >, Jerome Haerri >>> > >>> >, >>> Thierry Ernst >> > >> >, ipwave-chairs@ietf.org >>> >> > >>> >>> A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>> >>> has been successfully submitted by Alexandre Petrescu and posted to >>> the >>> >>> IETF repository. >>> >>> Name: draft-ietf-ipwave-ipv6-over-80211ocb >>> >>> Revision: 05 >>> >>> Title: Transmission of IPv6 Packets over IEEE 802.11 >>> Networks operating in mode Outside the Context of a Basic Service >>> Set (IPv6-over-80211-OCB) >>> >>> Document date: 2017-09-10 >>> >>> Group: ipwave >>> >>> Pages: 37 >>> >>> >>> URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave- >> ipv6-over-80211oc >> b-05.txt >> >>> >>> >>> > ipv6-over-80211ocb-0 >> 5.txt> >> >>> >>> >>> >>> >>> Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave- >> ipv6-over-80211ocb >> / >> >>> >>> >>> >> >>> >>> >>> >>> >>> Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6- >> over-80211ocb-05 >> >>> >>> >>> >> >>> >>> >>> >>> >>> Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ip >> wave-ipv6-over-8 >> 0211ocb-05 >> >>> >>> >>> > 6-over-80211ocb- >> 05> >> >>> >>> >>> >>> >>> Diff:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave- >> ipv6-over-80211ocb- >> 05 >> >>> >>> >>> > er-80211ocb-05> >> >>> >>> >>> Abstract: >>> >>> In order to transmit IPv6 packets on IEEE 802.11 networks run >>> outside >>> >>> the context of a basic service set (OCB, earlier "802.11p") there is >>> >>> a need to define a few parameters such as the supported Maximum >>> >>> Transmission Unit size on the 802.11-OCB link, the header format >>> >>> preceding the IPv6 header, the Type value within it, and others. >>> >>> This document describes these parameters for IPv6 and IEEE >>> 802.11-OCB >>> >>> networks; it portrays the layering of IPv6 on 802.11-OCB similarly >>> to >>> >>> other known 802.11 and Ethernet layers - by using an Ethernet >>> >>> Adaptation Layer. >>> >>> In addition, the document lists what is different in 802.11-OCB >>> >>> (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, >>> >>> where IPv6 protocols operate without issues. Most notably, the >>> >>> operation outside the context of a BSS (OCB) has impact on IPv6 >>> >>> handover behaviour and on IPv6 security. >>> >>> >>> >>> 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 >>> >>> >>> _______________________________________________ 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 >>> >>> >>> >>> >>> >>> -- >>> >>> >>> PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: >>> wwhyte@onboardsecurity.com >>> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> >> --=20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --001a11468c92a2bb7705598a3c4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dick's point is that messages are application-layer da= ta objects; what an ethertype identifies is a protocol.

= Cheers,

William

On Tue, Sep 19, 2017 at 7:42 AM, Alexand= re Petrescu <alexandre.petrescu@gmail.com> wrote:=


Le 19/09/2017 =C3=A0 00:19, Dick Roy a =C3=A9crit=C2=A0:
Alex et.al.,

To clarify, there is NO IANA listing for messages of any kind

 But there is this listing there:
https://www.iana.org/assignm= ents/ieee-802-numbers/ieee-802-numbers.xhtml

It does say 0x86DD for IPv6 and 0x8947 for GeoNetworking.=C2=A0 Do you thin= k 0x88DC does not fit there too? ("(WAVE) Short Message Protocol (WSM)= ")

If I want to build a unique box (not multiple boxes one per Region) I'd= have to write the code such that it multiplexes based on that EtherType.= =C2=A0 It might be that code is an IP code.=C2=A0 As such I'd look at I= ANA to see the EtherTypes.

Alex


, WSMs
included.=C2=A0 The IANA listings to which you refer below are the ethertyp= e
listings.=C2=A0 Ethertypes identify protocols, not messages.=C2=A0 0x88DC i= s assigned
to the WAVE Short Message Protocol which specifies how to construct a
transport layer header and a network layer header for exchanging TSDUs
between peer entities where there is NO network layer addressing at all! Note that in ISO, the equivalent protocol used to be called NNTP
(Null-Network & Transport layer Protocol) for just that reason!

Cheers,

RR

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Monday, September 18, 2017 3:50 AM
To: William Whyte
Cc: its@ietf.org
Subject: Re: [ipwave] -06 comments

Hi William,

Le 18/09/2017 =C3=A0 12:41, William Whyte a =C3=A9crit :
Hi Alex,

Do you know whether there is an EtherType allocated by IEEE for
WAVE
messages?

The IANA listing isn't the definitive listing of ethertype values.

I agree, the IANA listing is just echoing the IEEE listing with respect
to EtherTypes.=C2=A0 =C2=A0But it is very useful.

The definitive listing is at
http://standards-oui.ieee.org/ethertype/eth.txt<= /a>, which assigns 88dc
to "Wireless Access in a Vehicle Environment (WAVE) Short Message
Protocol (WSM) as defined in IEEE P1609.3."

BTW, note that "WAVE messages" isn't the best terminology to = use --
this is an identifier for WAVE *Short* Messages, or WSMs. "WAVE
messages" is a term with no defined meaning.

I agree.=C2=A0 To clarify myself, Wireshark calls 0x88DC "(WAVE) Short=
Message Protocol (WSM)".=C2=A0 Maybe this is more in-line with what is= expected.

Alex


Cheers,

William

On Sun, Sep 17, 2017 at 3:33 PM, Alexandre Petrescu
<alexa= ndre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>=
wrote:



Le 17/09/2017 =C3=A0 20:29, Alexandre Petrescu a =C3=A9crit : [...]

Finally, in your review, when you read the -06 text saying "Some
channels are reserved for safety communications; the IPv6 packets
should not be sent on these channels." you are commenting in your
review that "This assumes that Safety applications would not use
IPv6; erroneous assumption."=C2=A0 My question is the following: do yo= u
want text deleted? Which one?=C2=A0 Or is it just a comment?=C2=A0 Know tha= t
some WG members already suggested that "IPv6 packets should be sent on the channels reserved for safety".


I meant "_not_ be sent on the channels reserved for safety",
obviously.

Alex



Alex




Le 14/09/2017 =C3=A0 11:44, Fran=C3=A7ois Simon a =C3=A9crit :

Mr. Petrescu,

Find attached comments on version 06 of the document.

Let me know if you have any questions.

Francois Yves Simon

Lojik Technologies

*From:*its [mailto:its-bounces@ietf.org
<mailto:its-bo= unces@ietf.org>] *On Behalf Of *Alexandre Petrescu
*Sent:* Sunday, September 10, 2017 9:58 AM *To:* its@ietf.org
<mailto:its@ietf.org> *Subject:* [ipwave] Fwd: New Version
Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

Dear participants to IPWAVE WG,

This is the new IPv6-over-802.11-OCB addressing all the Reviewers
comments.

This is the ChangeLog:

o Lengthened the title and cleanded the abstract. o Added text
suggesting LLs may be easy to use on OCB, rather than GUAs based on
received prefix. o Added the risks of spoofing and hijacking. o
Removed the text speculation on adoption of the TSA message. o
Clarified that the ND protocol is used. o Clarified what it means
"No association needed". o Added some text about how two STAs
discover each other. o Added mention of external (OCB) and internal
network (stable), in the subnet structure section. o Added phrase
explaining that both .11 Data and .11 QoS Data headers are currently
being used, and may be used in the future. o Moved the packet
capture example into an Appendix Implementation Status. o Suggested
moving the reliability requirements appendix out into another
document. o Added a IANA Consiserations section, with content,
requesting for a new multicast group "all OCB interfaces". o Adde= d
new OBU term, improved the RSU term definition, removed the ETTC
term, replaced more occurences of 802.11p, 802.11 OCB with
802.11-OCB. o References: * Added an informational reference to
ETSI's IPv6-over- GeoNetworking. * Added more references to IETF and ETSI security protocols. * Updated some references from I-D to RFC,
and from old RFC to new RFC numbers. * Added reference to multicast
extensions to IPsec architecture RFC. * Added a reference to
2464-bis. * Removed FCC informative references, because not used. o
Updated the affiliation of one author. o Reformulation of some
phrases for better readability, and correction of typographical
errors.

Alex

-------- Message transf=C3=A9r=C3=A9 --------

*Sujet : *



New Version Notification for
draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

*Date : *



Sun, 10 Sep 2017 06:55:20 -0700

*De : *



internet-draf= ts@ietf.org <mailto:internet-drafts@ietf.org>
<mailto:in= ternet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>

*Pour : *



Nabil Benamar <= benamar73@gmail.com <mailto:benamar73@gmail.com>>
<mailto:benamar= 73@gmail.com <mailto:benamar73@gmail.com>>, Christian
Huitema <huitem= a@huitema.net <mailto:huitema@huitema.net>>
<mailto:huitema= @huitema.net <mailto:huitema@huitema.net>>, Jong-Hyouk
Lee <jonghyouk@= smu.ac.kr <mailto:jonghyouk@smu.ac.kr>>
<mailto:jonghyo= uk@smu.ac.kr <mailto:jonghyouk@smu.ac.kr>>, J=C3=A9r=C3=B4me
H=C3=A4rri <Jerome.Haerri@eurecom.fr <mailto:Jerome.Haerri@eurecom.fr>>
<mailto:Je= rome.Haerri@eurecom.fr <mailto:Jerome.Haerri@eurecom.fr>>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr
<mailto:A= lexandre.Petrescu@cea.fr>>
<mailto:A= lexandre.Petrescu@cea.fr
<mailto:A= lexandre.Petrescu@cea.fr>>, Tony Li <tony.li@tony.li
<mailto:tony.li@ton= y.li>> <mailto:tony.li@tony.li
<mailto:tony.li@ton= y.li>>, Alexandre Petrescu
<alexandr= e.petrescu@cea.fr <mailto:alexandre.petrescu@cea.fr>>
<mailto:a= lexandre.petrescu@cea.fr
<mailto:a= lexandre.petrescu@cea.fr>>, Jerome Haerri
<jerome.ha= erri@eurecom.fr <mailto:jerome.haerri@eurecom.fr>>
<mailto:je= rome.haerri@eurecom.fr <mailto:jerome.haerri@eurecom.fr>>, Thierry Ernst <thierry.ernst@yogoko.fr
<mailto:thi= erry.ernst@yogoko.fr>> <mailto:thierry.ernst@yogoko.fr
<mailto:thi= erry.ernst@yogoko.fr>>, ipwave-chairs@ietf.org
<mailto:ipwa= ve-chairs@ietf.org> <mailto:ipwave-chairs@ietf.org
<mailto:ipwa= ve-chairs@ietf.org>>

A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

has been successfully submitted by Alexandre Petrescu and posted to
the

IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-ipwave-ipv6-over-80= 211ocb

Revision:=C2=A0 =C2=A0 =C2=A0 05

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Transmission of IPv6 Packets over I= EEE 802.11
Networks operating in mode Outside the Context of a Basic Service
Set (IPv6-over-80211-OCB)

Document date: 2017-09-10

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ipwave

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A037


URL:https://www.ietf.org/int= ernet-drafts/draft-ietf-ipwave-ipv6-over-80211oc
b-05.txt


<https://www.ietf.org/= internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-0
5.txt>




Status:https://datatracker.iet<= wbr>f.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb
/


<https://datatracker.ietf.o= rg/doc/draft-ietf-ipwave-ipv6-over-80211ocb/>




Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05


<https://tools.ietf.org/html/d= raft-ietf-ipwave-ipv6-over-80211ocb-05>




Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-8
0211ocb-05


<https://datatracker.i= etf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-
05>




Diff:https://www.ietf.org/r= fcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80211ocb-
05


<https://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80211ocb-05>


Abstract:

In order to transmit IPv6 packets on IEEE 802.11 networks run
outside

the context of a basic service set (OCB, earlier "802.11p") there= is

a need to define a few parameters such as the supported Maximum

Transmission Unit size on the 802.11-OCB link, the header format

preceding the IPv6 header, the Type value within it, and others.

This document describes these parameters for IPv6 and IEEE
802.11-OCB

networks; it portrays the layering of IPv6 on 802.11-OCB similarly
to

other known 802.11 and Ethernet layers - by using an Ethernet

Adaptation Layer.

In addition, the document lists what is different in 802.11-OCB

(802.11p) links compared to more 'traditional' 802.11a/b/g/n links,=

where IPv6 protocols operate without issues.=C2=A0 Most notably, the

operation outside the context of a BSS (OCB) has impact on IPv6

handover behaviour and on IPv6 security.



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
<= http://tools.ietf.org>.

The IETF Secretariat


_______________________________________________ its mailing list
its@ietf.org <mail= to:its@ietf.org> https://www.ietf.org/mailman/listinfo/its
<https://www.ietf.org/mailman/listinfo/its><= br>

_______________________________________________ its mailing list
its@ietf.org <mail= to:its@ietf.org> https://www.ietf.org/mailman/listinfo/its
<https://www.ietf.org/mailman/listinfo/its><= br>



--


PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS:
wwhyte@onbo= ardsecurity.com <mailto:wwhyte@onboardsecurity.com>

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





--
=


PLEASE UPDATE YOUR ADDRESS BOOKS WIT= H MY NEW ADDRESS: wwhyte@onboardsecurity.com
--001a11468c92a2bb7705598a3c4c-- From nobody Tue Sep 19 07:23:04 2017 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 56AE1134337 for ; Tue, 19 Sep 2017 07:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 IVxb6PH7Mc1q for ; Tue, 19 Sep 2017 07:22:57 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 79EA8134239 for ; Tue, 19 Sep 2017 07:22:49 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id i13so172474qtc.11 for ; Tue, 19 Sep 2017 07:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=55vfT1SyqLhsFnJyPyslvjtOD7fdjRwBsoK3fBjeyPw=; b=BNupdA0/OWdPLhDAxfpyDqq90m5BvK8egARAdKjH4HKgEkS1DeEVFRiK3oxar2PnVU CIRIFMzsnF/EobhtgvUsDdjO6LU3dTD3qQ+8kxFrc576NeNqPIFUnYr/+2hPu4rRNqtt 785KXJvOTpLvx/pWDix/YSCrmTbbjOxu32f14S986UiGl5zePJulnsDOtVJ+2ztxV1eG YqUBMQFnfnn8xHrf6QqMIKc2Sp2RfJLKN3bcOv8EwIbiFAl4F4Slh+33D+HggSOfeD15 ZUGcpmSSNWiB/GAjLfxjA7MT9OPn/av+d9nW75FLrP5AMMttpX1xpVrfinRtgejTGvr4 5EeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=55vfT1SyqLhsFnJyPyslvjtOD7fdjRwBsoK3fBjeyPw=; b=Yv5lJ53Wbbow+DUUyx48OvuBtF04Dq7jffEF9GKgyqdNnB1aIZOUm8xjMNn56cjESK vx720NBwMqyd6OxLmN0kygyRc57zd13xBLA0F4f241KjHDJ+mHEgiOVvNKzP52DAnK9M ymH7e+l7kDZD1IeZ38tDyA3zJiCw9D5LgEAqZHIIY47OwbbKTe3neqaad1SQMrd5TYG3 oxhqy+Pn0k4c8RhasFijNcTw2pe7ExhUUy5HxzRy2PjKwU7WjtzbXYrlJy7tTjY/Vm+B 7GWSmzGTcH5gC6fjeb87HRqTEHiI60qdhnqfWO2FpaA9hMDIbKNlu1+d1hKPLoSJ/2BD bihw== X-Gm-Message-State: AHPjjUhLxaD0/gMr10SQwXLDbr/eJ7Nw21pi2qEwyYOa2lpPLsIn/UEm l3dfSOuuB8sBXgScHCGQkXA= X-Google-Smtp-Source: AOwi7QAH8m61d0vhg32AQ2uwKSMu/SObVjitDyoyvv0XX6t9Q14MXvTca6PBkweZxy2gmTEqgO5ThA== X-Received: by 10.200.8.131 with SMTP id v3mr2151131qth.262.1505830968296; Tue, 19 Sep 2017 07:22:48 -0700 (PDT) Received: from FrancoisPC (pool-108-48-85-190.washdc.fios.verizon.net. [108.48.85.190]) by smtp.gmail.com with ESMTPSA id g15sm6869836qtk.47.2017.09.19.07.22.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 07:22:46 -0700 (PDT) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" Cc: , References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> <011101d32d3e$00cc7d20$02657760$@gmail.com> <75e59482-38b7-c1c7-a09d-67de78588ad4@gmail.com> <000d01d33075$13cd39c0$3b67ad40$@gmail.com> <7493ccf3-a782-c88d-552f-2a6d2cc7085b@gmail.com> In-Reply-To: <7493ccf3-a782-c88d-552f-2a6d2cc7085b@gmail.com> Date: Tue, 19 Sep 2017 10:22:45 -0400 Message-ID: <003d01d33152$c4482ca0$4cd885e0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01D33131.3D368CA0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIukhOZsx60BumPZtxqsZkYmsT8+wFgJMjwAbp9UtkCl75/SwITd9gzAmE14w2htEXJQA== Archived-At: Subject: Re: [ipwave] -06 comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 14:23:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003E_01D33131.3D368CA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mr. Petrescu, Here are the answers to your questions. If you have additional questions, please, let me know. Sincerely, Francois Simon Lojik Technologies [Fygs: Only the US views are addressed here.] We received your comments and tried to resolve them. 1. This is the changelog that solves simple things. I invite you to look how they are solved in the new version, -07. o Added new terms: OBRU and RSRU ('R' for Router). Refined the existing terms RSU and OBU, which are no longer used throughout the document. o Improved definition of term "802.11-OCB". o Clarified that OCB does not "strip" security, but that the operation in OCB mode is "stripped off of all .11 security". o Clarified that theoretical OCB bandwidth speed is 54mbits, but that a commonly observed bandwidth in IP-over-OCB is 12mbit/s. [Fygs: Most of the =E2=80=9Ctrials=E2=80=9D have used 10 Mhz channel = spacing and 6 mbit/s] o Corrected typographical errors, and improved some phrasing. 2. I would like to ask you three questions: Do you know whether there is an EtherType allocated by IEEE for WAVE = messages? I noticed in packets BSM-over-802.11-OCB that the used type = is 0x88DC. Packet available upon request. This value is in LLC Header, = Type Field. It is understood by the Wireshark tool. But I dont see it = listed at IANA, IEEE 802 Numbers: https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml But on that page I do see 0x8947 for GeoNetworking and 0x86DD for IPv6. [Fygs: Reference http://standards-oui.ieee.org/ethertype/eth.txt : 0x88DC is the Ether type for WAVE WSMP assigned to IEEE 1609 WG = =E2=80=93 out of scope for IPWAVE =E2=80=93 IPv6 over OCB. 88dc - IEEE P1609 WG 3800 N Fairfax Drive #207, Arlington VA = 22203-1759 - Wireless Access in a Vehicle Environment (WAVE) Short = Message Protocol (WSM) as defined in IEEE P1609.3. 0x86DD is the Ether type for IPv6 assigned to the Internet Society. 86DD - USC/ISI 4676 Admiralty Way, Marina del Rey CA 90292 US - = Crawford, M. -=20 IPv6 - Internet Protocol Version 6 - Transmission of IPv6 Packets over = Ethernet Networks, RFC-2464, Internet Society, Dec. 1998 - = =20 Packets over Ethernet Networks, RFC-2464, Internet Society, Dec. =20 http://www.ietf.org/rfc/rfc2464.txt = = =20 =20 0x8947 is the Ether type for GeoNetworking assigned to ETSI. 8947 - ETSI 650 Route des lucioles, Sophia Antipolis 06921 FR - = = =20 GeoNetworking as defined in ETSI EN 302 636-4-1. Link to the protocol: = http://webapp.etsi.org/workprogram/Frame_WorkItemList.asp?SearchPage=3DTR= UE&qSORT=3DHIGHVERSION&qINCLUDE_SUB_TB=3DTrue&butSimple=3D++Search++&qETS= I_STANDARD_TYPE=3D&qETSI_NUMBER=3D302+636-4-1&qETSI_ALL=3DTRUE&qMILESTONE= =3D&qACHIEVED_DAY=3D&qACHIEVED_MONTH=3D&qACHIEVED_YEAR=3D&qREPORT_TYPE=3D= SUMMARY&optDisplay=3D10&qTB_ID=3D&includeNonActiveTB=3DFALSE] = =20 Do you think this existing text is wrong?: > At the time of writing, the prohibition [of IPv6] is explicit at=20 > higher layer protocols providing services to the application; these=20 > higher layer protocols are specified in IEEE 1609 documents, i.e. > the "WAVE" stack. [Fygs: See comments below.] Finally, in your review, when you read the -06 text saying "Some = channels are reserved for safety communications; the IPv6 packets should = not be sent on these channels." you are commenting in your review that = "This assumes that Safety applications would not use IPv6; erroneous = assumption." My question is the following: do you want text deleted? Which one? Or is it just a comment? Know that some WG members already = suggested that "IPv6 packets should be sent on the channels reserved for = safety". [Fygs: Text from =E2=80=9Cversion 7=E2=80=9D:=20 =E2=80=9CProhibition of IPv6 on some channels relevant for IEEE = 802.11-OCB, as opposed to IPv6 not being prohibited on any channel on = which 802.11a/b/g/n runs: * Some channels are reserved for safety communications; the IPv6 packets should not be sent on these channels. * At the time of writing, the prohibition is explicit at higher layer protocols providing services to the application; these higher layer protocols are specified in IEEE 1609 documents, i.e. the "WAVE" stack. * National or regional specifications and regulations specify the use of different channels; these regulations must be followed. Any channels within the 5.9 GHz band can be used to exchange safety = applications data, except for the 5 MHz in the lower part of the band = which is =E2=80=9Creserved=E2=80=9D. However, FCC identify channels 172 = (33 dBm max. EIRP) and 184 (33/44 dBm max. EIRP) which are = =E2=80=9Cdesignated for public safety applications involving safety of = life and property.=E2=80=9D The national regulations (FCC =E2=80=93 47 = CFR) specify the channel use details but does not specify protocols. Since IPWAVE IPv6 over OCB is exclusively related to =E2=80=9CIPv6 = =E2=80=93 LLC=E2=80=9D Service Access Point (SAP) (above the OCB MAC), = there is no requirement to be compatible with the IEEE 1609 protocol = stack. Therefore, the prohibition is irrelevant and should not be = stated. LLC, IEEE 802.11, and FCC have no protocol restriction on any of = the channels of 5.9 GHz band]. It is recommended to delete this entire section (shown above) of the = document.] Alex -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Monday, September 18, 2017 8:01 AM To: Fran=C3=A7ois Simon Subject: Re: -06 comments Mr. Simon, I just corrected my meessage, publicly. Please post publicly about this, and about the way we addressed all = other comments from your review. Alex Le 18/09/2017 =C3=A0 13:55, Fran=C3=A7ois Simon a =C3=A9crit : > Mr. Petrescu, >=20 > I will answer the questions. Do you want the response CCed to the WG = members? If so re-send the e-mail with the following statement = corrected: " Know that some WG members already suggested that "IPv6 = packets should be sent on the channels reserved for safety" >=20 > Sincerely, >=20 > Fygs >=20 > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Sunday, September 17, 2017 2:29 PM > To: Fran=C3=A7ois Simon > > Cc: its@ietf.org =20 > Subject: Re: -06 comments >=20 > Mr. Simon, >=20 > We received your comments and tried to resolve them. >=20 > 1. This is the changelog that solves simple things. I invite you to > look how they are solved in the new version, -07. > o Added new terms: OBRU and RSRU ('R' for Router). Refined the > existing terms RSU and OBU, which are no longer used = throughout > the document. > o Improved definition of term "802.11-OCB". > o Clarified that OCB does not "strip" security, but that the > operation in OCB mode is "stripped off of all .11 security". > o Clarified that theoretical OCB bandwidth speed is 54mbits, but > that a commonly observed bandwidth in IP-over-OCB is 12mbit/s. > o Corrected typographical errors, and improved some phrasing. >=20 > 2. I would like to ask you three questions: >=20 > Do you know whether there is an EtherType allocated by IEEE for WAVE = messages? I noticed in packets BSM-over-802.11-OCB that the used type = is 0x88DC. Packet available upon request. This value is in LLC Header, = Type Field. It is understood by the Wireshark tool. But I dont see it = listed at IANA, IEEE 802 Numbers: > https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xht > ml But on that page I do see 0x8947 for GeoNetworking and 0x86DD for=20 > IPv6. >=20 > Do you think this existing text is wrong?: >> At the time of writing, the prohibition [of IPv6] is explicit at=20 >> higher layer protocols providing services to the application; these=20 >> higher layer protocols are specified in IEEE 1609 documents, i.e. >> the "WAVE" stack. >=20 >=20 > Finally, in your review, when you read the -06 text saying "Some = channels are reserved for safety communications; the IPv6 packets should = not be sent on these channels." you are commenting in your review that = "This assumes that Safety applications would not use IPv6; erroneous = assumption." My question is the following: do you want text deleted? > Which one? Or is it just a comment? Know that some WG members = already suggested that "IPv6 packets should be sent on the channels = reserved for safety". >=20 > Alex >=20 >=20 >=20 >=20 > Le 14/09/2017 =C3=A0 11:44, Fran=C3=A7ois Simon a =C3=A9crit : >> Mr. Petrescu, >> >> Find attached comments on version 06 of the document. >> >> Let me know if you have any questions. >> >> Francois Yves Simon >> >> Lojik Technologies >> >> *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre=20 >> Petrescu *Sent:* Sunday, September 10, 2017 9:58 AM *To:*=20 >> its@ietf.org =20 >> *Subject:* [ipwave] Fwd: New Version Notification for=20 >> draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >> >> Dear participants to IPWAVE WG, >> >> This is the new IPv6-over-802.11-OCB addressing all the Reviewers=20 >> comments. >> >> This is the ChangeLog: >> >> o Lengthened the title and cleanded the abstract. o Added text=20 >> suggesting LLs may be easy to use on OCB, rather than GUAs based on=20 >> received prefix. o Added the risks of spoofing and hijacking. o=20 >> Removed the text speculation on adoption of the TSA message. o=20 >> Clarified that the ND protocol is used. o Clarified what it means "No = >> association needed". o Added some text about how two STAs discover=20 >> each other. o Added mention of external (OCB) and internal network=20 >> (stable), in the subnet structure section. o Added phrase explaining=20 >> that both .11 Data and .11 QoS Data headers are currently being used, = >> and may be used in the future. o Moved the packet capture example=20 >> into an Appendix Implementation Status. o Suggested moving the=20 >> reliability requirements appendix out into another document. o Added=20 >> a IANA Consiserations section, with content, requesting for a new=20 >> multicast group "all OCB interfaces". o Added new OBU term, improved=20 >> the RSU term definition, removed the ETTC term, replaced more=20 >> occurences of 802.11p, 802.11 OCB with 802.11-OCB. o References: *=20 >> Added an informational reference to ETSI=E2=80=99s IPv6-over- = GeoNetworking. >> * Added more references to IETF and ETSI security protocols. *=20 >> Updated some references from I-D to RFC, and from old RFC to new RFC = numbers. >> * Added reference to multicast extensions to IPsec architecture RFC.=20 >> * Added a reference to 2464-bis. * Removed FCC informative=20 >> references, because not used. o Updated the affiliation of one=20 >> author. o Reformulation of some phrases for better readability, and=20 >> correction of typographical errors. >> >> Alex >> >> -------- Message transf=C3=A9r=C3=A9 -------- >> >> *Sujet : * >> >> >> >> New Version Notification for >> draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >> >> *Date : * >> >> >> >> Sun, 10 Sep 2017 06:55:20 -0700 >> >> *De : * >> >> >> >> internet-drafts@ietf.org = >> >> *Pour : * >> >> >> >> Nabil Benamar > = ,=20 >> Christian Huitema > = ,=20 >> Jong-Hyouk Lee > = ,=20 >> J=C3=A9r=C3=B4me H=C3=A4rri >=20 >> , Alexandre Petrescu=20 >> > = , Tony=20 >> Li > = , Alexandre Petrescu=20 >> > = , >> Jerome Haerri >=20 >> , Thierry Ernst=20 >> > = ,=20 >> ipwave-chairs@ietf.org = >> >> A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >> >> has been successfully submitted by Alexandre Petrescu and posted to=20 >> the >> >> IETF repository. >> >> Name: draft-ietf-ipwave-ipv6-over-80211ocb >> >> Revision: 05 >> >> Title: Transmission of IPv6 Packets over IEEE 802.11 Networks >> operating in mode Outside the Context of a Basic Service Set >> (IPv6-over-80211-OCB) >> >> Document date: 2017-09-10 >> >> Group: ipwave >> >> Pages: 37 >> >> URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over- >> 8 >> 0211ocb-05.txt >> >> =20 >> Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-8 >> 0 >> 211ocb/ >> >> =20 >> Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-8021 >> 1 >> ocb-05 >> >> =20 >> Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6 >> - >> over-80211ocb-05 >> >> =20 >> = Diff:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80 >> 2 >> 11ocb-05 >> >> Abstract: >> >> In order to transmit IPv6 packets on IEEE 802.11 networks run outside >> >> the context of a basic service set (OCB, earlier "802.11p") there is >> >> a need to define a few parameters such as the supported Maximum >> >> Transmission Unit size on the 802.11-OCB link, the header format >> >> preceding the IPv6 header, the Type value within it, and others. >> >> This document describes these parameters for IPv6 and IEEE 802.11-OCB >> >> networks; it portrays the layering of IPv6 on 802.11-OCB similarly to >> >> other known 802.11 and Ethernet layers - by using an Ethernet >> >> Adaptation Layer. >> >> In addition, the document lists what is different in 802.11-OCB >> >> (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, >> >> where IPv6 protocols operate without issues. Most notably, the >> >> operation outside the context of a BSS (OCB) has impact on IPv6 >> >> handover behaviour and on IPv6 security. >> >> >> >> Please note that it may take a couple of minutes from the time of=20 >> submission >> >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >=20 ------=_NextPart_000_003E_01D33131.3D368CA0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RE: -06 comments

Mr. = Petrescu,

Here are the = answers to = your questions.

If you have = additional questions, please, let me know.

Sincerely,

Francois = Simon

Lojik = Technologies

[Fygs: Only = the US views are addressed here.]

We received = your comments and tried to resolve them.

1. This is the = changelog that solves simple things.  I invite you = to

    look how they are solved in the new = version, -07.

    o  Added new terms: OBRU and = RSRU ('R' for Router).  Refined the

       existing terms RSU = and OBU, which are no longer used throughout

       the = document.

    o  Improved definition of term = "802.11-OCB".

    o  Clarified that OCB does not = "strip" security, but that the

       operation in OCB = mode is "stripped off of all .11 security".

    o  Clarified that theoretical = OCB bandwidth speed is 54mbits, but

       that a commonly = observed bandwidth in IP-over-OCB is 12mbit/s.

[Fygs: Most of = the =E2=80=9Ctrials=E2=80=9D have used 10 Mhz channel spacing and 6 = mbit/s]

    o  Corrected typographical = errors, and improved some phrasing.

2. I would like = to ask you three questions:

Do you know = whether there is an EtherType allocated by IEEE for WAVE messages?  = I noticed in packets BSM-over-802.11-OCB that the used type is = 0x88DC.  Packet available upon request.  This value is in LLC = Header, Type Field.  It is understood by the Wireshark tool.  = But I dont see it listed at IANA, IEEE 802 Numbers:

https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbe= rs.xhtml

But on that = page I do see 0x8947 for GeoNetworking and 0x86DD for = IPv6.

[Fygs: = Reference http://standards= -oui.ieee.org/ethertype/eth.txt :

0x88DC is = the Ether type for WAVE WSMP assigned to IEEE 1609 WG =E2=80=93 out of = scope for IPWAVE =E2=80=93 IPv6 over OCB.

88dc  = -  IEEE P1609 WG   3800 N Fairfax Drive = #207, Arlington VA  22203-1759   -  Wireless Access in a Vehicle = Environment (WAVE) Short Message Protocol (WSM) as defined in IEEE = P1609.3.


0x86DD is = the Ether type for IPv6 assigned to the Internet = Society.

86DD - = USC/ISI 4676 Admiralty Way, Marina del Rey  CA  90292 US - = Crawford, M. - =

IPv6 - = Internet Protocol Version 6 - Transmission of IPv6 Packets over Ethernet = Networks, RFC-2464, Internet Society, Dec. 1998 = -            =             &= nbsp;           &n= bsp;

Packets over = Ethernet Networks, RFC-2464, Internet Society, = Dec.       

http://www.ietf.org/rfc/rfc2= 464.txt          &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              =

         &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;

0x8947 is = the Ether type for GeoNetworking assigned to ETSI.

8947  -  ETSI 650 Route des lucioles, Sophia Antipolis 06921 = FR  -          &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;         =

GeoNetworking as defined in ETSI EN 302 = 636-4-1.

Link to the = protocol: htt= p://webapp.etsi.org/workprogram/Frame_WorkItemList.asp?SearchPage=3DTRUE&= qSORT=3DHIGHVERSION&qINCLUDE_SUB_TB=3DTrue&butSimple=3D++Search++&qETSI_S= TANDARD_TYPE=3D&qETSI_NUMBER=3D302+636-4-1&qETSI_ALL=3DTRUE&qMILESTONE=3D= &qACHIEVED_DAY=3D&qACHIEVED_MONTH=3D&qACHIEVED_YEAR=3D&qREPORT_TYPE=3DSUM= MARY&optDisplay=3D10&qTB_ID=3D&includeNonActiveTB=3DFALSE]=          &n= bsp;   

Do you think = this existing text is wrong?:

> At the = time of writing, the prohibition [of IPv6] is explicit at =

> higher = layer protocols providing services to the application; these =

> higher = layer protocols are specified in IEEE 1609 documents, = i.e.

> the = "WAVE" stack.

[Fygs: See = comments below.]

Finally, in = your review, when you read the -06 text saying "Some channels are = reserved for safety communications; the IPv6 packets should not be sent = on these channels." you are commenting in your review that = "This assumes that Safety applications would not use IPv6; = erroneous assumption."  My question is the following: do you = want text deleted?

Which = one?  Or is it just a comment?  Know that some WG members = already suggested that "IPv6 packets should be sent on the channels = reserved for safety".

[Fygs: Text = from =E2=80=9Cversion 7=E2=80=9D:

=E2=80=9CProhibition of IPv6 on some = channels relevant for IEEE 802.11-OCB, as opposed to IPv6 not being = prohibited on any channel on which

802.11a/b/g/n runs:

      *  Some channels = are reserved for safety communications; the = IPv6

         = packets should not be sent on these channels.

      *  At the time of = writing, the prohibition is explicit at higher

         layer = protocols providing services to the application; = these

         higher = layer protocols are specified in IEEE 1609 = documents,

         i.e. = the "WAVE" stack.

      *  National or = regional specifications and regulations specify = the

         use of = different channels; these regulations must be = followed.

 Any = channels within the 5.9 GHz band can be used to exchange safety = applications data, except for the 5 MHz in the lower part of the band = which is =E2=80=9Creserved=E2=80=9D.  However, FCC identify = channels 172 (33 dBm max. EIRP) and 184 (33/44 dBm max. EIRP) which are = =E2=80=9Cdesignated for public safety applications involving = safety of life and property.=E2=80=9D The national = regulations (FCC =E2=80=93 47 CFR) specify the channel use details but = does not specify protocols.

Since IPWAVE = IPv6 over OCB is exclusively related to =E2=80=9CIPv6 =E2=80=93 = LLC=E2=80=9D Service Access Point (SAP) (above the OCB MAC), there is no = requirement to be compatible with the IEEE 1609 protocol stack.  = Therefore, the prohibition is irrelevant and should not be stated. LLC, = IEEE 802.11, and FCC have no protocol restriction on any of the channels = of 5.9 GHz band].

It is = recommended to delete this entire section (shown above) of the = document.]

Alex

-----Original = Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gm= ail.com]
Sent: Monday, September 18, 2017 8:01 AM
To: Fran=C3=A7ois Simon <fygsimon@gmail.com>
Subject: Re: -06 comments

Mr. = Simon,

I just = corrected my meessage, publicly.

Please post = publicly about this, and about the way we addressed all other comments = from your review.

Alex


Le 18/09/2017 = =C3=A0 13:55, Fran=C3=A7ois Simon a =C3=A9crit=C2=A0:

> Mr. = Petrescu,

> =

> I will = answer the questions.  Do you want the response CCed to the WG = members?  If so re-send the e-mail with the following statement = corrected: " Know that some WG members already suggested that = "IPv6 packets should be sent on the channels reserved for = safety"

> =

> = Sincerely,

> =

> = Fygs

> =

> = -----Original Message-----

> From: = Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]

> Sent: = Sunday, September 17, 2017 2:29 PM

> To: = Fran=C3=A7ois Simon <fygsimon@gmail.com>

> = Cc: its@ietf.org

> Subject: = Re: -06 comments

> =

> Mr. = Simon,

> =

> We = received your comments and tried to resolve them.

> =

> 1. This is = the changelog that solves simple things.  I invite you = to

>      look how they are = solved in the new version, -07.

>      o  Added new = terms: OBRU and RSRU ('R' for Router).  Refined = the

>         = existing terms RSU and OBU, which are no longer used = throughout

>         = the document.

>      o  Improved = definition of term "802.11-OCB".

>      o  Clarified = that OCB does not "strip" security, but that = the

>         = operation in OCB mode is "stripped off of all .11 = security".

>      o  Clarified = that theoretical OCB bandwidth speed is 54mbits, but

>         = that a commonly observed bandwidth in IP-over-OCB is = 12mbit/s.

>      o  Corrected = typographical errors, and improved some phrasing.

> =

> 2. I would = like to ask you three questions:

> =

> Do you = know whether there is an EtherType allocated by IEEE for WAVE = messages?  I noticed in packets BSM-over-802.11-OCB that the used = type is 0x88DC.  Packet available upon request.  This value is = in LLC Header, Type Field.  It is understood by the Wireshark = tool.  But I dont see it listed at IANA, IEEE 802 = Numbers:

> https://www.iana.org/assignments/ieee-802-numbers/ieee-8= 02-numbers.xht

> ml But on = that page I do see 0x8947 for GeoNetworking and 0x86DD for =

> = IPv6.

> =

> Do you = think this existing text is wrong?:

>> At the = time of writing, the prohibition [of IPv6] is explicit at =

>> higher = layer protocols providing services to the application; these =

>> higher = layer protocols are specified in IEEE 1609 documents, = i.e.

>> the = "WAVE" stack.

> =

> =

> Finally, = in your review, when you read the -06 text saying "Some channels = are reserved for safety communications; the IPv6 packets should not be = sent on these channels." you are commenting in your review that = "This assumes that Safety applications would not use IPv6; = erroneous assumption."  My question is the following: do you = want text deleted?

> Which = one?  Or is it just a comment?  Know that some WG members = already suggested that "IPv6 packets should be sent on the channels = reserved for safety".

> =

> = Alex

> =

> =

> =

> =

> Le = 14/09/2017 =C3=A0 11:44, Fran=C3=A7ois Simon a =C3=A9crit = :

>> Mr. = Petrescu,

>>

>> Find = attached comments on version 06 of the document.

>>

>> Let me = know if you have any questions.

>>

>> = Francois Yves Simon

>>

>> Lojik = Technologies

>>

>> = *From:*its [mailto:its-bounces@ietf.org] = *On Behalf Of *Alexandre

>> = Petrescu *Sent:* Sunday, September 10, 2017 9:58 AM *To:* =

>> its@ietf.org

>> = *Subject:* [ipwave] Fwd: New Version Notification for

>> = draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

>>

>> Dear = participants to IPWAVE WG,

>>

>> This = is the new IPv6-over-802.11-OCB addressing all the Reviewers =

>> = comments.

>>

>> This = is the ChangeLog:

>>

>> o = Lengthened the title and cleanded the abstract. o Added text =

>> = suggesting LLs may be easy to use on OCB, rather than GUAs based on =

>> = received prefix. o Added the risks of spoofing and hijacking. o =

>> = Removed the text speculation on adoption of the TSA message. o =

>> = Clarified that the ND protocol is used. o Clarified what it means = "No

>> = association needed". o Added some text about how two STAs discover =

>> each = other. o Added mention of external (OCB) and internal network =

>> = (stable), in the subnet structure section. o Added phrase explaining =

>> that = both .11 Data and .11 QoS Data headers are currently being used, =

>> and = may be used in the future. o Moved the packet capture example =

>> into = an Appendix Implementation Status. o Suggested moving the =

>> = reliability requirements appendix out into another document. o Added =

>> a IANA = Consiserations section, with content, requesting for a new =

>> = multicast group "all OCB interfaces". o Added new OBU term, = improved

>> the = RSU term definition, removed the ETTC term, replaced more =

>> = occurences of 802.11p, 802.11 OCB with 802.11-OCB. o References: * =

>> Added = an informational reference to ETSI=E2=80=99s IPv6-over- = GeoNetworking.

>> * = Added more references to IETF and ETSI security protocols. * =

>> = Updated some references from I-D to RFC, and from old RFC to new RFC = numbers.

>> * = Added reference to multicast extensions to IPsec architecture RFC. =

>> * = Added a reference to 2464-bis. * Removed FCC informative =

>> = references, because not used. o Updated the affiliation of one =

>> = author. o Reformulation of some phrases for better readability, and =

>> = correction of typographical errors.

>>

>> = Alex

>>

>> = -------- Message transf=C3=A9r=C3=A9 --------

>>

>> *Sujet = : *

>>

>>

>>

>> New = Version Notification for

>> = draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

>>

>> *Date = : *

>>

>>

>>

>> Sun, = 10 Sep 2017 06:55:20 -0700

>>

>> *De : = *

>>

>>

>>

>> internet-drafts@ietf.org = <mailto:internet-drafts@ietf.org>

>>

>> *Pour = : *

>>

>>

>>

>> Nabil = Benamar <benamar73@gmail.com> <mailto:benamar73@gmail.com>,

>> = Christian Huitema <huitema@huitema.net> <mailto:huitema@huitema.net>,

>> = Jong-Hyouk Lee <jonghyouk@smu.ac.kr> <mailto:jonghyouk@smu.ac.kr>,

>> = J=C3=A9r=C3=B4me H=C3=A4rri <Jerome.Haerri@eurecom.fr>

>> = <mailto:Jerome.Haerri@eurecom.fr>, Alexandre Petrescu

>> = <Alexandre.Petrescu@cea.fr> <mailto:Alexandre.Petrescu@cea.fr>, Tony

>> Li = <tony.li@tony.li> <mailto:tony.li@tony.li>, Alexandre Petrescu

>> = <alexandre.petrescu@cea.fr> <mailto:alexandre.petrescu@cea.fr>,

>> Jerome = Haerri <jerome.haerri@eurecom.fr>

>> = <mailto:jerome.haerri@eurecom.fr>, Thierry Ernst

>> = <thierry.ernst@yogoko.fr> <mailto:thierry.ernst@yogoko.fr>,

>> ipwave-chairs@ietf.org = <mailto:ipwave-chairs@ietf.org>

>>

>> A new = version of I-D, = draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

>>

>> has = been successfully submitted by Alexandre Petrescu and posted to =

>> = the

>>

>> IETF = repository.

>>

>> = Name:          = draft-ietf-ipwave-ipv6-over-80211ocb

>>

>> = Revision:      05

>>

>> = Title:         Transmission of = IPv6 Packets over IEEE 802.11 Networks

>> = operating in mode Outside the Context of a Basic Service = Set

>> = (IPv6-over-80211-OCB)

>>

>> = Document date: 2017-09-10

>>

>> = Group:         = ipwave

>>

>> = Pages:         = 37

>>

>> URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwa= ve-ipv6-over-

>> = 8

>> = 0211ocb-05.txt

>>

>>  

>> = Status:h= ttps://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-8<= /SPAN>

>> = 0

>> = 211ocb/

>>

>>  

>> = Htmlized:htt= ps://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-8021

>> = 1

>> = ocb-05

>>

>>  

>> = Htmlized:htt= ps://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6

>> = -

>> = over-80211ocb-05

>>

>>  

>> = Diff:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80=

>> = 2

>> = 11ocb-05

>>

>>   Abstract:

>>

>> In = order to transmit IPv6 packets on IEEE 802.11 networks run = outside

>>

>> the = context of a basic service set (OCB, earlier "802.11p") there = is

>>

>> a need = to define a few parameters such as the supported = Maximum

>>

>> = Transmission Unit size on the 802.11-OCB link, the header = format

>>

>> = preceding the IPv6 header, the Type value within it, and = others.

>>

>> This = document describes these parameters for IPv6 and IEEE = 802.11-OCB

>>

>> = networks; it portrays the layering of IPv6 on 802.11-OCB similarly = to

>>

>> other = known 802.11 and Ethernet layers - by using an = Ethernet

>>

>> = Adaptation Layer.

>>

>> In = addition, the document lists what is different in = 802.11-OCB

>>

>> = (802.11p) links compared to more 'traditional' 802.11a/b/g/n = links,

>>

>> where = IPv6 protocols operate without issues.  Most notably, = the

>>

>> = operation outside the context of a BSS (OCB) has impact on = IPv6

>>

>> = handover behaviour and on IPv6 security.

>>

>>

>>

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

>>

>

------=_NextPart_000_003E_01D33131.3D368CA0-- From nobody Tue Sep 19 08:05:51 2017 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 B6738133158 for ; Tue, 19 Sep 2017 08:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 XIE3s3t7uNRA for ; Tue, 19 Sep 2017 08:05:43 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF8A13306C for ; Tue, 19 Sep 2017 08:05:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.42,418,1500933600"; d="scan'208,217";a="6858249" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 19 Sep 2017 17:05:41 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 1B437F8E; Tue, 19 Sep 2017 17:05:41 +0200 (CEST) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: =?utf-8?Q?'Fran=C3=A7ois_Simon'?= , "'Alexandre Petrescu'" Cc: References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> <011101d32d3e$00cc7d20$02657760$@gmail.com> <75e59482-38b7-c1c7-a09d-67de78588ad4@gmail.com> <000d01d33075$13cd39c0$3b67ad40$@gmail.com> <7493ccf3-a782-c88d-552f-2a6d2cc7085b@gmail.com> <003d01d33152$c4482ca0$4cd885e0$@gmail.com> In-Reply-To: <003d01d33152$c4482ca0$4cd885e0$@gmail.com> Date: Tue, 19 Sep 2017 17:05:41 +0200 Organization: EURECOM Message-ID: <025101d33158$c25352c0$46f9f840$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0252_01D33169.85E598A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIukhOZsx60BumPZtxqsZkYmsT8+wFgJMjwAbp9UtkCl75/SwITd9gzAmE14w0Bqqau+qGm9lXA Content-Language: en-us Archived-At: Subject: Re: [ipwave] -06 comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 15:05:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0252_01D33169.85E598A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear Mr. Simon, =20 As far as I know, IEEE 802.11-2016 OCB is 10Mhz only. The 6Mbps is a = profile that is applied by WAVE and ETSI ITS but is out of scope of = IETF..we basically do not need to respect it (actually we should not, as = the tests showing the superior channel usage of 6Mps has been obtained = for fixed size BSM/CAM at constant Transmit Power and in Full Broadcast = mode)=E2=80=A6 =20 The only thing we can write there is that IEEE 802.11-2016 OCB has a = maximum capacity (theoretical bandwidth) of 27Mbps due to the 10Mhz = constraints=E2=80=A6finding the optimal modulation for IPv6 traffic = should be left open.=20 =20 For the Ethertype for OCB, it is important to differentiate what we mean = by IEEE.=20 =20 =C2=B7 IEEE 802.11 does not do it, and I would not understand = why they would need it, as OCB is clearly identified at LL by a wildcard = BSSID as well as ToDS and fromDS fields to set to 0.=20 =20 =C2=B7 IEEE 1609.x indeed proposed an Ethertype (used over the = last decade if I am not mistaken) for the WAVE stack (not BSM)..BSM use = such ethertype as they are not transmitted over IPv6 (or IPv4), but only = because they use a WAVE headers (and the WAVE non-IP stack). Would BSM = be sent over IPv6, they would most likely not use this ethertype.=20 o In EU, the ETSI followed a similar strategy for the GeoNet stack = (the Geonet headers)=E2=80=A6CAM use the GeoNet Ethertype but would most = likely not use it if CAM would be sent over plain IPv6.=20 =20 Now the question is: Why would we need a new Ethertype if we do plain = IPv6-over-OCB=E2=80=A6Why would we need to differentiate at L3 OCB from = BSS/IBSS WiFi ? IPv6 header and packets are the same, only the access = technology changes, which is out of scope of IETF. Could we use an IPv6 = Profile to provide some traffic differentiation?=20 =20 I understand there might be requirements at L3 to know that some of the = =E2=80=98assumed=E2=80=99 security mechanisms at 802.11 level be absent = (or that IPv6 ND would need to operate differently=E2=80=A6), and = therefore to adopt an alternative strategy=E2=80=A6I am just wondering = if an Ethertype is the right tool for this=E2=80=A6.Maybe some use cases = could we worth drawing and discussing.=20 =20 Best Regards, =20 J=C3=A9r=C3=B4me=20 =20 =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Fran=C3=A7ois Simon Sent: Tuesday 19 September 2017 16:23 To: 'Alexandre Petrescu' Cc: fygsimon@gmail.com; its@ietf.org Subject: Re: [ipwave] -06 comments =20 Mr. Petrescu, Here are the answers to your questions. If you have additional questions, please, let me know. Sincerely, Francois Simon Lojik Technologies [Fygs: Only the US views are addressed here.] We received your comments and tried to resolve them. 1. This is the changelog that solves simple things. I invite you to look how they are solved in the new version, -07. o Added new terms: OBRU and RSRU ('R' for Router). Refined the existing terms RSU and OBU, which are no longer used throughout the document. o Improved definition of term "802.11-OCB". o Clarified that OCB does not "strip" security, but that the operation in OCB mode is "stripped off of all .11 security". o Clarified that theoretical OCB bandwidth speed is 54mbits, but that a commonly observed bandwidth in IP-over-OCB is 12mbit/s. [Fygs: Most of the =E2=80=9Ctrials=E2=80=9D have used 10 Mhz channel = spacing and 6 mbit/s] o Corrected typographical errors, and improved some phrasing. 2. I would like to ask you three questions: Do you know whether there is an EtherType allocated by IEEE for WAVE = messages? I noticed in packets BSM-over-802.11-OCB that the used type = is 0x88DC. Packet available upon request. This value is in LLC Header, = Type Field. It is understood by the Wireshark tool. But I dont see it = listed at IANA, IEEE 802 Numbers: https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml But on that page I do see 0x8947 for GeoNetworking and 0x86DD for IPv6. [Fygs: Reference http://standards-oui.ieee.org/ethertype/eth.txt : 0x88DC is the Ether type for WAVE WSMP assigned to IEEE 1609 WG = =E2=80=93 out of scope for IPWAVE =E2=80=93 IPv6 over OCB. 88dc - IEEE P1609 WG 3800 N Fairfax Drive #207, Arlington VA = 22203-1759 - Wireless Access in a Vehicle Environment (WAVE) Short = Message Protocol (WSM) as defined in IEEE P1609.3. =20 0x86DD is the Ether type for IPv6 assigned to the Internet Society. 86DD - USC/ISI 4676 Admiralty Way, Marina del Rey CA 90292 US - = Crawford, M. -=20 IPv6 - Internet Protocol Version 6 - Transmission of IPv6 Packets over = Ethernet Networks, RFC-2464, Internet Society, Dec. 1998 - = =20 Packets over Ethernet Networks, RFC-2464, Internet Society, Dec. =20 http://www.ietf.org/rfc/rfc2464.txt = = =20 =20 0x8947 is the Ether type for GeoNetworking assigned to ETSI. 8947 - ETSI 650 Route des lucioles, Sophia Antipolis 06921 FR - = = =20 GeoNetworking as defined in ETSI EN 302 636-4-1. Link to the protocol: = http://webapp.etsi.org/workprogram/Frame_WorkItemList.asp?SearchPage=3DTR= UE = = &qSORT=3DHIGHVERSION&qINCLUDE_SUB_TB=3DTrue&butSimple=3D++Search++&qETSI_= STANDARD_TYPE=3D&qETSI_NUMBER=3D302+636-4-1&qETSI_ALL=3DTRUE&qMILESTONE=3D= &qACHIEVED_DAY=3D&qACHIEVED_MONTH=3D&qACHIEVED_YEAR=3D&qREPORT_TYPE=3DSUM= MARY&optDisplay=3D10&qTB_ID=3D&includeNonActiveTB=3DFALSE] =20 Do you think this existing text is wrong?: > At the time of writing, the prohibition [of IPv6] is explicit at=20 > higher layer protocols providing services to the application; these=20 > higher layer protocols are specified in IEEE 1609 documents, i.e. > the "WAVE" stack. [Fygs: See comments below.] Finally, in your review, when you read the -06 text saying "Some = channels are reserved for safety communications; the IPv6 packets should = not be sent on these channels." you are commenting in your review that = "This assumes that Safety applications would not use IPv6; erroneous = assumption." My question is the following: do you want text deleted? Which one? Or is it just a comment? Know that some WG members already = suggested that "IPv6 packets should be sent on the channels reserved for = safety". [Fygs: Text from =E2=80=9Cversion 7=E2=80=9D:=20 =E2=80=9CProhibition of IPv6 on some channels relevant for IEEE = 802.11-OCB, as opposed to IPv6 not being prohibited on any channel on = which 802.11a/b/g/n runs: * Some channels are reserved for safety communications; the IPv6 packets should not be sent on these channels. * At the time of writing, the prohibition is explicit at higher layer protocols providing services to the application; these higher layer protocols are specified in IEEE 1609 documents, i.e. the "WAVE" stack. * National or regional specifications and regulations specify the use of different channels; these regulations must be followed. Any channels within the 5.9 GHz band can be used to exchange safety = applications data, except for the 5 MHz in the lower part of the band = which is =E2=80=9Creserved=E2=80=9D. However, FCC identify channels 172 = (33 dBm max. EIRP) and 184 (33/44 dBm max. EIRP) which are = =E2=80=9Cdesignated for public safety applications involving safety of = life and property.=E2=80=9D The national regulations (FCC =E2=80=93 47 = CFR) specify the channel use details but does not specify protocols. Since IPWAVE IPv6 over OCB is exclusively related to =E2=80=9CIPv6 = =E2=80=93 LLC=E2=80=9D Service Access Point (SAP) (above the OCB MAC), = there is no requirement to be compatible with the IEEE 1609 protocol = stack. Therefore, the prohibition is irrelevant and should not be = stated. LLC, IEEE 802.11, and FCC have no protocol restriction on any of = the channels of 5.9 GHz band]. It is recommended to delete this entire section (shown above) of the = document.] Alex -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] Sent: Monday, September 18, 2017 8:01 AM To: Fran=C3=A7ois Simon Subject: Re: -06 comments Mr. Simon, I just corrected my meessage, publicly. Please post publicly about this, and about the way we addressed all = other comments from your review. Alex =20 Le 18/09/2017 =C3=A0 13:55, Fran=C3=A7ois Simon a =C3=A9crit : > Mr. Petrescu, >=20 > I will answer the questions. Do you want the response CCed to the WG = members? If so re-send the e-mail with the following statement = corrected: " Know that some WG members already suggested that "IPv6 = packets should be sent on the channels reserved for safety" >=20 > Sincerely, >=20 > Fygs >=20 > -----Original Message----- > From: Alexandre Petrescu [ = mailto:alexandre.petrescu@gmail.com] > Sent: Sunday, September 17, 2017 2:29 PM > To: Fran=C3=A7ois Simon < = fygsimon@gmail.com> > Cc: its@ietf.org > Subject: Re: -06 comments >=20 > Mr. Simon, >=20 > We received your comments and tried to resolve them. >=20 > 1. This is the changelog that solves simple things. I invite you to > look how they are solved in the new version, -07. > o Added new terms: OBRU and RSRU ('R' for Router). Refined the > existing terms RSU and OBU, which are no longer used = throughout > the document. > o Improved definition of term "802.11-OCB". > o Clarified that OCB does not "strip" security, but that the > operation in OCB mode is "stripped off of all .11 security". > o Clarified that theoretical OCB bandwidth speed is 54mbits, but > that a commonly observed bandwidth in IP-over-OCB is 12mbit/s. > o Corrected typographical errors, and improved some phrasing. >=20 > 2. I would like to ask you three questions: >=20 > Do you know whether there is an EtherType allocated by IEEE for WAVE = messages? I noticed in packets BSM-over-802.11-OCB that the used type = is 0x88DC. Packet available upon request. This value is in LLC Header, = Type Field. It is understood by the Wireshark tool. But I dont see it = listed at IANA, IEEE 802 Numbers: > = = https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xht > ml But on that page I do see 0x8947 for GeoNetworking and 0x86DD for=20 > IPv6. >=20 > Do you think this existing text is wrong?: >> At the time of writing, the prohibition [of IPv6] is explicit at=20 >> higher layer protocols providing services to the application; these=20 >> higher layer protocols are specified in IEEE 1609 documents, i.e. >> the "WAVE" stack. >=20 >=20 > Finally, in your review, when you read the -06 text saying "Some = channels are reserved for safety communications; the IPv6 packets should = not be sent on these channels." you are commenting in your review that = "This assumes that Safety applications would not use IPv6; erroneous = assumption." My question is the following: do you want text deleted? > Which one? Or is it just a comment? Know that some WG members = already suggested that "IPv6 packets should be sent on the channels = reserved for safety". >=20 > Alex >=20 >=20 >=20 >=20 > Le 14/09/2017 =C3=A0 11:44, Fran=C3=A7ois Simon a =C3=A9crit : >> Mr. Petrescu, >>=20 >> Find attached comments on version 06 of the document. >>=20 >> Let me know if you have any questions. >>=20 >> Francois Yves Simon >>=20 >> Lojik Technologies >>=20 >> *From:*its [ = mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre=20 >> Petrescu *Sent:* Sunday, September 10, 2017 9:58 AM *To:*=20 >> its@ietf.org >> *Subject:* [ipwave] Fwd: New Version Notification for=20 >> draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>=20 >> Dear participants to IPWAVE WG, >>=20 >> This is the new IPv6-over-802.11-OCB addressing all the Reviewers=20 >> comments. >>=20 >> This is the ChangeLog: >>=20 >> o Lengthened the title and cleanded the abstract. o Added text=20 >> suggesting LLs may be easy to use on OCB, rather than GUAs based on=20 >> received prefix. o Added the risks of spoofing and hijacking. o=20 >> Removed the text speculation on adoption of the TSA message. o=20 >> Clarified that the ND protocol is used. o Clarified what it means "No = >> association needed". o Added some text about how two STAs discover=20 >> each other. o Added mention of external (OCB) and internal network=20 >> (stable), in the subnet structure section. o Added phrase explaining=20 >> that both .11 Data and .11 QoS Data headers are currently being used, = >> and may be used in the future. o Moved the packet capture example=20 >> into an Appendix Implementation Status. o Suggested moving the=20 >> reliability requirements appendix out into another document. o Added=20 >> a IANA Consiserations section, with content, requesting for a new=20 >> multicast group "all OCB interfaces". o Added new OBU term, improved=20 >> the RSU term definition, removed the ETTC term, replaced more=20 >> occurences of 802.11p, 802.11 OCB with 802.11-OCB. o References: *=20 >> Added an informational reference to ETSI=E2=80=99s IPv6-over- = GeoNetworking. >> * Added more references to IETF and ETSI security protocols. *=20 >> Updated some references from I-D to RFC, and from old RFC to new RFC = numbers. >> * Added reference to multicast extensions to IPsec architecture RFC.=20 >> * Added a reference to 2464-bis. * Removed FCC informative=20 >> references, because not used. o Updated the affiliation of one=20 >> author. o Reformulation of some phrases for better readability, and=20 >> correction of typographical errors. >>=20 >> Alex >>=20 >> -------- Message transf=C3=A9r=C3=A9 -------- >>=20 >> *Sujet : * >>=20 >>=20 >>=20 >> New Version Notification for >> draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>=20 >> *Date : * >>=20 >>=20 >>=20 >> Sun, 10 Sep 2017 06:55:20 -0700 >>=20 >> *De : * >>=20 >>=20 >>=20 >> internet-drafts@ietf.org < = mailto:internet-drafts@ietf.org> >>=20 >> *Pour : * >>=20 >>=20 >>=20 >> Nabil Benamar < benamar73@gmail.com> < = mailto:benamar73@gmail.com>,=20 >> Christian Huitema < huitema@huitema.net> = < mailto:huitema@huitema.net>,=20 >> Jong-Hyouk Lee < jonghyouk@smu.ac.kr> < = mailto:jonghyouk@smu.ac.kr>,=20 >> J=C3=A9r=C3=B4me H=C3=A4rri < = Jerome.Haerri@eurecom.fr>=20 >> < mailto:Jerome.Haerri@eurecom.fr>, = Alexandre Petrescu=20 >> < Alexandre.Petrescu@cea.fr> < = mailto:Alexandre.Petrescu@cea.fr>, = Tony=20 >> Li < tony.li@tony.li> < = mailto:tony.li@tony.li>, Alexandre Petrescu=20 >> < alexandre.petrescu@cea.fr> < = mailto:alexandre.petrescu@cea.fr>, >> Jerome Haerri < = jerome.haerri@eurecom.fr>=20 >> < mailto:jerome.haerri@eurecom.fr>, = Thierry Ernst=20 >> < thierry.ernst@yogoko.fr> < = mailto:thierry.ernst@yogoko.fr>,=20 >> ipwave-chairs@ietf.org < = mailto:ipwave-chairs@ietf.org> >>=20 >> A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>=20 >> has been successfully submitted by Alexandre Petrescu and posted to=20 >> the >>=20 >> IETF repository. >>=20 >> Name: draft-ietf-ipwave-ipv6-over-80211ocb >>=20 >> Revision: 05 >>=20 >> Title: Transmission of IPv6 Packets over IEEE 802.11 Networks >> operating in mode Outside the Context of a Basic Service Set >> (IPv6-over-80211-OCB) >>=20 >> Document date: 2017-09-10 >>=20 >> Group: ipwave >>=20 >> Pages: 37 >>=20 >> = = URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over- >> 8 >> 0211ocb-05.txt >>=20 >> =20 >> Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-8 >> 0 >> 211ocb/ >>=20 >> =20 >> Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-8021 >> 1 >> ocb-05 >>=20 >> =20 >> Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6 >> - >> over-80211ocb-05 >>=20 >> =20 >> = Diff:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80 >> 2 >> 11ocb-05 >>=20 >> Abstract: >>=20 >> In order to transmit IPv6 packets on IEEE 802.11 networks run outside >>=20 >> the context of a basic service set (OCB, earlier "802.11p") there is >>=20 >> a need to define a few parameters such as the supported Maximum >>=20 >> Transmission Unit size on the 802.11-OCB link, the header format >>=20 >> preceding the IPv6 header, the Type value within it, and others. >>=20 >> This document describes these parameters for IPv6 and IEEE 802.11-OCB >>=20 >> networks; it portrays the layering of IPv6 on 802.11-OCB similarly to >>=20 >> other known 802.11 and Ethernet layers - by using an Ethernet >>=20 >> Adaptation Layer. >>=20 >> In addition, the document lists what is different in 802.11-OCB >>=20 >> (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, >>=20 >> where IPv6 protocols operate without issues. Most notably, the >>=20 >> operation outside the context of a BSS (OCB) has impact on IPv6 >>=20 >> handover behaviour and on IPv6 security. >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission >>=20 >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 ------=_NextPart_000_0252_01D33169.85E598A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: -06 comments

Dear Mr. Simon,

 

As far as I know, IEEE 802.11-2016 OCB is 10Mhz only. The 6Mbps is a = profile that is applied by WAVE and ETSI ITS but is out of scope of = IETF..we basically do not need to respect it (actually we should not, as = the tests showing the superior channel usage of 6Mps has been obtained = for fixed size BSM/CAM at constant Transmit Power and in Full Broadcast = mode)=E2=80=A6

 

The only thing we can write there is that IEEE 802.11-2016 OCB has a = maximum capacity (theoretical bandwidth) of 27Mbps due to the 10Mhz = constraints=E2=80=A6finding the optimal modulation for IPv6 traffic = should be left open.

 

For the Ethertype for OCB, it is important to differentiate what we = mean by IEEE.

 

=C2=B7         = IEEE 802.11 does not do it, and I would not understand why they would = need it, as OCB is clearly identified at LL by a wildcard BSSID as well = as ToDS and fromDS fields to set to 0.

 

=C2=B7         = IEEE 1609.x indeed proposed an Ethertype (used over the last decade = if I am not mistaken) for the WAVE stack (not BSM)..BSM use such = ethertype as they are not transmitted over IPv6 (or IPv4), but only = because they use a WAVE headers (and the WAVE non-IP stack). Would BSM = be sent over IPv6, they would most likely not use this ethertype. =

o   In EU, the ETSI followed a similar strategy for the GeoNet stack (the = Geonet headers)=E2=80=A6CAM use the GeoNet Ethertype but would most = likely not use it if CAM would be sent over plain IPv6. =

=C2=A0

Now the question is: Why would we need a new Ethertype if we do plain = IPv6-over-OCB=E2=80=A6Why would we need to differentiate at L3 OCB from = BSS/IBSS WiFi ? IPv6 header and packets are the same, only the access = technology changes, which is out of scope of IETF. Could we use an IPv6 = Profile to provide some traffic differentiation? =

=C2=A0

I understand there might be requirements at L3 to know that some of = the =E2=80=98assumed=E2=80=99 security mechanisms at 802.11 level be = absent (or that IPv6 ND would need to operate differently=E2=80=A6), and = therefore to adopt an alternative strategy=E2=80=A6I am just wondering = if an Ethertype is the right tool for this=E2=80=A6.Maybe some use cases = could we worth drawing and discussing.

 

Best Regards,

 

J=C3=A9r=C3=B4me

 

 

 

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of Fran=C3=A7ois = Simon
Sent: Tuesday 19 September 2017 16:23
To: = 'Alexandre Petrescu'
Cc: fygsimon@gmail.com; = its@ietf.org
Subject: Re: [ipwave] -06 = comments

 

Mr. = Petrescu,

Here are the answers to = your questions.

If you have additional = questions, please, let me know.

Sincerely,=

Francois = Simon

Lojik = Technologies

[Fygs: Only the US views = are addressed here.]

We received your comments = and tried to resolve them.

1. This is the changelog = that solves simple things.  I invite you = to

    look how = they are solved in the new version, -07.

    o  = Added new terms: OBRU and RSRU ('R' for Router).  Refined = the

    &nbs= p;  existing terms RSU and OBU, which are no longer used = throughout

    &nbs= p;  the document.

    o  = Improved definition of term = "802.11-OCB".

    o  = Clarified that OCB does not "strip" security, but that = the

    &nbs= p;  operation in OCB mode is "stripped off of all .11 = security".

    o  = Clarified that theoretical OCB bandwidth speed is 54mbits, = but

    &nbs= p;  that a commonly observed bandwidth in IP-over-OCB is = 12mbit/s.

[Fygs: Most of the = =E2=80=9Ctrials=E2=80=9D have used 10 Mhz channel spacing and 6 = mbit/s]

    o  = Corrected typographical errors, and improved some = phrasing.

2. I would like to ask you = three questions:

Do you know whether there = is an EtherType allocated by IEEE for WAVE messages?  I noticed in = packets BSM-over-802.11-OCB that the used type is 0x88DC.  Packet = available upon request.  This value is in LLC Header, Type = Field.  It is understood by the Wireshark tool.  But I dont = see it listed at IANA, IEEE 802 Numbers:

https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbe= rs.xhtml

But on that page I do see = 0x8947 for GeoNetworking and 0x86DD for = IPv6.

[Fygs: Reference http://standards= -oui.ieee.org/ethertype/eth.txt = :

0x88DC is the Ether type = for WAVE WSMP assigned to IEEE 1609 WG =E2=80=93 out of scope for IPWAVE = =E2=80=93 IPv6 over OCB.

88dc  = -  IEEE = P1609 WG   3800 N Fairfax Drive #207, Arlington VA  = 22203-1759   -  Wireless Access in a = Vehicle Environment (WAVE) Short Message Protocol (WSM) as defined in = IEEE P1609.3.

 

0x86DD is the Ether type = for IPv6 assigned to the Internet = Society.

86DD - USC/ISI 4676 = Admiralty Way, Marina del Rey  CA  90292 US - Crawford, M. = -

IPv6 - Internet Protocol = Version 6 - Transmission of IPv6 Packets over Ethernet Networks, = RFC-2464, Internet Society, Dec. 1998 = -            =             &= nbsp;           &n= bsp;

Packets over Ethernet = Networks, RFC-2464, Internet Society, = Dec.        =

http://www.ietf.org/rfc/rfc2= 464.txt          &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              =

    &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;     

0x8947 is the Ether type = for GeoNetworking assigned to ETSI.

8947  = -  ETSI 650 Route des = lucioles, Sophia Antipolis 06921 FR  -     &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; 

GeoNetworking as defined in = ETSI EN 302 636-4-1.

Link to the protocol: http://webapp.etsi.o= rg/workprogram/Frame_WorkItemList.asp?SearchPage=3DTRUE&qSORT=3DHIGHV= ERSION&qINCLUDE_SUB_TB=3DTrue&butSimple=3D++Search++&qETSI_ST= ANDARD_TYPE=3D&qETSI_NUMBER=3D302+636-4-1&qETSI_ALL=3DTRUE&qM= ILESTONE=3D&qACHIEVED_DAY=3D&qACHIEVED_MONTH=3D&qACHIEVED_YEA= R=3D&qREPORT_TYPE=3DSUMMARY&optDisplay=3D10&qTB_ID=3D&inc= ludeNonActiveTB=3DFALSE]    &nbs= p;         =

Do you think this existing = text is wrong?:

> At the time of = writing, the prohibition [of IPv6] is explicit at =

> higher layer protocols = providing services to the application; these =

> higher layer protocols = are specified in IEEE 1609 documents, i.e.

> the "WAVE" = stack.

[Fygs: See comments = below.]

Finally, in your review, = when you read the -06 text saying "Some channels are reserved for = safety communications; the IPv6 packets should not be sent on these = channels." you are commenting in your review that "This = assumes that Safety applications would not use IPv6; erroneous = assumption."  My question is the following: do you want text = deleted?

Which one?  Or is it = just a comment?  Know that some WG members already suggested that = "IPv6 packets should be sent on the channels reserved for = safety".

[Fygs: Text from = =E2=80=9Cversion 7=E2=80=9D:

=E2=80=9CProhibition of = IPv6 on some channels relevant for IEEE 802.11-OCB, as opposed to IPv6 = not being prohibited on any channel on = which

802.11a/b/g/n = runs:

    &nbs= p; *  Some channels are reserved for safety communications; the = IPv6

    &nbs= p;    packets should not be sent on these = channels.

    &nbs= p; *  At the time of writing, the prohibition is explicit at = higher

    &nbs= p;    layer protocols providing services to the = application; these

    &nbs= p;    higher layer protocols are specified in IEEE 1609 = documents,

    &nbs= p;    i.e. the "WAVE" = stack.

    &nbs= p; *  National or regional specifications and regulations specify = the

    &nbs= p;    use of different channels; these regulations must = be followed.

<= p> Any = channels within the 5.9 GHz band can be used to exchange safety = applications data, except for the 5 MHz in the lower part of the band = which is =E2=80=9Creserved=E2=80=9D.  However, FCC identify = channels 172 (33 dBm max. EIRP) and 184 (33/44 dBm max. EIRP) which are = =E2=80=9Cdesignated for public safety applications involving safety = of life and property.=E2=80=9D The national regulations (FCC = =E2=80=93 47 CFR) specify the channel use details but does not specify = protocols.

Since IPWAVE IPv6 over OCB = is exclusively related to =E2=80=9CIPv6 =E2=80=93 LLC=E2=80=9D Service = Access Point (SAP) (above the OCB MAC), there is no requirement to be = compatible with the IEEE 1609 protocol stack.  Therefore, the = prohibition is irrelevant and should not be stated. LLC, IEEE 802.11, = and FCC have no protocol restriction on any of the channels of 5.9 GHz = band].

It is recommended to delete = this entire section (shown above) of the = document.]

Alex

-----Original = Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gm= ail.com]
Sent: Monday, September 18, 2017 8:01 AM
To: = Fran=C3=A7ois Simon <fygsimon@gmail.com>
Subject:= Re: -06 comments

Mr. = Simon,

I just corrected my = meessage, publicly.

Please post publicly about = this, and about the way we addressed all other comments from your = review.

Alex

 

Le 18/09/2017 =C3=A0 13:55, = Fran=C3=A7ois Simon a =C3=A9crit :

> Mr. = Petrescu,

> =

> I will answer the = questions.  Do you want the response CCed to the WG members?  = If so re-send the e-mail with the following statement corrected: " = Know that some WG members already suggested that "IPv6 packets = should be sent on the channels reserved for = safety"

> =

> = Sincerely,

> =

> = Fygs

> =

> -----Original = Message-----

> From: Alexandre = Petrescu [mailto:alexandre.petrescu@gm= ail.com]

> Sent: Sunday, = September 17, 2017 2:29 PM

> To: Fran=C3=A7ois = Simon <fygsimon@gmail.com>

> Cc: its@ietf.org=

> = Subject: Re: -06 comments

> =

> Mr. = Simon,

> =

> We received your = comments and tried to resolve them.

> =

> 1. This is the = changelog that solves simple things.  I invite you = to

>    =   look how they are solved in the new version, = -07.

>    =   o  Added new terms: OBRU and RSRU ('R' for Router).  = Refined the

>    =      existing terms RSU and OBU, which are no longer = used throughout

>    =      the document.

>    =   o  Improved definition of term = "802.11-OCB".

>    =   o  Clarified that OCB does not "strip" security, = but that the

>    =      operation in OCB mode is "stripped off of = all .11 security".

>    =   o  Clarified that theoretical OCB bandwidth speed is = 54mbits, but

>    =      that a commonly observed bandwidth in = IP-over-OCB is 12mbit/s.

>    =   o  Corrected typographical errors, and improved some = phrasing.

> =

> 2. I would like to ask = you three questions:

> =

> Do you know whether = there is an EtherType allocated by IEEE for WAVE messages?  I = noticed in packets BSM-over-802.11-OCB that the used type is = 0x88DC.  Packet available upon request.  This value is in LLC = Header, Type Field.  It is understood by the Wireshark tool.  = But I dont see it listed at IANA, IEEE 802 = Numbers:

> https://www.iana.org/assignm= ents/ieee-802-numbers/ieee-802-numbers.xht

> ml But on that = page I do see 0x8947 for GeoNetworking and 0x86DD for =

> = IPv6.

> =

> Do you think this = existing text is wrong?:

>> At the time of = writing, the prohibition [of IPv6] is explicit at =

>> higher layer = protocols providing services to the application; these =

>> higher layer = protocols are specified in IEEE 1609 documents, = i.e.

>> the = "WAVE" stack.

> =

> =

> Finally, in your = review, when you read the -06 text saying "Some channels are = reserved for safety communications; the IPv6 packets should not be sent = on these channels." you are commenting in your review that = "This assumes that Safety applications would not use IPv6; = erroneous assumption."  My question is the following: do you = want text deleted?

> Which one?  Or is = it just a comment?  Know that some WG members already suggested = that "IPv6 packets should be sent on the channels reserved for = safety".

> =

> = Alex

> =

> =

> =

> =

> Le 14/09/2017 =C3=A0 = 11:44, Fran=C3=A7ois Simon a =C3=A9crit :

>> Mr. = Petrescu,

>> 

>> = Find attached comments on version 06 of the = document.

>> 

>> = Let me know if you have any questions.

>> 

>> = Francois Yves Simon

>> 

>> = Lojik Technologies

>> 

>> = *From:*its [mailto:its-bounces@ietf.org<= /span>] *On = Behalf Of *Alexandre

>> Petrescu *Sent:* = Sunday, September 10, 2017 9:58 AM *To:*

>> its@ietf.org=

>> = *Subject:* [ipwave] Fwd: New Version Notification for =

>> = draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

>> 

>> = Dear participants to IPWAVE WG,

>> 

>> = This is the new IPv6-over-802.11-OCB addressing all the Reviewers =

>> = comments.

>> 

>> = This is the ChangeLog:

>> 

>> o = Lengthened the title and cleanded the abstract. o Added text =

>> suggesting LLs may = be easy to use on OCB, rather than GUAs based on =

>> received prefix. o = Added the risks of spoofing and hijacking. o =

>> Removed the text = speculation on adoption of the TSA message. o =

>> Clarified that the = ND protocol is used. o Clarified what it means "No =

>> association = needed". o Added some text about how two STAs discover =

>> each other. o = Added mention of external (OCB) and internal network =

>> (stable), in the = subnet structure section. o Added phrase explaining =

>> that both .11 Data = and .11 QoS Data headers are currently being used, =

>> and may be used in = the future. o Moved the packet capture example =

>> into an Appendix = Implementation Status. o Suggested moving the =

>> reliability = requirements appendix out into another document. o Added =

>> a IANA = Consiserations section, with content, requesting for a new =

>> multicast group = "all OCB interfaces". o Added new OBU term, improved =

>> the RSU term = definition, removed the ETTC term, replaced more =

>> occurences of = 802.11p, 802.11 OCB with 802.11-OCB. o References: * =

>> Added an = informational reference to ETSI=E2=80=99s IPv6-over- = GeoNetworking.

>> * Added more = references to IETF and ETSI security protocols. * =

>> Updated some = references from I-D to RFC, and from old RFC to new RFC = numbers.

>> * Added reference = to multicast extensions to IPsec architecture RFC. =

>> * Added a = reference to 2464-bis. * Removed FCC informative =

>> references, = because not used. o Updated the affiliation of one =

>> author. o = Reformulation of some phrases for better readability, and =

>> correction of = typographical errors.

>> 

>> = Alex

>> 

>> = -------- Message transf=C3=A9r=C3=A9 = --------

>> 

>> = *Sujet : *

>> 

>> 

>> 

>> = New Version Notification for

>> = draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

>> 

>> = *Date : *

>> 

>> 

>> 

>> = Sun, 10 Sep 2017 06:55:20 -0700

>> 

>> = *De : *

>> 

>> 

>> 

>> internet-drafts@ietf.org <mailto:internet-drafts@ietf.= org>

>> 

>> = *Pour : *

>> 

>> 

>> 

>> = Nabil Benamar <benamar73@gmail.com> <mailto:benamar73@gmail.com>, =

>> Christian Huitema = <huitema@huitema.net> <mailto:huitema@huitema.net>, =

>> Jong-Hyouk Lee = <jonghyouk@smu.ac.kr> <mailto:jonghyouk@smu.ac.kr>, =

>> J=C3=A9r=C3=B4me = H=C3=A4rri <Jerome.Haerri@eurecom.fr> =

>> <mailto:Jerome.Haerri@eurecom= .fr>, = Alexandre Petrescu

>> <Alexandre.Petrescu@cea.fr> = <mailto:Alexandre.Petrescu@ce= a.fr>, = Tony

>> Li <tony.li@tony.li> <mailto:tony.li@tony.li>, Alexandre = Petrescu

>> <alexandre.petrescu@cea.fr> = <mailto:alexandre.petrescu@ce= a.fr>,

<= p>>> Jerome = Haerri <jerome.haerri@eurecom.fr> =

>> <mailto:jerome.haerri@eurecom= .fr>, = Thierry Ernst

>> <thierry.ernst@yogoko.fr> = <mailto:thierry.ernst@yogoko.= fr>, =

>> ipwave-chairs@ietf.org <mailto:ipwave-chairs@ietf.or= g>

>> 

>> A = new version of I-D, = draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

>> 

>> = has been successfully submitted by Alexandre Petrescu and posted to =

>> = the

>> 

>> = IETF repository.

>> 

>> = Name:          = draft-ietf-ipwave-ipv6-over-80211ocb

>> 

>> = Revision:      05

>> 

>> = Title:         Transmission of = IPv6 Packets over IEEE 802.11 Networks

>> operating in mode = Outside the Context of a Basic Service Set

>> = (IPv6-over-80211-OCB)

>> 

>> = Document date: 2017-09-10

>> 

>> = Group:         = ipwave

>> 

>> = Pages:         = 37

>> 

>> URL:https://www.ietf.org/int= ernet-drafts/draft-ietf-ipwave-ipv6-over-

>> = 8

>> = 0211ocb-05.txt

>> 

>>   =

>> Status:h= ttps://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-8<= o:p>

>> = 0

>> = 211ocb/

>> 

>>   =

>> Htmlized:htt= ps://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-8021=

>> = 1

>> = ocb-05

>> 

>>   =

>> Htmlized:htt= ps://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6=

>> = -

>> = over-80211ocb-05

>> 

>>   =

>> Diff:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80=

>> = 2

>> = 11ocb-05

>> 

>>   = Abstract:

>> 

>> = In order to transmit IPv6 packets on IEEE 802.11 networks run = outside

>> 

>> = the context of a basic service set (OCB, earlier "802.11p") = there is

>> 

>> a = need to define a few parameters such as the supported = Maximum

>> 

>> = Transmission Unit size on the 802.11-OCB link, the header = format

>> 

>> = preceding the IPv6 header, the Type value within it, and = others.

>> 

>> = This document describes these parameters for IPv6 and IEEE = 802.11-OCB

>> 

>> = networks; it portrays the layering of IPv6 on 802.11-OCB similarly = to

>> 

>> = other known 802.11 and Ethernet layers - by using an = Ethernet

>> 

>> = Adaptation Layer.

>> 

>> = In addition, the document lists what is different in = 802.11-OCB

>> 

>> = (802.11p) links compared to more 'traditional' 802.11a/b/g/n = links,

>> 

>> = where IPv6 protocols operate without issues.  Most notably, = the

>> 

>> = operation outside the context of a BSS (OCB) has impact on = IPv6

>> 

>> = handover behaviour and on IPv6 security.

>> 

>> 

>> 

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

>> 

> =

------=_NextPart_000_0252_01D33169.85E598A0-- From nobody Tue Sep 19 08:51:55 2017 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 66EB8133200 for ; Tue, 19 Sep 2017 08:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 26hv4rBkbCXj for ; Tue, 19 Sep 2017 08:51:51 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 8C96B132403 for ; Tue, 19 Sep 2017 08:51:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8JFpmxC001655; Tue, 19 Sep 2017 17:51:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BE57720E5F0; Tue, 19 Sep 2017 17:51: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 AE8BD20E5F3; Tue, 19 Sep 2017 17:51:48 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8JFpmwx021785; Tue, 19 Sep 2017 17:51:48 +0200 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" Cc: its@ietf.org References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> <011101d32d3e$00cc7d20$02657760$@gmail.com> <75e59482-38b7-c1c7-a09d-67de78588ad4@gmail.com> <000d01d33075$13cd39c0$3b67ad40$@gmail.com> <7493ccf3-a782-c88d-552f-2a6d2cc7085b@gmail.com> <003d01d33152$c4482ca0$4cd885e0$@gmail.com> <025101d33158$c25352c0$46f9f840$@eurecom.fr> From: Alexandre Petrescu Message-ID: Date: Tue, 19 Sep 2017 17:51:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <025101d33158$c25352c0$46f9f840$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] -06 comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 15:51:53 -0000 Le 19/09/2017 à 17:05, Jérôme Härri a écrit : [...] > Now the question is: Why would we need a new Ethertype if we do plain > IPv6-over-OCB… Let me clarify myself: I am not asking for a new EtherType for IPv6-over-OCB. IPv6-over-OCB uses 0x86DD, and that's fine. What may be needed, is IANA to list 0x88DC too, for the sake of completeness at IANA. That's not in IPv6-over-OCB. > Why would we need to differentiate at L3 OCB from BSS/IBSS WiFi ? > IPv6 header and packets are the same, only the access technology > changes, which is out of scope of IETF. Could we use an IPv6 Profile > to provide some traffic differentiation? > > I understand there might be requirements at L3 to know that some of > the ‘assumed’ security mechanisms at 802.11 level be absent (or that > IPv6 ND would need to operate differently…), and therefore to adopt > an alternative strategy…I am just wondering if an Ethertype is the > right tool for this…. No, not the right tool. Sorry if I made a mistake here stirring the waters. If somebody with IP background builds a unique box for all country markets (instead of currently 2 distinct boxes) then that somebody will look up EtherTypes at IEEE and at IETF and everywhere else where it is necessary. One can live with that, it's just browsing the web. Alex From nobody Tue Sep 19 08:55:10 2017 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 CC917132403 for ; Tue, 19 Sep 2017 08:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 mqB7jn30C2Cu for ; Tue, 19 Sep 2017 08:55:03 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 73534133020 for ; Tue, 19 Sep 2017 08:55:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8JFt1HY015054; Tue, 19 Sep 2017 17:55:01 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EA09620E287; Tue, 19 Sep 2017 17:55:00 +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 DB7EE2039EF; Tue, 19 Sep 2017 17:55:00 +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 v8JFsxqd024372; Tue, 19 Sep 2017 17:55:00 +0200 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= Cc: its@ietf.org References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> <011101d32d3e$00cc7d20$02657760$@gmail.com> <75e59482-38b7-c1c7-a09d-67de78588ad4@gmail.com> <000d01d33075$13cd39c0$3b67ad40$@gmail.com> <7493ccf3-a782-c88d-552f-2a6d2cc7085b@gmail.com> <003d01d33152$c4482ca0$4cd885e0$@gmail.com> From: Alexandre Petrescu Message-ID: <3272a3c1-5a9c-6697-1b86-d3b6c2641eb0@gmail.com> Date: Tue, 19 Sep 2017 17:54:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <003d01d33152$c4482ca0$4cd885e0$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] -06 comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 15:55:06 -0000 Le 19/09/2017 à 16:22, François Simon a écrit : [...] > [Fygs: Most of the “trials” have used 10 Mhz channel spacing and 6 mbit/s] Some of trials someone tried on road did 12mbit/s. Not sure what channel spacing was it, though. [...]> *[Fygs: Text from “version 7”: * > > *“**/Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB, > as opposed to IPv6 not being prohibited on any channel on which/* > > */802.11a/b/g/n runs:/* > > */      *  Some channels are reserved for safety communications; the IPv6/* > > */         packets should not be sent on these channels./* > > */      *  At the time of writing, the prohibition is explicit at higher/* > > */         layer protocols providing services to the application; these/* > > */         higher layer protocols are specified in IEEE 1609 documents,/* > > */         i.e. the "WAVE" stack./* > > */      *  National or regional specifications and regulations specify the/* > > */         use of different channels; these regulations must be > followed/**.* > > * Any channels within the 5.9 GHz band can be used to exchange safety > applications data, except for the 5 MHz in the lower part of the band > which is “reserved”.  However, FCC identify channels 172 (33 dBm max. > EIRP) and 184 (33/44 dBm max. EIRP) which are “**/designated for public > safety applications involving safety of life and property/**.” The > national regulations (FCC – 47 CFR) specify the channel use details but > does not specify protocols.* > > *Since IPWAVE IPv6 over OCB is exclusively related to “IPv6 – LLC” > Service Access Point (SAP) (above the OCB MAC), there is no requirement > to be compatible with the IEEE 1609 protocol stack.  Therefore, the > prohibition is irrelevant and should not be stated. LLC, IEEE 802.11, > and FCC have no protocol restriction on any of the channels of 5.9 GHz > band].* > > *It is recommended to delete this entire section (shown above) of the > document.]* Noted. Alex From nobody Tue Sep 19 09:11:21 2017 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2811C1320D9; Tue, 19 Sep 2017 09:11:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150583748013.11713.14434850817084888861@ietfa.amsl.com> Date: Tue, 19 Sep 2017 09:11:20 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-08.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 16:11:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Alexandre Petrescu Nabil Benamar Jérôme Härri Christian Huitema Jong-Hyouk Lee Thierry Ernst Tony Li Filename : draft-ietf-ipwave-ipv6-over-80211ocb-08.txt Pages : 38 Date : 2017-09-19 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. In addition, the document lists what is different in 802.11-OCB (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, where IPv6 protocols operate without issues. Most notably, the operation outside the context of a BSS (OCB) impacts IPv6 handover behaviour and IPv6 security. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-08 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-08 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/ From nobody Tue Sep 19 09:13:32 2017 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 34D2C134289 for ; Tue, 19 Sep 2017 09:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 179IlMYoBvYX for ; Tue, 19 Sep 2017 09:13:28 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 44819134286 for ; Tue, 19 Sep 2017 09:13:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8JGDQsE008404 for ; Tue, 19 Sep 2017 18:13:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A409520E627 for ; Tue, 19 Sep 2017 18:13:26 +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 983D720E3D8 for ; Tue, 19 Sep 2017 18:13:26 +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 v8JGDOh1010546 for ; Tue, 19 Sep 2017 18:13:26 +0200 References: <150583748025.11713.12831102529539042106.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <150583748025.11713.12831102529539042106.idtracker@ietfa.amsl.com> Message-ID: Date: Tue, 19 Sep 2017 18:13:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150583748025.11713.12831102529539042106.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------38344A2A9B35B3EB4CC67E80" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-08.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 16:13:30 -0000 This is a multi-part message in MIME format. --------------38344A2A9B35B3EB4CC67E80 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear participants to IPWAVE WG, I just submitted the -08.  This is the ChangeLog: - Removed the per-channel IPv6 prohibition text. - Corrected typographical errors. Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-08.txt Date : Tue, 19 Sep 2017 09:11:20 -0700 De : internet-drafts@ietf.org Pour : Nabil Benamar , Christian Huitema , Jong-Hyouk Lee , Jérôme Härri , Alexandre Petrescu , Tony Li , Alexandre Petrescu , Jerome Haerri , Thierry Ernst , ipwave-chairs@ietf.org A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-08.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 08 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Document date: 2017-09-19 Group: ipwave Pages: 38 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-08.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-08 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-08 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. In addition, the document lists what is different in 802.11-OCB (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, where IPv6 protocols operate without issues. Most notably, the operation outside the context of a BSS (OCB) impacts IPv6 handover behaviour and IPv6 security. 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 --------------38344A2A9B35B3EB4CC67E80 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear participants to IPWAVE WG,

I just submitted the -08.  This is the ChangeLog:

- Removed the per-channel IPv6 prohibition text.

- Corrected typographical errors.

Alex



-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-08.txt
Date : Tue, 19 Sep 2017 09:11:20 -0700
De : internet-drafts@ietf.org
Pour : Nabil Benamar <benamar73@gmail.com>, Christian Huitema <huitema@huitema.net>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr>, Jérôme Härri <Jerome.Haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Tony Li <tony.li@tony.li>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Jerome Haerri <jerome.haerri@eurecom.fr>, Thierry Ernst <thierry.ernst@yogoko.fr>, ipwave-chairs@ietf.org 


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

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	08
Title:		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:	2017-09-19
Group:		ipwave
Pages:		38
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-08.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-08
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-08
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-08

Abstract:
   In order to transmit IPv6 packets on IEEE 802.11 networks running
   outside the context of a basic service set (OCB, earlier "802.11p")
   there is a need to define a few parameters such as the supported
   Maximum Transmission Unit size on the 802.11-OCB link, the header
   format preceding the IPv6 header, the Type value within it, and
   others.  This document describes these parameters for IPv6 and IEEE
   802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
   similarly to other known 802.11 and Ethernet layers - by using an
   Ethernet Adaptation Layer.

   In addition, the document lists what is different in 802.11-OCB
   (802.11p) links compared to more 'traditional' 802.11a/b/g/n links,
   where IPv6 protocols operate without issues.  Most notably, the
   operation outside the context of a BSS (OCB) impacts IPv6 handover
   behaviour and IPv6 security.

                                                                                  


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
--------------38344A2A9B35B3EB4CC67E80-- From nobody Tue Sep 19 11:46:39 2017 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 0E6A4134357 for ; Tue, 19 Sep 2017 11:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 ZF9XORHEnI4Q for ; Tue, 19 Sep 2017 11:46:35 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 F0D59134353 for ; Tue, 19 Sep 2017 11:46:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8JIkUcO057118; Tue, 19 Sep 2017 20:46:30 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AFD9220E60A; Tue, 19 Sep 2017 20:46: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 9D2C1201A90; Tue, 19 Sep 2017 20:46:30 +0200 (CEST) Received: from [132.166.84.160] ([132.166.84.160]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8JIkTWK005049; Tue, 19 Sep 2017 20:46:30 +0200 To: dickroy@alum.mit.edu, "'William Whyte'" Cc: its@ietf.org References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> <011101d32d3e$00cc7d20$02657760$@gmail.com> <75e59482-38b7-c1c7-a09d-67de78588ad4@gmail.com> <541905b5-3c4b-337b-21a2-d421d9cd28bc@gmail.com> <20e2b3e5-70e3-36ac-dec1-6bbefcb4c453@gmail.com> <7C012720BADE47279874D36436256947@SRA6> <23930411-16f8-a80e-64d6-d029b4f6f55f@gmail.com> <808F0D756066423AB34F0CE215C865F6@SRA6> From: Alexandre Petrescu Message-ID: <2e21f216-d549-4cf1-3b25-c419c2304263@gmail.com> Date: Tue, 19 Sep 2017 20:46:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <808F0D756066423AB34F0CE215C865F6@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] -06 comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 18:46:38 -0000 Le 19/09/2017 à 19:15, Dick Roy a écrit : > I believe the IANA listing is simply meant to reflect the content of the > IEEE RA ethertype assignments. It is apparently only updated occasionally > and is today a bit out of date. I would not worry about such small matters. > I would, however, look to the IEEE RA site as the official site for > ethertypes, not the IANA site. Agreed. (and please fix the email issue so your emails get into the archive, without me having to respond) Alex > > RR > > -----Original ----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Tuesday, September 19, 2017 4:43 AM > To: dickroy@alum.mit.edu; 'William Whyte' > Cc: its@ietf.org > Subject: Re: [ipwave] -06 comments > > > > Le 19/09/2017 à 00:19, Dick Roy a écrit : >> Alex et.al., >> >> To clarify, there is NO IANA listing for messages of any kind > > But there is this listing there: > https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml > > It does say 0x86DD for IPv6 and 0x8947 for GeoNetworking. Do you think > 0x88DC does not fit there too? ("(WAVE) Short Message Protocol (WSM)") > > If I want to build a unique box (not multiple boxes one per Region) I'd > have to write the code such that it multiplexes based on that EtherType. > It might be that code is an IP code. As such I'd look at IANA to see > the EtherTypes. > > Alex > > , WSMs >> included. The IANA listings to which you refer below are the ethertype >> listings. Ethertypes identify protocols, not messages. 0x88DC is > assigned >> to the WAVE Short Message Protocol which specifies how to construct a >> transport layer header and a network layer header for exchanging TSDUs >> between peer entities where there is NO network layer addressing at all! >> Note that in ISO, the equivalent protocol used to be called NNTP >> (Null-Network & Transport layer Protocol) for just that reason! >> >> Cheers, >> >> RR >> >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu >> Sent: Monday, September 18, 2017 3:50 AM >> To: William Whyte >> Cc: its@ietf.org >> Subject: Re: [ipwave] -06 comments >> >> Hi William, >> >> Le 18/09/2017 à 12:41, William Whyte a écrit : >>> Hi Alex, >>> >>>> Do you know whether there is an EtherType allocated by IEEE for >>>> WAVE >>> messages? >>> >>> The IANA listing isn't the definitive listing of ethertype values. >> >> I agree, the IANA listing is just echoing the IEEE listing with respect >> to EtherTypes. But it is very useful. >> >>> The definitive listing is at >>> http://standards-oui.ieee.org/ethertype/eth.txt, which assigns 88dc >>> to "Wireless Access in a Vehicle Environment (WAVE) Short Message >>> Protocol (WSM) as defined in IEEE P1609.3." >>> >>> BTW, note that "WAVE messages" isn't the best terminology to use -- >>> this is an identifier for WAVE *Short* Messages, or WSMs. "WAVE >>> messages" is a term with no defined meaning. >> >> I agree. To clarify myself, Wireshark calls 0x88DC "(WAVE) Short >> Message Protocol (WSM)". Maybe this is more in-line with what is > expected. >> >> Alex >> >>> >>> Cheers, >>> >>> William >>> >>> On Sun, Sep 17, 2017 at 3:33 PM, Alexandre Petrescu >>> > >>> wrote: >>> >>> >>> >>> Le 17/09/2017 à 20:29, Alexandre Petrescu a écrit : [...] >>> >>> Finally, in your review, when you read the -06 text saying "Some >>> channels are reserved for safety communications; the IPv6 packets >>> should not be sent on these channels." you are commenting in your >>> review that "This assumes that Safety applications would not use >>> IPv6; erroneous assumption." My question is the following: do you >>> want text deleted? Which one? Or is it just a comment? Know that >>> some WG members already suggested that "IPv6 packets should be sent >>> on the channels reserved for safety". >>> >>> >>> I meant "_not_ be sent on the channels reserved for safety", >>> obviously. >>> >>> Alex >>> >>> >>> >>> Alex >>> >>> >>> >>> >>> Le 14/09/2017 à 11:44, François Simon a écrit : >>> >>> Mr. Petrescu, >>> >>> Find attached comments on version 06 of the document. >>> >>> Let me know if you have any questions. >>> >>> Francois Yves Simon >>> >>> Lojik Technologies >>> >>> *From:*its [mailto:its-bounces@ietf.org >>> ] *On Behalf Of *Alexandre Petrescu >>> *Sent:* Sunday, September 10, 2017 9:58 AM *To:* its@ietf.org >>> *Subject:* [ipwave] Fwd: New Version >>> Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>> >>> Dear participants to IPWAVE WG, >>> >>> This is the new IPv6-over-802.11-OCB addressing all the Reviewers >>> comments. >>> >>> This is the ChangeLog: >>> >>> o Lengthened the title and cleanded the abstract. o Added text >>> suggesting LLs may be easy to use on OCB, rather than GUAs based on >>> received prefix. o Added the risks of spoofing and hijacking. o >>> Removed the text speculation on adoption of the TSA message. o >>> Clarified that the ND protocol is used. o Clarified what it means >>> "No association needed". o Added some text about how two STAs >>> discover each other. o Added mention of external (OCB) and internal >>> network (stable), in the subnet structure section. o Added phrase >>> explaining that both .11 Data and .11 QoS Data headers are currently >>> being used, and may be used in the future. o Moved the packet >>> capture example into an Appendix Implementation Status. o Suggested >>> moving the reliability requirements appendix out into another >>> document. o Added a IANA Consiserations section, with content, >>> requesting for a new multicast group "all OCB interfaces". o Added >>> new OBU term, improved the RSU term definition, removed the ETTC >>> term, replaced more occurences of 802.11p, 802.11 OCB with >>> 802.11-OCB. o References: * Added an informational reference to >>> ETSI's IPv6-over- GeoNetworking. * Added more references to IETF and >>> ETSI security protocols. * Updated some references from I-D to RFC, >>> and from old RFC to new RFC numbers. * Added reference to multicast >>> extensions to IPsec architecture RFC. * Added a reference to >>> 2464-bis. * Removed FCC informative references, because not used. o >>> Updated the affiliation of one author. o Reformulation of some >>> phrases for better readability, and correction of typographical >>> errors. >>> >>> Alex >>> >>> -------- Message transféré -------- >>> >>> *Sujet : * >>> >>> >>> >>> New Version Notification for >>> draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>> >>> *Date : * >>> >>> >>> >>> Sun, 10 Sep 2017 06:55:20 -0700 >>> >>> *De : * >>> >>> >>> >>> internet-drafts@ietf.org >>> > >>> >>> *Pour : * >>> >>> >>> >>> Nabil Benamar > >>> >, Christian >>> Huitema > >>> >, Jong-Hyouk >>> Lee > >>> >, Jérôme >>> Härri > >>> >, >>> Alexandre Petrescu >> > >>> >> >, Tony Li >> > >> >, Alexandre Petrescu >>> > >>> >> >, Jerome Haerri >>> > >>> >, >>> Thierry Ernst >> > >> >, ipwave-chairs@ietf.org >>> >> > >>> >>> A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>> >>> has been successfully submitted by Alexandre Petrescu and posted to >>> the >>> >>> IETF repository. >>> >>> Name: draft-ietf-ipwave-ipv6-over-80211ocb >>> >>> Revision: 05 >>> >>> Title: Transmission of IPv6 Packets over IEEE 802.11 >>> Networks operating in mode Outside the Context of a Basic Service >>> Set (IPv6-over-80211-OCB) >>> >>> Document date: 2017-09-10 >>> >>> Group: ipwave >>> >>> Pages: 37 >>> >>> >> > URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211oc >> b-05.txt >>> >>> >> > > 5.txt> >>> >>> >>> >>> >> > Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb >> / >>> >>> >> >>> >>> >>> >>> >> > Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05 >>> >>> >> >>> >>> >>> >>> >> > Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-8 >> 0211ocb-05 >>> >>> >> > > 05> >>> >>> >>> >>> >> > Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb- >> 05 >>> >>> >> > >>> >>> >>> Abstract: >>> >>> In order to transmit IPv6 packets on IEEE 802.11 networks run >>> outside >>> >>> the context of a basic service set (OCB, earlier "802.11p") there is >>> >>> a need to define a few parameters such as the supported Maximum >>> >>> Transmission Unit size on the 802.11-OCB link, the header format >>> >>> preceding the IPv6 header, the Type value within it, and others. >>> >>> This document describes these parameters for IPv6 and IEEE >>> 802.11-OCB >>> >>> networks; it portrays the layering of IPv6 on 802.11-OCB similarly >>> to >>> >>> other known 802.11 and Ethernet layers - by using an Ethernet >>> >>> Adaptation Layer. >>> >>> In addition, the document lists what is different in 802.11-OCB >>> >>> (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, >>> >>> where IPv6 protocols operate without issues. Most notably, the >>> >>> operation outside the context of a BSS (OCB) has impact on IPv6 >>> >>> handover behaviour and on IPv6 security. >>> >>> >>> >>> 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 >>> >>> >>> _______________________________________________ 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 >>> >>> >>> >>> >>> >>> -- >>> >>> >>> PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: >>> wwhyte@onboardsecurity.com >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Tue Sep 19 11:47:06 2017 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 27C0E134365 for ; Tue, 19 Sep 2017 11:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 iQVD8miq3KSe for ; Tue, 19 Sep 2017 11:47:02 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 DB205134366 for ; Tue, 19 Sep 2017 11:46:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8JIkk6U057150; Tue, 19 Sep 2017 20:46:46 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 278DE20E60A; Tue, 19 Sep 2017 20:46:46 +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 1A0F7201A90; Tue, 19 Sep 2017 20:46:46 +0200 (CEST) Received: from [132.166.84.160] ([132.166.84.160]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8JIkjHJ005125; Tue, 19 Sep 2017 20:46:45 +0200 To: dickroy@alum.mit.edu, its@ietf.org References: <2E8AAA2242ED4122B30FFE4C49BFF5E8@SRA6> <64f88cf4-685a-9dff-4a3a-a7a8cf771781@gmail.com> <523A387999DC4DC9AEFAFD678F282429@SRA6> From: Alexandre Petrescu Message-ID: <7be09fbe-8320-9434-4b53-a573bcb3f12b@gmail.com> Date: Tue, 19 Sep 2017 20:46:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <523A387999DC4DC9AEFAFD678F282429@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] correction X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 18:47:04 -0000 Le 19/09/2017 à 19:10, Dick Roy a écrit : > Yes, by all means. All of it is 1) subject to change, 2) way out of scope > for the IETF, and 3) totally irrelevant to the planned effort. Agreed. Alex > > RR > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Tuesday, September 19, 2017 4:45 AM > To: dickroy@alum.mit.edu; its@ietf.org > Subject: Re: [ipwave] correction > > So, should I remove this paragraph: > >> o Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB, >> as opposed to IPv6 not being prohibited on any channel on which >> 802.11a/b/g/n runs: >> >> * Some channels are reserved for safety communications; the IPv6 >> packets should not be sent on these channels. >> >> * At the time of writing, the prohibition is explicit at higher >> layer protocols providing services to the application; these >> higher layer protocols are specified in IEEE 1609 documents, >> i.e. the "WAVE" stack. >> >> * National or regional specifications and regulations specify the >> use of different channels; these regulations must be followed. > > Alex > > Le 19/09/2017 à 00:06, Dick Roy a écrit : >> Alex et.al., >> >> The simple fact is that how physical resources are to be used (aka "what >> apps are allowed on which channels") is a topic/issue way outside the > scope >> of the IETF's work. I highly recommend you make no statements on such >> issues nor make any recommendations along those lines. Stick to IPv6 >> networking and the network (and transport) layer functions required to >> implement it. Leave channel allocation issues to the appropriate entities >> ... the regulators and system integrators. >> >> MTC ... >> >> RR >> >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu >> Sent: Monday, September 18, 2017 5:00 AM >> To: its@ietf.org >> Subject: [ipwave] correction >> >> I know that some WG members already suggested that "IPv6 packets should > not >> be sent on the channels reserved for safety". >> >> 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 Wed Sep 20 07:44:11 2017 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 847FC132D51 for ; Wed, 20 Sep 2017 07:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5DorGgPYct4 for ; Wed, 20 Sep 2017 07:44:00 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 E27BE13214D for ; Wed, 20 Sep 2017 07:43:59 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id x54so2979974qth.12 for ; Wed, 20 Sep 2017 07:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=Lf0pMKPc2Z2sce24nanxuhAqYO4+i187P9ru7BOzo2A=; b=sCztjFO646u5ng3+FylslgcpJb7k64mQ/0a81Zp0c69r/PsL26Trj7ZFWRgFBRv7Lb wdv3S6M1rJWlqNIPTgSXagj+gHoakIBXM0Myvtj+z0BT/V/ZG4xPVs+Pos2QA1f+6EZp Vf/wUU8c5LSj8Tf3g4tt9DvrAomAYSS0tm8idPGTC5FO75nT9y4AJhAErTrFtVehjmXv jiWCgRxuSZC8egbK0y+cyH5WHDbf08rQ0H5JI6gY9zSiHnmN80eLgumRmlnjk2OCTxQ6 Cd4HMRiriOHem1DaZbK34OJ5S11VWiqbBL0DXa7c/8MVBy8Notpi4OpUJM9i++GB+bEl 3Baw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=Lf0pMKPc2Z2sce24nanxuhAqYO4+i187P9ru7BOzo2A=; b=SSeycCokJEcuwM19RlrcnT1jyIwKPm7sVCsR82BPRrYI0PDsnX5b8d1suOCxlVZlWm 0MjdAZBvXpfLeF7+n5KFCzxHCb93G7Sr9bHhbAgBEcQolrq6jt5P7BhG6CeOJHpHUTGs U84U0oazWK/nM3j5bT5AwBdDC0Hou2TnKnfo8zQs5Xg0Zu4isvLuZhyMBBHh28u7F/5v whqMh2SHM2InO2fMsl0es7qxo7oPgfvgOrHf7kbSpq0AsGw6Lii5lk3tTjR58/meoxUs TW39ewHw3BrcXlZpDoIE7PUdueqtMEn22lospl/36OPQMdKIU9TuDGCs6g38XTEkBbjK qBNg== X-Gm-Message-State: AHPjjUgg4rnE+u6hrRDUtwRn9U+u/e9t+i3N2efbNA4EIyHdtCD7fpY4 lULMnGt5lJ+ba7Vv6cE2UhU= X-Google-Smtp-Source: AOwi7QCdjuN0vxbdWqcaWeHTdwtZTnxmaZozbzfLOmgw45gM6/Oex5wCTjy5Qj65JQbFjZbooh4KPg== X-Received: by 10.200.45.91 with SMTP id o27mr7795391qta.319.1505918638491; Wed, 20 Sep 2017 07:43:58 -0700 (PDT) Received: from FrancoisPC (pool-108-56-236-157.washdc.fios.verizon.net. [108.56.236.157]) by smtp.gmail.com with ESMTPSA id z22sm1484176qti.36.2017.09.20.07.43.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 07:43:57 -0700 (PDT) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= Cc: , References: <150505172031.8046.10083602421074157775.idtracker@ietfa.amsl.com> <9addb061-ac19-cd48-8f63-800b83258041@gmail.com> <011101d32d3e$00cc7d20$02657760$@gmail.com> <75e59482-38b7-c1c7-a09d-67de78588ad4@gmail.com> <000d01d33075$13cd39c0$3b67ad40$@gmail.com> <7493ccf3-a782-c88d-552f-2a6d2cc7085b@gmail.com> <003d01d33152$c4482ca0$4cd885e0$@gmail.com> <025101d33158$c25352c0$46f9f840$@eurecom.fr> In-Reply-To: <025101d33158$c25352c0$46f9f840$@eurecom.fr> Date: Wed, 20 Sep 2017 10:43:56 -0400 Message-ID: <011f01d3321e$e3ba9560$ab2fc020$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0120_01D331FD.5CB37CB0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIukhOZsx60BumPZtxqsZkYmsT8+wFgJMjwAbp9UtkCl75/SwITd9gzAmE14w0Bqqau+gGy6hCAoZrXgTA= Archived-At: Subject: Re: [ipwave] -06 comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 14:44:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0120_01D331FD.5CB37CB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mr. Harri, =20 In the US 802.11-2016 OCB supports two 20 MHz channels in the 5.9 MHz = band; Service Channels 175 and 181. =20 In the US, the certification of products will require conformance to the = IEEE 802.11 standard which makes mandatory the support of 3, 6, and 12 = Mb/s for 10 MHz channel spacing and 6, 12, and 24 Mb/s for 20 MHz = channel spacing. =20 It is true that the maximum data rate for 10 MHz channel is 27 MHz. = However, the data rate / modulation has nothing to do with the content = of the PPDU data field. Each OFDM frame (PPDU) being transmitted, the 4 = LSB of the SIGNAL field must be set to the required data rate (i.e.; = 0x0101 =E2=80=93 QPSK R=3D1/2 for 6 Mbps for 10 MHz channel spacing). = One must not confuse data rate and throughput. =20 Ethertype for OCB =20 * The LLC provides multiplexing for several network protocols coexisting = within the network transported on the same medium. In the case of OCB, = 0x86DD for IPv6, 0x88DC for WSMP, etc. * The Ethertype identifies transport protocol; not application data = (i.e., BSM). A BSM data message transported in an IPv6 frame, IPv6 being = the transport protocol, would indeed be identified as Ethertype 0x86DD, = the same BSM being transported in a WSM would be identify by 0X88dDC. =20 =E2=80=9CNow the question is: Why would we need a new Ethertype if we do = plain IPv6-over-OCB=E2=80=A6Why would we need to differentiate at L3 OCB = from BSS/IBSS WiFi ? IPv6 header and packets are the same, only the = access technology changes, which is out of scope of IETF. Could we use = an IPv6 Profile to provide some traffic differentiation?=E2=80=9D =20 You are correct in respect of OCB is just an =E2=80=9Cadd-on=E2=80=9D to = BSS, IBSS, and WiFi. And yes the technology change is out of scope as = long that IPv6 use of the OCB services stays within the OCB constraints. =20 Sincerely, =20 Francois Simon =20 =20 From: J=C3=A9r=C3=B4me H=C3=A4rri [mailto:jerome.haerri@eurecom.fr]=20 Sent: Tuesday, September 19, 2017 11:06 AM To: 'Fran=C3=A7ois Simon' ; 'Alexandre Petrescu' = Cc: its@ietf.org Subject: RE: [ipwave] -06 comments =20 Dear Mr. Simon, =20 As far as I know, IEEE 802.11-2016 OCB is 10Mhz only. The 6Mbps is a = profile that is applied by WAVE and ETSI ITS but is out of scope of = IETF..we basically do not need to respect it (actually we should not, as = the tests showing the superior channel usage of 6Mps has been obtained = for fixed size BSM/CAM at constant Transmit Power and in Full Broadcast = mode)=E2=80=A6 =20 The only thing we can write there is that IEEE 802.11-2016 OCB has a = maximum capacity (theoretical bandwidth) of 27Mbps due to the 10Mhz = constraints=E2=80=A6finding the optimal modulation for IPv6 traffic = should be left open.=20 =20 For the Ethertype for OCB, it is important to differentiate what we mean = by IEEE.=20 =20 * IEEE 802.11 does not do it, and I would not understand why they would = need it, as OCB is clearly identified at LL by a wildcard BSSID as well = as ToDS and fromDS fields to set to 0.=20 =20 * IEEE 1609.x indeed proposed an Ethertype (used over the last decade if = I am not mistaken) for the WAVE stack (not BSM)..BSM use such ethertype = as they are not transmitted over IPv6 (or IPv4), but only because they = use a WAVE headers (and the WAVE non-IP stack). Would BSM be sent over = IPv6, they would most likely not use this ethertype.=20 * In EU, the ETSI followed a similar strategy for the GeoNet stack (the = Geonet headers)=E2=80=A6CAM use the GeoNet Ethertype but would most = likely not use it if CAM would be sent over plain IPv6.=20 =20 Now the question is: Why would we need a new Ethertype if we do plain = IPv6-over-OCB=E2=80=A6Why would we need to differentiate at L3 OCB from = BSS/IBSS WiFi ? IPv6 header and packets are the same, only the access = technology changes, which is out of scope of IETF. Could we use an IPv6 = Profile to provide some traffic differentiation?=20 =20 I understand there might be requirements at L3 to know that some of the = =E2=80=98assumed=E2=80=99 security mechanisms at 802.11 level be absent = (or that IPv6 ND would need to operate differently=E2=80=A6), and = therefore to adopt an alternative strategy=E2=80=A6I am just wondering = if an Ethertype is the right tool for this=E2=80=A6.Maybe some use cases = could we worth drawing and discussing.=20 =20 Best Regards, =20 J=C3=A9r=C3=B4me=20 =20 =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Fran=C3=A7ois Simon Sent: Tuesday 19 September 2017 16:23 To: 'Alexandre Petrescu' Cc: fygsimon@gmail.com ; its@ietf.org = =20 Subject: Re: [ipwave] -06 comments =20 Mr. Petrescu, Here are the answers to your questions. If you have additional questions, please, let me know. Sincerely, Francois Simon Lojik Technologies [Fygs: Only the US views are addressed here.] We received your comments and tried to resolve them. 1. This is the changelog that solves simple things. I invite you to look how they are solved in the new version, -07. o Added new terms: OBRU and RSRU ('R' for Router). Refined the existing terms RSU and OBU, which are no longer used throughout the document. o Improved definition of term "802.11-OCB". o Clarified that OCB does not "strip" security, but that the operation in OCB mode is "stripped off of all .11 security". o Clarified that theoretical OCB bandwidth speed is 54mbits, but that a commonly observed bandwidth in IP-over-OCB is 12mbit/s. [Fygs: Most of the =E2=80=9Ctrials=E2=80=9D have used 10 Mhz channel = spacing and 6 mbit/s] o Corrected typographical errors, and improved some phrasing. 2. I would like to ask you three questions: Do you know whether there is an EtherType allocated by IEEE for WAVE = messages? I noticed in packets BSM-over-802.11-OCB that the used type = is 0x88DC. Packet available upon request. This value is in LLC Header, = Type Field. It is understood by the Wireshark tool. But I dont see it = listed at IANA, IEEE 802 Numbers: https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml But on that page I do see 0x8947 for GeoNetworking and 0x86DD for IPv6. [Fygs: Reference http://standards-oui.ieee.org/ethertype/eth.txt : 0x88DC is the Ether type for WAVE WSMP assigned to IEEE 1609 WG = =E2=80=93 out of scope for IPWAVE =E2=80=93 IPv6 over OCB. 88dc - IEEE P1609 WG 3800 N Fairfax Drive #207, Arlington VA = 22203-1759 - Wireless Access in a Vehicle Environment (WAVE) Short = Message Protocol (WSM) as defined in IEEE P1609.3. =20 0x86DD is the Ether type for IPv6 assigned to the Internet Society. 86DD - USC/ISI 4676 Admiralty Way, Marina del Rey CA 90292 US - = Crawford, M. -=20 IPv6 - Internet Protocol Version 6 - Transmission of IPv6 Packets over = Ethernet Networks, RFC-2464, Internet Society, Dec. 1998 - = =20 Packets over Ethernet Networks, RFC-2464, Internet Society, Dec. =20 http://www.ietf.org/rfc/rfc2464.txt = = =20 =20 0x8947 is the Ether type for GeoNetworking assigned to ETSI. 8947 - ETSI 650 Route des lucioles, Sophia Antipolis 06921 FR - = = =20 GeoNetworking as defined in ETSI EN 302 636-4-1. Link to the protocol: = http://webapp.etsi.org/workprogram/Frame_WorkItemList.asp?SearchPage=3DTR= UE = = &qSORT=3DHIGHVERSION&qINCLUDE_SUB_TB=3DTrue&butSimple=3D++Search++&qETSI_= STANDARD_TYPE=3D&qETSI_NUMBER=3D302+636-4-1&qETSI_ALL=3DTRUE&qMILESTONE=3D= &qACHIEVED_DAY=3D&qACHIEVED_MONTH=3D&qACHIEVED_YEAR=3D&qREPORT_TYPE=3DSUM= MARY&optDisplay=3D10&qTB_ID=3D&includeNonActiveTB=3DFALSE] =20 Do you think this existing text is wrong?: > At the time of writing, the prohibition [of IPv6] is explicit at=20 > higher layer protocols providing services to the application; these=20 > higher layer protocols are specified in IEEE 1609 documents, i.e. > the "WAVE" stack. [Fygs: See comments below.] Finally, in your review, when you read the -06 text saying "Some = channels are reserved for safety communications; the IPv6 packets should = not be sent on these channels." you are commenting in your review that = "This assumes that Safety applications would not use IPv6; erroneous = assumption." My question is the following: do you want text deleted? Which one? Or is it just a comment? Know that some WG members already = suggested that "IPv6 packets should be sent on the channels reserved for = safety". [Fygs: Text from =E2=80=9Cversion 7=E2=80=9D:=20 =E2=80=9CProhibition of IPv6 on some channels relevant for IEEE = 802.11-OCB, as opposed to IPv6 not being prohibited on any channel on = which 802.11a/b/g/n runs: * Some channels are reserved for safety communications; the IPv6 packets should not be sent on these channels. * At the time of writing, the prohibition is explicit at higher layer protocols providing services to the application; these higher layer protocols are specified in IEEE 1609 documents, i.e. the "WAVE" stack. * National or regional specifications and regulations specify the use of different channels; these regulations must be followed. Any channels within the 5.9 GHz band can be used to exchange safety = applications data, except for the 5 MHz in the lower part of the band = which is =E2=80=9Creserved=E2=80=9D. However, FCC identify channels 172 = (33 dBm max. EIRP) and 184 (33/44 dBm max. EIRP) which are = =E2=80=9Cdesignated for public safety applications involving safety of = life and property.=E2=80=9D The national regulations (FCC =E2=80=93 47 = CFR) specify the channel use details but does not specify protocols. Since IPWAVE IPv6 over OCB is exclusively related to =E2=80=9CIPv6 = =E2=80=93 LLC=E2=80=9D Service Access Point (SAP) (above the OCB MAC), = there is no requirement to be compatible with the IEEE 1609 protocol = stack. Therefore, the prohibition is irrelevant and should not be = stated. LLC, IEEE 802.11, and FCC have no protocol restriction on any of = the channels of 5.9 GHz band]. It is recommended to delete this entire section (shown above) of the = document.] Alex -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] Sent: Monday, September 18, 2017 8:01 AM To: Fran=C3=A7ois Simon = > Subject: Re: -06 comments Mr. Simon, I just corrected my meessage, publicly. Please post publicly about this, and about the way we addressed all = other comments from your review. Alex =20 Le 18/09/2017 =C3=A0 13:55, Fran=C3=A7ois Simon a =C3=A9crit : > Mr. Petrescu, >=20 > I will answer the questions. Do you want the response CCed to the WG = members? If so re-send the e-mail with the following statement = corrected: " Know that some WG members already suggested that "IPv6 = packets should be sent on the channels reserved for safety" >=20 > Sincerely, >=20 > Fygs >=20 > -----Original Message----- > From: Alexandre Petrescu [ = mailto:alexandre.petrescu@gmail.com] > Sent: Sunday, September 17, 2017 2:29 PM > To: Fran=C3=A7ois Simon < = fygsimon@gmail.com> > Cc: its@ietf.org > Subject: Re: -06 comments >=20 > Mr. Simon, >=20 > We received your comments and tried to resolve them. >=20 > 1. This is the changelog that solves simple things. I invite you to > look how they are solved in the new version, -07. > o Added new terms: OBRU and RSRU ('R' for Router). Refined the > existing terms RSU and OBU, which are no longer used = throughout > the document. > o Improved definition of term "802.11-OCB". > o Clarified that OCB does not "strip" security, but that the > operation in OCB mode is "stripped off of all .11 security". > o Clarified that theoretical OCB bandwidth speed is 54mbits, but > that a commonly observed bandwidth in IP-over-OCB is 12mbit/s. > o Corrected typographical errors, and improved some phrasing. >=20 > 2. I would like to ask you three questions: >=20 > Do you know whether there is an EtherType allocated by IEEE for WAVE = messages? I noticed in packets BSM-over-802.11-OCB that the used type = is 0x88DC. Packet available upon request. This value is in LLC Header, = Type Field. It is understood by the Wireshark tool. But I dont see it = listed at IANA, IEEE 802 Numbers: > = = https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xht > ml But on that page I do see 0x8947 for GeoNetworking and 0x86DD for=20 > IPv6. >=20 > Do you think this existing text is wrong?: >> At the time of writing, the prohibition [of IPv6] is explicit at=20 >> higher layer protocols providing services to the application; these=20 >> higher layer protocols are specified in IEEE 1609 documents, i.e. >> the "WAVE" stack. >=20 >=20 > Finally, in your review, when you read the -06 text saying "Some = channels are reserved for safety communications; the IPv6 packets should = not be sent on these channels." you are commenting in your review that = "This assumes that Safety applications would not use IPv6; erroneous = assumption." My question is the following: do you want text deleted? > Which one? Or is it just a comment? Know that some WG members = already suggested that "IPv6 packets should be sent on the channels = reserved for safety". >=20 > Alex >=20 >=20 >=20 >=20 > Le 14/09/2017 =C3=A0 11:44, Fran=C3=A7ois Simon a =C3=A9crit : >> Mr. Petrescu, >>=20 >> Find attached comments on version 06 of the document. >>=20 >> Let me know if you have any questions. >>=20 >> Francois Yves Simon >>=20 >> Lojik Technologies >>=20 >> *From:*its [ = mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre=20 >> Petrescu *Sent:* Sunday, September 10, 2017 9:58 AM *To:*=20 >> its@ietf.org >> *Subject:* [ipwave] Fwd: New Version Notification for=20 >> draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>=20 >> Dear participants to IPWAVE WG, >>=20 >> This is the new IPv6-over-802.11-OCB addressing all the Reviewers=20 >> comments. >>=20 >> This is the ChangeLog: >>=20 >> o Lengthened the title and cleanded the abstract. o Added text=20 >> suggesting LLs may be easy to use on OCB, rather than GUAs based on=20 >> received prefix. o Added the risks of spoofing and hijacking. o=20 >> Removed the text speculation on adoption of the TSA message. o=20 >> Clarified that the ND protocol is used. o Clarified what it means "No = >> association needed". o Added some text about how two STAs discover=20 >> each other. o Added mention of external (OCB) and internal network=20 >> (stable), in the subnet structure section. o Added phrase explaining=20 >> that both .11 Data and .11 QoS Data headers are currently being used, = >> and may be used in the future. o Moved the packet capture example=20 >> into an Appendix Implementation Status. o Suggested moving the=20 >> reliability requirements appendix out into another document. o Added=20 >> a IANA Consiserations section, with content, requesting for a new=20 >> multicast group "all OCB interfaces". o Added new OBU term, improved=20 >> the RSU term definition, removed the ETTC term, replaced more=20 >> occurences of 802.11p, 802.11 OCB with 802.11-OCB. o References: *=20 >> Added an informational reference to ETSI=E2=80=99s IPv6-over- = GeoNetworking. >> * Added more references to IETF and ETSI security protocols. *=20 >> Updated some references from I-D to RFC, and from old RFC to new RFC = numbers. >> * Added reference to multicast extensions to IPsec architecture RFC.=20 >> * Added a reference to 2464-bis. * Removed FCC informative=20 >> references, because not used. o Updated the affiliation of one=20 >> author. o Reformulation of some phrases for better readability, and=20 >> correction of typographical errors. >>=20 >> Alex >>=20 >> -------- Message transf=C3=A9r=C3=A9 -------- >>=20 >> *Sujet : * >>=20 >>=20 >>=20 >> New Version Notification for >> draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>=20 >> *Date : * >>=20 >>=20 >>=20 >> Sun, 10 Sep 2017 06:55:20 -0700 >>=20 >> *De : * >>=20 >>=20 >>=20 >> internet-drafts@ietf.org < = mailto:internet-drafts@ietf.org> >>=20 >> *Pour : * >>=20 >>=20 >>=20 >> Nabil Benamar < benamar73@gmail.com> < = mailto:benamar73@gmail.com>,=20 >> Christian Huitema < huitema@huitema.net> = < mailto:huitema@huitema.net>,=20 >> Jong-Hyouk Lee < jonghyouk@smu.ac.kr> < = mailto:jonghyouk@smu.ac.kr>,=20 >> J=C3=A9r=C3=B4me H=C3=A4rri < = Jerome.Haerri@eurecom.fr>=20 >> < mailto:Jerome.Haerri@eurecom.fr>, = Alexandre Petrescu=20 >> < Alexandre.Petrescu@cea.fr> < = mailto:Alexandre.Petrescu@cea.fr>, = Tony=20 >> Li < tony.li@tony.li> < = mailto:tony.li@tony.li>, Alexandre Petrescu=20 >> < alexandre.petrescu@cea.fr> < = mailto:alexandre.petrescu@cea.fr>, >> Jerome Haerri < = jerome.haerri@eurecom.fr>=20 >> < mailto:jerome.haerri@eurecom.fr>, = Thierry Ernst=20 >> < thierry.ernst@yogoko.fr> < = mailto:thierry.ernst@yogoko.fr>,=20 >> ipwave-chairs@ietf.org < = mailto:ipwave-chairs@ietf.org> >>=20 >> A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt >>=20 >> has been successfully submitted by Alexandre Petrescu and posted to=20 >> the >>=20 >> IETF repository. >>=20 >> Name: draft-ietf-ipwave-ipv6-over-80211ocb >>=20 >> Revision: 05 >>=20 >> Title: Transmission of IPv6 Packets over IEEE 802.11 Networks >> operating in mode Outside the Context of a Basic Service Set >> (IPv6-over-80211-OCB) >>=20 >> Document date: 2017-09-10 >>=20 >> Group: ipwave >>=20 >> Pages: 37 >>=20 >> = = URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over- >> 8 >> 0211ocb-05.txt >>=20 >> =20 >> Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-8 >> 0 >> 211ocb/ >>=20 >> =20 >> Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-8021 >> 1 >> ocb-05 >>=20 >> =20 >> Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6 >> - >> over-80211ocb-05 >>=20 >> =20 >> = Diff:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80 >> 2 >> 11ocb-05 >>=20 >> Abstract: >>=20 >> In order to transmit IPv6 packets on IEEE 802.11 networks run outside >>=20 >> the context of a basic service set (OCB, earlier "802.11p") there is >>=20 >> a need to define a few parameters such as the supported Maximum >>=20 >> Transmission Unit size on the 802.11-OCB link, the header format >>=20 >> preceding the IPv6 header, the Type value within it, and others. >>=20 >> This document describes these parameters for IPv6 and IEEE 802.11-OCB >>=20 >> networks; it portrays the layering of IPv6 on 802.11-OCB similarly to >>=20 >> other known 802.11 and Ethernet layers - by using an Ethernet >>=20 >> Adaptation Layer. >>=20 >> In addition, the document lists what is different in 802.11-OCB >>=20 >> (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, >>=20 >> where IPv6 protocols operate without issues. Most notably, the >>=20 >> operation outside the context of a BSS (OCB) has impact on IPv6 >>=20 >> handover behaviour and on IPv6 security. >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission >>=20 >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 ------=_NextPart_000_0120_01D331FD.5CB37CB0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RE: -06 comments

Mr. = Harri,

 

In the US = 802.11-2016 OCB supports two 20 MHz channels in the 5.9 MHz band; = Service Channels 175 and 181.

 

In the US, = the certification of products will require conformance to the IEEE = 802.11 standard which makes mandatory the support of 3, 6, and 12 = Mb/s for 10 MHz channel spacing and 6, 12, and 24 Mb/s for 20 MHz = channel spacing.

 

It is true = that the maximum data rate for 10 MHz channel is 27 MHz. = =C2=A0=C2=A0However, the data rate / modulation has nothing to do with = the content of the PPDU data = field. Each OFDM = frame (PPDU) being transmitted, the 4 LSB of the SIGNAL field must be = set to the required data rate (i.e.; 0x0101 =E2=80=93 QPSK R=3D1/2 for 6 = Mbps for 10 MHz channel spacing).=C2=A0 One must not confuse data rate = and throughput.

 

Ethertype = for OCB

 

  • The LLC = provides multiplexing for several network protocols coexisting within = the network transported on the same medium. In the case of OCB, = 0x86DD for = IPv6, 0x88DC for WSMP, etc.
  • The = Ethertype identifies transport protocol; not application data (i.e., = BSM). A BSM data message transported in an IPv6 frame, IPv6 being the = transport protocol, would indeed be identified as Ethertype 0x86DD, the = same BSM being transported in a WSM would be identify by = 0X88dDC.

 

=E2=80=9CNow the question is: Why would we need a new Ethertype if we do plain = IPv6-over-OCB=E2=80=A6Why would we need to differentiate at L3 OCB from = BSS/IBSS WiFi ? IPv6 header and packets are the same, only the access = technology changes, which is out of scope of IETF. Could we use an IPv6 = Profile to provide some traffic = differentiation?=E2=80=9D

 

You are = correct in respect of OCB is just an =E2=80=9Cadd-on=E2=80=9D to BSS, = IBSS, and WiFi. And yes the technology change is out of scope as long = that IPv6 use of the OCB services stays within the OCB = constraints.

 

Sincerely,

 

Francois = Simon

 

 

From:<= /b> = J=C3=A9r=C3=B4me H=C3=A4rri [mailto:jerome.haerri@eurecom.fr] =
Sent: Tuesday, September 19, 2017 11:06 AM
To: = 'Fran=C3=A7ois Simon' <fygsimon@gmail.com>; 'Alexandre Petrescu' = <alexandre.petrescu@gmail.com>
Cc: = its@ietf.org
Subject: RE: [ipwave] -06 = comments

 

Dear Mr. Simon,

 

As far as I know, IEEE 802.11-2016 OCB is 10Mhz only. The 6Mbps is a = profile that is applied by WAVE and ETSI ITS but is out of scope of = IETF..we basically do not need to respect it (actually we should not, as = the tests showing the superior channel usage of 6Mps has been obtained = for fixed size BSM/CAM at constant Transmit Power and in Full Broadcast = mode)=E2=80=A6

 

The only thing we can write there is that IEEE 802.11-2016 OCB has a = maximum capacity (theoretical bandwidth) of 27Mbps due to the 10Mhz = constraints=E2=80=A6finding the optimal modulation for IPv6 traffic = should be left open.

 

For the Ethertype for OCB, it is important to differentiate what we = mean by IEEE.

 

  • IEEE 802.11 = does not do it, and I would not understand why they would need it, as = OCB is clearly identified at LL by a wildcard BSSID as well as ToDS and = fromDS fields to set to 0.

 

  • IEEE 1609.x = indeed proposed an Ethertype (used over the last decade if I am not = mistaken) for the WAVE stack (not BSM)..BSM use such ethertype as they = are not transmitted over IPv6 (or IPv4), but only because they use a = WAVE headers (and the WAVE non-IP stack). Would BSM be sent over IPv6, = they would most likely not use this ethertype. =
    • In EU, the = ETSI followed a similar strategy for the GeoNet stack (the Geonet = headers)=E2=80=A6CAM use the GeoNet Ethertype but would most likely not = use it if CAM would be sent over plain IPv6. =

 

Now the question is: Why would we need a new Ethertype if we do plain = IPv6-over-OCB=E2=80=A6Why would we need to differentiate at L3 OCB from = BSS/IBSS WiFi ? IPv6 header and packets are the same, only the access = technology changes, which is out of scope of IETF. Could we use an IPv6 = Profile to provide some traffic differentiation? =

 

I understand there might be requirements at L3 to know that some of the = =E2=80=98assumed=E2=80=99 security mechanisms at 802.11 level be absent = (or that IPv6 ND would need to operate differently=E2=80=A6), and = therefore to adopt an alternative strategy=E2=80=A6I am just wondering = if an Ethertype is the right tool for this=E2=80=A6.Maybe some use cases = could we worth drawing and discussing.

 

Best Regards,

 

J=C3=A9r=C3=B4me

 

 

 

From: its = [mailto:its-bounces@ietf.org] = On Behalf Of Fran=C3=A7ois Simon
Sent: Tuesday 19 = September 2017 16:23
To: 'Alexandre Petrescu'
Cc: fygsimon@gmail.com; its@ietf.org
Subject: Re: = [ipwave] -06 comments

 

Mr. = Petrescu,

Here are the answers to your = questions.

If you have additional = questions, please, let me know.

Sincerely,

Francois = Simon

Lojik = Technologies

[Fygs: Only the US views are = addressed here.]

We received your comments and = tried to resolve them.

1. This is the changelog that = solves simple things.  I invite you = to

    look how = they are solved in the new version, -07.

    o  = Added new terms: OBRU and RSRU ('R' for Router).  Refined = the

     =   existing terms RSU and OBU, which are no longer used = throughout

     =   the document.

    o  = Improved definition of term = "802.11-OCB".

    o  = Clarified that OCB does not "strip" security, but that = the

     =   operation in OCB mode is "stripped off of all .11 = security".

    o  = Clarified that theoretical OCB bandwidth speed is 54mbits, = but

     =   that a commonly observed bandwidth in IP-over-OCB is = 12mbit/s.

[Fygs: Most of the = =E2=80=9Ctrials=E2=80=9D have used 10 Mhz channel spacing and 6 = mbit/s]

    o  = Corrected typographical errors, and improved some = phrasing.

2. I would like to ask you = three questions:

Do you know whether there is = an EtherType allocated by IEEE for WAVE messages?  I noticed in = packets BSM-over-802.11-OCB that the used type is 0x88DC.  Packet = available upon request.  This value is in LLC Header, Type = Field.  It is understood by the Wireshark tool.  But I dont = see it listed at IANA, IEEE 802 Numbers:

https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbe= rs.xhtml

But on that page I do see = 0x8947 for GeoNetworking and 0x86DD for = IPv6.

[Fygs: Reference http://standards= -oui.ieee.org/ethertype/eth.txt = :

0x88DC is the Ether type for = WAVE WSMP assigned to IEEE 1609 WG =E2=80=93 out of scope for IPWAVE = =E2=80=93 IPv6 over OCB.

88dc  = -  IEEE = P1609 WG   3800 N Fairfax Drive #207, Arlington VA  = 22203-1759   -  Wireless Access in a Vehicle = Environment (WAVE) Short Message Protocol (WSM) as defined in IEEE = P1609.3.

 

0x86DD is the Ether type for = IPv6 assigned to the Internet = Society.

86DD - USC/ISI 4676 Admiralty = Way, Marina del Rey  CA  90292 US - Crawford, M. - =

IPv6 - Internet Protocol = Version 6 - Transmission of IPv6 Packets over Ethernet Networks, = RFC-2464, Internet Society, Dec. 1998 = -            =             &= nbsp;           &n= bsp;

Packets over Ethernet = Networks, RFC-2464, Internet Society, = Dec.        =

http://www.ietf.org/rfc/rfc2= 464.txt          &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              =

     =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;     

0x8947 is the Ether type for = GeoNetworking assigned to ETSI.

8947  = -  ETSI 650 Route des lucioles, = Sophia Antipolis 06921 FR  -      =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;

GeoNetworking as defined in = ETSI EN 302 636-4-1.

Link to the protocol: http://webapp.etsi.o= rg/workprogram/Frame_WorkItemList.asp?SearchPage=3DTRUE&qSORT=3DHIGHV= ERSION&qINCLUDE_SUB_TB=3DTrue&butSimple=3D++Search++&qETSI_ST= ANDARD_TYPE=3D&qETSI_NUMBER=3D302+636-4-1&qETSI_ALL=3DTRUE&qM= ILESTONE=3D&qACHIEVED_DAY=3D&qACHIEVED_MONTH=3D&qACHIEVED_YEA= R=3D&qREPORT_TYPE=3DSUMMARY&optDisplay=3D10&qTB_ID=3D&inc= ludeNonActiveTB=3DFALSE]     =          =

Do you think this existing = text is wrong?:

> At the time of writing, = the prohibition [of IPv6] is explicit at

> higher layer protocols = providing services to the application; these =

> higher layer protocols = are specified in IEEE 1609 documents, i.e.

> the "WAVE" = stack.

[Fygs: See comments = below.]

Finally, in your review, when = you read the -06 text saying "Some channels are reserved for safety = communications; the IPv6 packets should not be sent on these = channels." you are commenting in your review that "This = assumes that Safety applications would not use IPv6; erroneous = assumption."  My question is the following: do you want text = deleted?

Which one?  Or is it = just a comment?  Know that some WG members already suggested that = "IPv6 packets should be sent on the channels reserved for = safety".

[Fygs: Text from = =E2=80=9Cversion 7=E2=80=9D:

=E2=80=9CProhibition of = IPv6 on some channels relevant for IEEE 802.11-OCB, as opposed to IPv6 = not being prohibited on any channel on = which

802.11a/b/g/n = runs:

     = *  Some channels are reserved for safety communications; the = IPv6

     =     packets should not be sent on these = channels.

     = *  At the time of writing, the prohibition is explicit at = higher

     =     layer protocols providing services to the = application; these

     =     higher layer protocols are specified in IEEE 1609 = documents,

     =     i.e. the "WAVE" = stack.

     = *  National or regional specifications and regulations specify = the

     =     use of different channels; these regulations must be = followed.

=  Any channels = within the 5.9 GHz band can be used to exchange safety applications = data, except for the 5 MHz in the lower part of the band which is = =E2=80=9Creserved=E2=80=9D.  However, FCC identify channels 172 (33 = dBm max. EIRP) and 184 (33/44 dBm max. EIRP) which are = =E2=80=9Cdesignated for public safety applications involving safety = of life and property.=E2=80=9D The national regulations (FCC = =E2=80=93 47 CFR) specify the channel use details but does not specify = protocols.

Since IPWAVE IPv6 over OCB is = exclusively related to =E2=80=9CIPv6 =E2=80=93 LLC=E2=80=9D Service = Access Point (SAP) (above the OCB MAC), there is no requirement to be = compatible with the IEEE 1609 protocol stack.  Therefore, the = prohibition is irrelevant and should not be stated. LLC, IEEE 802.11, = and FCC have no protocol restriction on any of the channels of 5.9 GHz = band].

It is recommended to delete = this entire section (shown above) of the = document.]

Alex

<= span style=3D'font-family:"Calibri",sans-serif'>-----Original = Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gm= ail.com]
Sent: Monday, September 18, 2017 8:01 AM
To: = Fran=C3=A7ois Simon <fygsimon@gmail.com>
Subject:= Re: -06 comments

Mr. = Simon,

I just corrected my meessage, = publicly.

Please post publicly about = this, and about the way we addressed all other comments from your = review.

Alex

 

Le 18/09/2017 =C3=A0 13:55, = Fran=C3=A7ois Simon a =C3=A9crit :

> Mr. = Petrescu,

> =

> I will answer the = questions.  Do you want the response CCed to the WG members?  = If so re-send the e-mail with the following statement corrected: " = Know that some WG members already suggested that "IPv6 packets = should be sent on the channels reserved for = safety"

> =

> = Sincerely,

> =

> = Fygs

> =

> -----Original = Message-----

> From: Alexandre Petrescu = [mailto:alexandre.petrescu@gmai= l.com]

> Sent: Sunday, = September 17, 2017 2:29 PM

> To: Fran=C3=A7ois Simon = <fygsimon@gmail.com<= span = style=3D'font-family:"Calibri",sans-serif'>>

<= span style=3D'font-family:"Calibri",sans-serif'>> Cc: its@ietf.org

> = Subject: Re: -06 comments

> =

> Mr. = Simon,

> =

> We received your = comments and tried to resolve them.

> =

> 1. This is the changelog = that solves simple things.  I invite you = to

>    &n= bsp; look how they are solved in the new version, = -07.

>    &n= bsp; o  Added new terms: OBRU and RSRU ('R' for Router).  = Refined the

>    &n= bsp;    existing terms RSU and OBU, which are no longer = used throughout

>    &n= bsp;    the document.

>    &n= bsp; o  Improved definition of term = "802.11-OCB".

>    &n= bsp; o  Clarified that OCB does not "strip" security, but = that the

>    &n= bsp;    operation in OCB mode is "stripped off of = all .11 security".

>    &n= bsp; o  Clarified that theoretical OCB bandwidth speed is 54mbits, = but

>    &n= bsp;    that a commonly observed bandwidth in IP-over-OCB = is 12mbit/s.

>    &n= bsp; o  Corrected typographical errors, and improved some = phrasing.

> =

> 2. I would like to ask = you three questions:

> =

> Do you know whether = there is an EtherType allocated by IEEE for WAVE messages?  I = noticed in packets BSM-over-802.11-OCB that the used type is = 0x88DC.  Packet available upon request.  This value is in LLC = Header, Type Field.  It is understood by the Wireshark tool.  = But I dont see it listed at IANA, IEEE 802 = Numbers:

> https://www.iana.org/assignmen= ts/ieee-802-numbers/ieee-802-numbers.xht

> ml But on that page I = do see 0x8947 for GeoNetworking and 0x86DD for =

> = IPv6.

> =

> Do you think this = existing text is wrong?:

>> At the time of = writing, the prohibition [of IPv6] is explicit at =

>> higher layer = protocols providing services to the application; these =

>> higher layer = protocols are specified in IEEE 1609 documents, = i.e.

>> the "WAVE" = stack.

> =

> =

> Finally, in your review, = when you read the -06 text saying "Some channels are reserved for = safety communications; the IPv6 packets should not be sent on these = channels." you are commenting in your review that "This = assumes that Safety applications would not use IPv6; erroneous = assumption."  My question is the following: do you want text = deleted?

> Which one?  Or is = it just a comment?  Know that some WG members already suggested = that "IPv6 packets should be sent on the channels reserved for = safety".

> =

> = Alex

> =

> =

> =

> =

> Le 14/09/2017 =C3=A0 = 11:44, Fran=C3=A7ois Simon a =C3=A9crit :

>> Mr. = Petrescu,

>> 

>> Find = attached comments on version 06 of the = document.

>> 

>> Let = me know if you have any questions.

>> 

>> = Francois Yves Simon

>> 

>> Lojik = Technologies

>> 

>> = *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of = *Alexandre

>> Petrescu *Sent:* = Sunday, September 10, 2017 9:58 AM *To:*

>> its@ietf.org

>> = *Subject:* [ipwave] Fwd: New Version Notification for =

>> = draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

>> 

>> Dear = participants to IPWAVE WG,

>> 

>> This = is the new IPv6-over-802.11-OCB addressing all the Reviewers =

>> = comments.

>> 

>> This = is the ChangeLog:

>> 

>> o = Lengthened the title and cleanded the abstract. o Added text =

>> suggesting LLs may = be easy to use on OCB, rather than GUAs based on =

>> received prefix. o = Added the risks of spoofing and hijacking. o =

>> Removed the text = speculation on adoption of the TSA message. o =

>> Clarified that the = ND protocol is used. o Clarified what it means "No =

>> association = needed". o Added some text about how two STAs discover =

>> each other. o Added = mention of external (OCB) and internal network =

>> (stable), in the = subnet structure section. o Added phrase explaining =

>> that both .11 Data = and .11 QoS Data headers are currently being used, =

>> and may be used in = the future. o Moved the packet capture example =

>> into an Appendix = Implementation Status. o Suggested moving the =

>> reliability = requirements appendix out into another document. o Added =

>> a IANA = Consiserations section, with content, requesting for a new =

>> multicast group = "all OCB interfaces". o Added new OBU term, improved =

>> the RSU term = definition, removed the ETTC term, replaced more =

>> occurences of = 802.11p, 802.11 OCB with 802.11-OCB. o References: * =

>> Added an = informational reference to ETSI=E2=80=99s IPv6-over- = GeoNetworking.

>> * Added more = references to IETF and ETSI security protocols. * =

>> Updated some = references from I-D to RFC, and from old RFC to new RFC = numbers.

>> * Added reference to = multicast extensions to IPsec architecture RFC. =

>> * Added a reference = to 2464-bis. * Removed FCC informative

>> references, because = not used. o Updated the affiliation of one =

>> author. o = Reformulation of some phrases for better readability, and =

>> correction of = typographical errors.

>> 

>> = Alex

>> 

>> = -------- Message transf=C3=A9r=C3=A9 = --------

>> 

>> = *Sujet : *

>> 

>> 

>> 

>> New = Version Notification for

>> = draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

>> 

>> *Date = : *

>> 

>> 

>> 

>> Sun, = 10 Sep 2017 06:55:20 -0700

>> 

>> *De : = *

>> 

>> 

>> 

>> internet-drafts@ietf.org <mailto:internet-drafts@ietf.or= g>

<= span = style=3D'font-family:"Calibri",sans-serif'>>> 

>> *Pour = : *

>> 

>> 

>> 

>> Nabil = Benamar <benamar73@gmail.com= > <mailto:benamar73@gmail.com>, =

>> Christian Huitema = <huitema@huitema.net= > <mailto:huitema@huitema.net>, =

>> Jong-Hyouk Lee = <jonghyouk@smu.ac.kr= > <mailto:jonghyouk@smu.ac.kr>, =

>> J=C3=A9r=C3=B4me = H=C3=A4rri <Jerome.Haerri@eurecom.fr> =

>> <mailto:Jerome.Haerri@eurecom.f= r>, = Alexandre Petrescu

>> <Alexandre.Petrescu@cea.fr> = <mailto:Alexandre.Petrescu@cea.= fr>, Tony =

>> Li <tony.li@tony.li> <mailto:tony.li@tony.li<= /a>>, Alexandre = Petrescu

>> <alexandre.petrescu@cea.fr> = <mailto:alexandre.petrescu@cea.= fr>,

= >> Jerome Haerri = <jerome.haerri@eurecom.fr> =

>> <mailto:jerome.haerri@eurecom.f= r>, = Thierry Ernst

>> <thierry.ernst@yogoko.fr= > <mailto:thierry.ernst@yogoko.fr= >, =

>> ipwave-chairs@ietf.org<= /a> <mailto:ipwave-chairs@ietf.org<= /span>>

<= span = style=3D'font-family:"Calibri",sans-serif'>>> 

>> A new = version of I-D, = draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

>> 

>> has = been successfully submitted by Alexandre Petrescu and posted to =

>> = the

>> 

>> IETF = repository.

>> 

>> = Name:          = draft-ietf-ipwave-ipv6-over-80211ocb

>> 

>> = Revision:      05

>> 

>> = Title:         Transmission of = IPv6 Packets over IEEE 802.11 Networks

>> operating in mode = Outside the Context of a Basic Service Set

>> = (IPv6-over-80211-OCB)

>> 

>> = Document date: 2017-09-10

>> 

>> = Group:         = ipwave

>> 

>> = Pages:         = 37

>> 

>> URL:https://www.ietf.org/inter= net-drafts/draft-ietf-ipwave-ipv6-over-

>> = 8

>> = 0211ocb-05.txt

>> 

>>   =

>> Status:h= ttps://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-8<= o:p>

>> = 0

>> = 211ocb/

>> 

>>   =

>> Htmlized:htt= ps://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-8021=

>> = 1

>> = ocb-05

>> 

>>   =

>> Htmlized:htt= ps://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6=

>> = -

>> = over-80211ocb-05

>> 

>>   =

>> Diff:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80=

>> = 2

>> = 11ocb-05

>> 

>>   = Abstract:

>> 

>> In = order to transmit IPv6 packets on IEEE 802.11 networks run = outside

>> 

>> the = context of a basic service set (OCB, earlier "802.11p") there = is

>> 

>> a = need to define a few parameters such as the supported = Maximum

>> 

>> = Transmission Unit size on the 802.11-OCB link, the header = format

>> 

>> = preceding the IPv6 header, the Type value within it, and = others.

>> 

>> This = document describes these parameters for IPv6 and IEEE = 802.11-OCB

>> 

>> = networks; it portrays the layering of IPv6 on 802.11-OCB similarly = to

>> 

>> other = known 802.11 and Ethernet layers - by using an = Ethernet

>> 

>> = Adaptation Layer.

>> 

>> In = addition, the document lists what is different in = 802.11-OCB

>> 

>> = (802.11p) links compared to more 'traditional' 802.11a/b/g/n = links,

>> 

>> where = IPv6 protocols operate without issues.  Most notably, = the

>> 

>> = operation outside the context of a BSS (OCB) has impact on = IPv6

>> 

>> = handover behaviour and on IPv6 security.

>> 

>> 

>> 

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

>> 

> =

------=_NextPart_000_0120_01D331FD.5CB37CB0-- From nobody Wed Sep 20 09:04:49 2017 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 F0D1213300C for ; Wed, 20 Sep 2017 09:04: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 K4RhWt3-Nxbw for ; Wed, 20 Sep 2017 09:04:41 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001: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 E643F133090 for ; Wed, 20 Sep 2017 09:04:40 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id e189so4661683ioa.4 for ; Wed, 20 Sep 2017 09:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ynQ/6Ahe4pTzszhb1Vu8SqNQUD4xe71mkAQoDgAS7lU=; b=Ji60yvXeIusnhvmiwiwYirlBr7IT+MQGIIwMRYnP0H1Atw3Ir5Rfc5an1QW7LUD516 y7rLCwF/NXK0lafhs9yVjyAwoyBTlVhcj8LYzpmd9XNcDxzS2Uwzk5Y+9OyQv6FyUTr6 8Ird6ec4VKhkyGOjmxy4PLV7QcDtFfN6CMB0BFkC1vF5XIQhkKMeNkWBnH+Bk5kltKji Dn7UtOcFIebAQSoEkcqUlKGiRjk+AT9Ym8NF/xLkMu6bpHK1kGJKJIJp+D7uunJKB3Q8 drH84m78+V9SjMQTytt6EqtzfVdhUlYRonMdSD3hwmdwtkpTWTdkCL+C9xix/8i6DhH5 dUVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ynQ/6Ahe4pTzszhb1Vu8SqNQUD4xe71mkAQoDgAS7lU=; b=X08NEJ+lDhZXKhAOJ9LSBC5rNlgPaviFBrFpvyrXX4RH1YH0Ozkhqi5zT1MWxRgHyx swt/gJM6POmoD5HyfC8IuNhyvhBfaFb0BBtmtFhhUfF6/qJ1+F+/LxO/8Ns7KwGsxHmp t7Am3FKagjIRhZIO3TO4vbTZEskAWGz32xybNJa3WAPZTXA9pIAvAAKJ8f0qLUur3L/g 8I7AmpLspn9zwBtqlN0CcSdZQ2yOmntbsmgAw/J18Tj7nS09WiNPoZGPTWahKqTIWTDn /rx1kT35nFveHxFPRMnDX5owXuG6YOrbV7NbBjMmDlAkfLVJ5dlhsm01KS9S7qziP4nk LIQA== X-Gm-Message-State: AHPjjUhEtqacgWcEKE/cMrVpITVYi6Np/QffeCqx4NrpCMu4KUP2fVPm SrQ5LocJDdM6pcSYxveFe/GkRNLYAN2TfTsu8Cs= X-Google-Smtp-Source: AOwi7QAZkWuOotPGBRUCl7E2Y5pVVmIfYCKYciV74q6u1sfV+bBdiCtS9EziYLHAYmlF51cnmzZjsl7qxInR3C4BHz0= X-Received: by 10.202.63.132 with SMTP id m126mr6646478oia.137.1505923480135; Wed, 20 Sep 2017 09:04:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.20.66 with HTTP; Wed, 20 Sep 2017 09:04:39 -0700 (PDT) In-Reply-To: References: <2E8AAA2242ED4122B30FFE4C49BFF5E8@SRA6> <64f88cf4-685a-9dff-4a3a-a7a8cf771781@gmail.com> From: Abdussalam Baryun Date: Wed, 20 Sep 2017 18:04:39 +0200 Message-ID: To: Alexandre Petrescu , dickroy@alum.mit.edu, its Content-Type: multipart/alternative; boundary="001a113d660a17adf40559a122fc" Archived-At: Subject: Re: [ipwave] correction X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 16:04:48 -0000 --001a113d660a17adf40559a122fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex and the authors of other emails included, My comments and discussion below On Tue, Sep 19, 2017 at 1:44 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > So, should I remove this paragraph: > > o Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB, >> as opposed to IPv6 not being prohibited on any channel on which >> 802.11a/b/g/n runs: >> >> * Some channels are reserved for safety communications; the IPv6 >> packets should not be sent on these channels. >> >> * At the time of writing, the prohibition is explicit at higher >> layer protocols providing services to the application; these >> higher layer protocols are specified in IEEE 1609 documents, >> i.e. the "WAVE" stack. >> >> * National or regional specifications and regulations specify the >> use of different channels; these regulations must be followed. >> > > Alex > you can remove but not sure did WG agree on that, > > Le 19/09/2017 =C3=A0 00:06, Dick Roy a =C3=A9crit : > >> Alex et.al., >> >> The simple fact is that how physical resources are to be used (aka "what >> apps are allowed on which channels") is a topic/issue way outside the >> scope >> of the IETF's work. > > I don't agree with Dick Roy. The problem with the past IPv4 protocols is just that approach, we are in the future of IPv6, we need to look into future systems and protocols that use IPv6. > I highly recommend you make no statements on such >> issues nor make any recommendations along those lines. > > I think that is clean idea for now, however, we may need to make few conditions. > Stick to IPv6 >> networking and the network (and transport) layer functions required to >> implement it. Leave channel allocation issues to the appropriate entiti= es >> ... the regulators and system integrators. >> > The problem is that our system is not always TCP/IP model layers that was IPv4 systems. IMO IPWAVE systems are more complicated and have cross layers (I think we should not stick to one system layer model and separate IPv6 networking). >From your statement you want us to stick to old approach of system design, but we need new for our protocols of IPv6. So I recommend we don't stick to old IP networking because IPv6 is new and is future work. However, IMHO if this WG takes your approach we may need in future to change our specifications. Nothing is wrong with channel allocation in IETF we should be able to do that as well. We can regulate any of our protocols within any channel we agree on (if not please tell me what restricts us or what RFC stops us from such regulation) because the packet is our protocol. No one can own the channel but we own the IPv6 specification, and we can say which is recommended (usually for the best benefit of users not regulators). > >> MTC ... >> >> RR >> >> Le 19/09/2017 =C3=A0 19:10, Dick Roy a =C3=A9crit : > Yes, by all means. All of it is 1) subject to change, 2) way out of scop= e > for the IETF, and 3) totally irrelevant to the planned effort. > 1) Yes everything can change in future when we need it 2) I don't think channel allocation for IPWAVE is out of scope for IETF, because we already have cooperations between IEEE and IETF, so now things change regulators around the world are working together to find best solutions for best systems and best utilizations. IMHO, IPWAVE systems including channels are not out of scope for IETF, we work together (regulators because they don't own IPv6 protocols) with others without layers or abstractions or separations. 3) No, I think it can be totally relevant if WG says so, but if WG don't want to think out of the box then yes it is not relevant to WG effort. Best Regards --001a113d660a17adf40559a122fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Hi Alex and the au= thors of other emails included,

My comments and di= scussion=C2=A0below


=
On Tue, Sep 19, 2= 017 at 1:44 PM, Alexandre Petrescu <alexandre.petrescu@gmail.co= m> wrote:
So, should I remove this paragr= aph:

=C2=A0 =C2=A0o=C2=A0 Prohibition of IPv6 on so= me channels relevant for IEEE 802.11-OCB,
=C2=A0 =C2=A0 =C2=A0 as oppos= ed to IPv6 not being prohibited on any channel on which
=C2=A0 =C2=A0 = =C2=A0 802.11a/b/g/n runs:

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 Some channe= ls are reserved for safety communications; the IPv6
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0packets should not be sent on these channels.

=C2= =A0 =C2=A0 =C2=A0 *=C2=A0 At the time of writing, the prohibition is explic= it at higher
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0layer protocols providin= g services to the application; these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= higher layer protocols are specified in IEEE 1609 documents,
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0i.e. the "WAVE" stack.

=C2=A0 =C2= =A0 =C2=A0 *=C2=A0 National or regional specifications and regulations spec= ify the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use of different channels; th= ese regulations must be followed.

Alex

you can remove but not sure did WG agree on tha= t,
=C2=A0

Le = 19/09/2017 =C3=A0 00:06, Dick Roy a =C3=A9crit=C2=A0:
= Alex et.al.,

The simple fact is that how physical resources are to be used = (aka "what
apps are allowed on which channels") is a topic/is= sue way outside the scope
of the IETF's work.=C2=A0

I don't agree with Dick Roy. The problem= with the past IPv4 protocols is just that approach, we are in the future o= f IPv6, we need to look into future systems and protocols that use IPv6.=C2=A0
I highly recommend you make no statements on such=
issues nor make any recommendations along those lines.=C2=A0

I think that is clean idea for n= ow, however, we may need to make=C2=A0few conditions.
=C2=A0
Stick to IPv6<= br> networking and the network (and transport) layer functions required to<= br> implement it.=C2=A0 Leave channel allocation issues to the appropriate = entities
... the regulators and system integrators.

The problem is that our system is not = always TCP/IP model layers that was IPv4 systems.=C2=A0IMO =C2=A0IPWAVE sys= tems are more complicated and have cross layers=C2=A0(I think we should not= stick to one system layer model and separate IPv6 networking).
<= br>
From your statement you want us to stick to old approach of s= ystem design, but=C2=A0we need new for our protocols of IPv6. So I recommen= d we don't stick to old IP networking because IPv6 is new and is future= work. However, IMHO if this WG takes your approach we may need in future t= o change our specifications.

Nothing is wrong with= channel allocation in IETF we should be able to do that as well. We can re= gulate any of our protocols within any channel we agree on (if not please t= ell me what restricts us or what RFC stops us from such regulation) because= the packet is our protocol. No one can own the channel but we own the IPv6= specification, and we can say which is recommended (usually for the best b= enefit of users not regulators).

=C2=A0

MTC ...

RR

Le 19/09/2017 = =C3=A0 19:10, Dick Roy a =C3=A9crit=C2=A0:
Yes, b= y all means.=C2=A0 All of it is 1) subject to change, 2) way out of scope for the IETF, and 3) totally irrelevant to the planned effort.

1)=C2=A0=C2=A0Yes everything c= an change in future when we need it
=C2=A02= ) I don't think channel allocation for IPWAVE is out of scope for IETF,= because we already have cooperations between IEEE and IETF, so now things = change regulators around the world are working together to find best soluti= ons for best systems and best utilizations. IMHO, =C2=A0IPWAVE systems incl= uding channels are not out of scope for IETF, we work together (regulators = because they don't own IPv6 protocols) with others without layers or ab= stractions or separations.
3) No, I think i= t can be totally relevant if WG says so, but if=C2=A0WG don't want to t= hink out of the box then yes it is not relevant to WG effort.

Best Regards<= span>
--001a113d660a17adf40559a122fc-- From nobody Wed Sep 20 21:40:12 2017 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 8E1D31342C2 for ; Wed, 20 Sep 2017 21:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 uzUoaiQHyoFJ for ; Wed, 20 Sep 2017 21:40:09 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 E691C124239 for ; Wed, 20 Sep 2017 21:40:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8L4e3F9015803; Thu, 21 Sep 2017 06:40:03 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 63538202289; Thu, 21 Sep 2017 06:40:03 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 530E2201A50; Thu, 21 Sep 2017 06:40:03 +0200 (CEST) Received: from [132.166.84.14] ([132.166.84.14]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8L4dwij022494; Thu, 21 Sep 2017 06:40:02 +0200 To: Abdussalam Baryun , dickroy@alum.mit.edu, its References: <2E8AAA2242ED4122B30FFE4C49BFF5E8@SRA6> <64f88cf4-685a-9dff-4a3a-a7a8cf771781@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 21 Sep 2017 06:39:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] correction X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 04:40:12 -0000 Le 20/09/2017 à 18:04, Abdussalam Baryun a écrit : > > > Hi Alex and the authors of other emails included, > > My comments and discussion below > > > On Tue, Sep 19, 2017 at 1:44 PM, Alexandre Petrescu > > wrote: > > So, should I remove this paragraph: > >    o  Prohibition of IPv6 on some channels relevant for IEEE > 802.11-OCB, >       as opposed to IPv6 not being prohibited on any channel on > which >       802.11a/b/g/n runs: > >       *  Some channels are reserved for safety communications; > the IPv6 >          packets should not be sent on these channels. > >       *  At the time of writing, the prohibition is explicit at > higher >          layer protocols providing services to the application; > these >          higher layer protocols are specified in IEEE 1609 > documents, >          i.e. the "WAVE" stack. > >       *  National or regional specifications and regulations > specify the >          use of different channels; these regulations must be > followed. > > > Alex > > > you can remove but not sure did WG agree on that, Well there were two indications in that direction, and I agree with it too. You too say "you can". > > > Le 19/09/2017 à 00:06, Dick Roy a écrit : > > Alex et.al ., > > The simple fact is that how physical resources are to be used > (aka "what > apps are allowed on which channels") is a topic/issue way > outside the scope > of the IETF's work. > > > I don't agree with Dick Roy. The problem with the past IPv4 protocols is > just that approach, we are in the future of IPv6, we need to look into > future systems and protocols that use IPv6. In order to discuss with Dick Roy there are two possibilities: one is to approach him in private. In public, it is hard to discuss, because there is an email problem. I suggest you help Dick and IETF to fix that email problem. > > I highly recommend you make no statements on such > issues nor make any recommendations along those lines. > > > I think that is clean idea for now, however, we may need to make few > conditions. > > Stick to IPv6 > networking and the network (and transport) layer functions > required to > implement it.  Leave channel allocation issues to the > appropriate entities > ... the regulators and system integrators. > > > The problem is that our system is not always TCP/IP model layers that > was IPv4 systems. Err... I disagree. IPv6-over-OCB is still the TCP/IP model. > IMO  IPWAVE systems are more complicated and have > cross layers (I think we should not stick to one system layer model and > separate IPv6 networking). I agree with that, but how about solving it in a separate document? > > From your statement you want us to stick to old approach of system > design, but we need new for our protocols of IPv6. So I recommend we > don't stick to old IP networking because IPv6 is new and is future work. > However, IMHO if this WG takes your approach we may need in future to > change our specifications. Err... WE can discuss this separately in the intarea WG. There is an IPv10 proposal there, that I could contribute to. But here let us do IPv6-over-OCB, with old system design. Old system design gives us access to interoperability to very numerous existing old system designs. > Nothing is wrong with channel allocation in IETF we should be able to do > that as well. We can regulate any of our protocols within any channel we > agree on (if not please tell me what restricts us or what RFC stops us > from such regulation) because the packet is our protocol. No one can own > the channel but we own the IPv6 specification, and we can say which is > recommended (usually for the best benefit of users not regulators). Well, I agree. I also propose to stick together all the channels of the 5.9GHz into just one, to get higher bandwidth, for _some_ environments. But it is future work. It needs to update the ath10k driver, which is hard to do. Do you agree it is hard to do? [...] > Le 19/09/2017 à 19:10, Dick Roy a écrit : > > Yes, by all means.  All of it is 1) subject to change, 2) way out of > scope > for the IETF, and 3) totally irrelevant to the planned effort. > > > 1)  Yes everything can change in future when we need it >  2) I don't think channel allocation for IPWAVE is out of scope for > IETF, because we already have cooperations between IEEE and IETF, so now > things change regulators around the world are working together to find > best solutions for best systems and best utilizations. IMHO,  IPWAVE > systems including channels are not out of scope for IETF, we work > together (regulators because they don't own IPv6 protocols) with others > without layers or abstractions or separations. Let us propose something in a separate document. Do you agree? > 3) No, I think it can be totally relevant if WG says so, but if WG don't > want to think out of the box then yes it is not relevant to WG effort. Thinking out of the box will come time for it. In that sense, do you agree to pursue now in this direction with this draft? Alex > > Best Regards From nobody Thu Sep 21 03:54:56 2017 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 A723A1348DF for ; Thu, 21 Sep 2017 03:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, URIBL_BLOCKED=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 FOjKw4xibYf4 for ; Thu, 21 Sep 2017 03:54:50 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001: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 4B1581348EB for ; Thu, 21 Sep 2017 03:54:49 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id d16so9877434ioj.3 for ; Thu, 21 Sep 2017 03:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Av0uAdBc608A5BQBTEfZkmAvW55TFmhJbKQy1xRTVow=; b=RaETN/ux0o40MdmPJqDmJC2w6fH2gt+ZdnHqLFKTRM+Ulkjk3mqLLOnRevSoj9EzXO JkqsqOGJpyep01gPjjPC7PW4bJ6gN1X751G6/5CwVMM+FSgkgpTSdoqxxVjGhsSJDhfJ id5xRs1VWYToemnFyuPHxA+hpalml/7PGNC+1bI4ys8xM2fIYZ55CV5aK3GcGqLLVc9H 4A4XsJ/u01E7xnTl+3Yhy6dk2eSd+9Sp7R8v51vrrieI0lRxxwvWYkbWQv0IOJIGJIrg gACjOIDIgfQ9QGxdN2TCtIDSyJdvchPV9TSZQ6StulqHwv1oRtXByErWmaJ83eXFZFA3 LqUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Av0uAdBc608A5BQBTEfZkmAvW55TFmhJbKQy1xRTVow=; b=LY3yssnYEPDskBTxMZFeGZmjf/WcTjfQq1kUFi/CsF9DZ56dLaXpY2ABNWFHuuOcOZ IwR7FtbaaZqfm8VEl7JGPN9FJRyP1+7V9X5zzMUJwYWInD06qYfqqqSvqzGQMLAeUd2o TdadwQ+m8cUlxf7Xc8e8nFEiORIPwam4d7eEhtAh+BsKrtNbzCRfjk1Ajmw4MQZ9J9oZ eVE0bGft7fYfroctzgN6YrFgRruToV8EIxccMqN8LUEiykJ5uWmtTnoL8C+cgS88fLTx oFJX0irW6eOjz+y0v5/3sCGtbcqbWFMXDsvAiGTpLOK2Eh0BFfCPMnIYHfewkLUA3J81 XCpA== X-Gm-Message-State: AHPjjUjxHaZ3vLvZPHnnp8SS4HY/2NCArFYhOxyaVyRWZDmmPxMbKneu H+OtqiRkmCuOTnZeYZXQnk6hqULhazFHWBb5QqY= X-Google-Smtp-Source: AOwi7QBgd8c5+iqteU+/+MyR6PjuI+yYqdnS2ScmLs8kFDjL7HguvSGoO1hRRFXdAHR6inS4unGDOhJVUTVad0w0DRY= X-Received: by 10.202.73.65 with SMTP id w62mr1800664oia.167.1505991288542; Thu, 21 Sep 2017 03:54:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.20.66 with HTTP; Thu, 21 Sep 2017 03:54:47 -0700 (PDT) In-Reply-To: <49010CA2890B44CABF86C57A5633CBFD@SRA6> References: <2E8AAA2242ED4122B30FFE4C49BFF5E8@SRA6> <64f88cf4-685a-9dff-4a3a-a7a8cf771781@gmail.com> <49010CA2890B44CABF86C57A5633CBFD@SRA6> From: Abdussalam Baryun Date: Thu, 21 Sep 2017 12:54:47 +0200 Message-ID: To: Richard Roy Cc: Alexandre Petrescu , its Content-Type: multipart/alternative; boundary="001a113dbbeac9d9e50559b0ebef" Archived-At: Subject: Re: [ipwave] correction X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 10:54:54 -0000 --001a113dbbeac9d9e50559b0ebef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Richard My comments below [AB], sorry that I may not reply quickly on all comments, On Thu, Sep 21, 2017 at 7:42 AM, Dick Roy wrote: > Abdussalam, > > > > > > > > > > > > > > > > > > > > > > > > > * Thanks for taking the time to respond. I am sorry about the email > reflector issue. I hope it can be resolved soon. In the meantime, some > comments below =E2=80=A6 and feel free to contact me directly if you=E2= =80=99d like to > discuss in more detail. Cheers, RR ------------------------------ Fro= m: > Abdussalam Baryun [mailto:abdussalambaryun@gmail.com > ] Sent: Wednesday, September 20, 2017 9:05 AM > To: Alexandre Petrescu; dickroy@alum.mit.edu ; its > Subject: Re: [ipwave] correction Hi Alex and the authors of other > emails included, My comments and discussion below On Tue, Sep 19, > 2017 at 1:44 PM, Alexandre Petrescu > wrote: So, should I remove this paragraph= : > o Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB, > as opposed to IPv6 not being prohibited on any channel on which > 802.11a/b/g/n runs: * Some channels are reserved for safety > communications; the IPv6 packets should not be sent on these > channels. * At the time of writing, the prohibition is explicit at > higher layer protocols providing services to the application; > these higher layer protocols are specified in IEEE 1609 document= s, > i.e. the "WAVE" stack. * National or regional > specifications and regulations specify the use of different > channels; these regulations must be followed. Alex you can remove but n= ot > sure did WG agree on that, Le 19/09/2017 =C3=A0 00:06, Dick Roy a =C3= =A9crit : Alex > et.al ., The simple fact is that how physical resources ar= e > to be used (aka "what apps are allowed on which channels") is a topic/iss= ue > way outside the scope of the IETF's work. I don't agree with Dick Roy. > [RR] Join the crowd! You are by no means alone. * > *[AB] I don't follow ideas without discussions. .......You never know when the crowd change their mind, but it is good to discuss among different ideas when designing, otherwise our ideas are the creation of one person or one company and we don't relise that. I always like to join the crowd but discuss more to get to the best solution. The crowd are not always right, so be careful when you follow the crowd. * > > > * The problem with the past IPv4 protocols is just that approach, we are > in the future of IPv6, we need to look into future systems and protocols > that use IPv6. [RR] IPv6 is a set of protocols for communication between > peer entities in the network layer (layer 3 of the OSI model). They can = be > management entities (ND, ARP, etc.) and they can be data plane entities > (NPDU processing entities). The physical layers over which the NPDUs are > exchanged is/should be irrelevant to the peers. That=E2=80=99s the whole= point of > the layered model of communications. Yes, there are cross-layer > optimizations that are possible, but that is beyond the scope of any IETF > effort in this regard (making IPv6 work over rapidly varying network > topologies). If a regulator states that physical streams (physical layer > communication strings of bits exchanged over communication media) on a > particular RF channel can not use IPv6 as the layer 3 protocol, will that > change in any way the work upon which the rest of the ITS world hopes the > IETF will embark? I sure as h__k hope not! I recommend people stop > thinking about issues that are irrelevant to their work and over which th= ey > have no control. It=E2=80=99s a waste of time and energy. The IETF shou= ld > concentrate on its job, not someone else=E2=80=99s. * > > > [AB] We now days need to cooperate with SDOs even if we work in separate SDOs, before experts work alone but now we need to work together. However, we are not discussing use case of rapidly varying network topology, we only discussing IPWAVE, I think they are different cases. [AB] You say physical layers should be irrelevant, but we know that it affects the peer communications. For example using wired or wireless channels for TCP applications has different results, so we have recommendations for using such packets/protocol in such media, regarding frequencies, different countries as Japan/USA/Germany/etc. may rule for different PHY technology for ITS, but our system we design in IETF is not for one country or two. However, yes countries/governments are controlling channel allocation technologies use, but we travel among different countries/systems with IPv6 technologies. [AB] IMHO, it is not waste (to discuss on list) of time to make our work original and use all PHY-technologies with recommendation of such channel allocations or media accesses. I will stop thinking when SDOs make a standard available for IPWAVE. [AB] IMO, Our use-case user is a vehicle that can carry many/100 of physical devices (Am I wrong?), a user may decide/allocate the best regulated-channel/technology available to use in terms of reliability or other purpose. The user owns the technologies and can use the best channel of communication available (physically or virtually). [AB] our charter states: *The group will try to reuse relevant technologies for Internet ofThings (IoT) and infrastructure mobility that have been developedin other IETF and IRTF groups. The WG will pay particularattention to the privacy characteristics of solution it developsin order to minimize unwanted tracking opportunities. The groupwill closely coordinate with IEEE 802.11. The IETF has alsoestablished a formal liason relationship with ISO/TC204 inconnection with the work to be performed by this workinggroup. The work produced by this group may also be of interest toother SDOs such as ETSI TC ITS, 3GPP, and governmentorganizations such as the NHTSA. No formal co-ordination isanticipated with these groups at this point but work done inthese SDOs may end up becoming relevant to the WG deliverables inthe future. * > > > > > * I highly recommend you make no statements on such issues nor make any > recommendations along those lines. I think that is clean idea for now, > however, we may need to make few conditions. Stick to IPv6 networking a= nd > the network (and transport) layer functions required to implement it. > Leave channel allocation issues to the appropriate entities ... the > regulators and system integrators. The problem is that our system is no= t > always TCP/IP model layers that was IPv4 systems. IMO IPWAVE systems are > more complicated and have cross layers (I think we should not stick to on= e > system layer model and separate IPv6 networking). [RR] First, as you stat= e, > TCP/IP is simply a transport protocol on top of a network protocol, wheth= er > it=E2=80=99s IPv4 or IPv6, and while there is no such thing as an IPWAVE = system > (unless you defined one), the WAVE (1609.x) standards have gratuitous > support for IPv6 in one small paragraph, and in a WRA (I know because I w= as > part of the team that wrote it.). That said, =E2=80=9CWAVE systems=E2=80= =9D (really WAVE > devices acting as nodes in the ITS communication system) are no more > complicated than your laptop. There are no =E2=80=9Ccross layer=E2=80=9D= issues other than > those well-known ones which were found to be relevant over 20 years ago > when the =E2=80=9Cmanagement plane=E2=80=9D was conceived. * > [AB] IMO, Define the IPWAVE system/application (as from the WG charter) as that work on V2V and V2I use-cases where IP is well-suited as a networking technology and will develop an IPv6 based solution to establish direct and secure connectivity between a vehicle and other vehicles or stationary systems. These vehicular networks are characterized by dynamically changing network topologies and connectivity. [AB] We in IETF are different than IEEE, they look into design down to up, but we look from up to down, we look at our applications and services for users and then look into physical, so we have an advantage above IEEE. Furthermore, the Internet services is needed by all so the physical layer experts needs to work harder to follow our IPWAVE applications. As you may know that the mobile system is changing from many generations for best internet service, there was a change in frequency allocation worldwide and per countries just because they want higher/better internet services. Systems/technologies within 2G, 3G, 4G are available with different frequencies and different users > > *From your statement you want us to stick to old approach of system > design,* > > *[RR] Absolutely not! Read any (or all:^)) of the ISO TC204 WG16/18 > standards (many of which I worked on) and see if there is anything therei= n > that would lead you to believe we are looking for yesterday=E2=80=99s tec= hnology! > You will NOT find anything!* > > * but we need new for our protocols of IPv6. * > > *So I recommend we don't stick to old IP networking because IPv6 is new > and is future work. However, IMHO if this WG takes your approach we may > need in future to change our specifications.* > > *[RR] The ITS community is counting on the IETF to revise old standards > and create new ones to address the challenges of implementing IPv6 > networking in ITS! That said, IPv4 will be around for quite a while and I= TS > needs to accommodate that fact. IPv6 is still in its infancy, and we are > counting on it succeeding! Let=E2=80=99s get the ball rolling, and now!* > [AB] Yes I agree that we all need to standard for IPWAVE so IETF wants all experts to participate, its open to all, but we do things right in IETF not like others maybe. however, in our WG we need to into new standards of other WGs that related to us as well for the future of IoT, which yes we never say we will stop IPv4 availability for our users. > > > *Nothing is wrong with channel allocation in IETF we should be able to do > that as well. * > > *[RR] If I understand the IETF=E2=80=99s charter, the answer is, while yo= u should > be =E2=80=9Cable=E2=80=9D to do it (remember we are talking about layer 1= physical > channels, not layer 3 logical channels), you should not do it. It is > rarely if ever a good idea to step outside one=E2=80=99s area of expertis= e and make > proclamations which, with probability one will, in the very near future, > make them look like something less than knowledgeable let=E2=80=99s just = say. There > is NO upside to making such statements, only a downside. If someone want= s > to transmit IPv6 packets using tin cans and strings, or smoke signals, th= ey > should be able to do so and the IETF should cheer loudly and admire their > ingenuity! * > > *We can regulate any of our protocols within any channel we agree on (if > not please tell me what restricts us or what RFC stops us from such > regulation) * > > *[RR] Since the IETF has no authority to do so, and it has NO means of > enforcement, any restrictions you put on physical layer communications in > your RFC=E2=80=99s are vacuous. * > [AB] We should recommend what is best to be use per technology per service. Our user can carry many technologies and is travelling within many regulators areas, so there is in some points that you can use/connect both/two/three channels when you become in boarders. The user is travelling and owns the technologies which are regulated/available. As we do a section for security considerations in RFCs the user may not use it but it is there for best. > *because the packet is our protocol. * > > *[RR] The layer 3 packet conforms to your protocol; the physical layer > stream conforms to someone else=E2=80=99s protocol and that is, as the pr= ophet > said, =E2=80=9Cnone of your business=E2=80=9D.* > [AB] It is the owner's business, he owns the transmitter and maybe the receiver as well, this layering thinking/business is wrong. We have business with IP users around the world, why we should not recommend what is best in PHY layers including allocation of channels. > *No one can own the channel* > > *[RR] That=E2=80=99s also not true, but I digress.* > [AB] A physical wireless channel can be used by any one that owns a transmitter and/or receiver that works on such channel, > * but we own the IPv6 specification, * > > *[RR] No you don=E2=80=99t. It=E2=80=99s in the public domain. Just goo= gle IPv6 > specifications!* > [AB] I mean owning it as we can change/amend it when IETF decides so. The author is the owner of the document even if it is in public. > *and we can say which is recommended (usually for the best benefit of > users not regulators).* > > *[RR] You can recommend whatever you like =E2=80=A6 and users can freely = ignore it > as they wish. Who cares? What makes you think that an expert in physica= l > layer communications should listen to a network layer guru who has never > held a soldering iron trying to tell him how to do his job? Is there > anyone so foolish?? I wonder ...* > [AB] You can see how the developed the mobile cellular system and you will know that both experts computing and engineering must listen/advise to each other, otherwise no networking. Yes users may ignore but when a problem occurs the user becomes the fool not the standard issuer. best, AB --001a113dbbeac9d9e50559b0ebef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard

My comments below= [AB], sorry that I may not reply quickly on all comments,

On Thu, Sep 21, 2017 at 7:4= 2 AM, Dick Roy <dickroy@alum.mit.edu> wrote:

Abdussalam,

=C2=A0=

Thanks for taking th= e time to respond.=C2=A0 I am sorry about the email reflector issue.=C2=A0 I hope it can be resolved s= oon.

=C2=A0=

In the meantime, som= e comments below =E2=80=A6 and feel free to contact me directly if you=E2=80=99d like to discuss in mo= re detail.

=C2=A0=

Cheers,


RR

=C2=A0=

From:<= font face=3D"Tahoma" size=3D"2"> Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: Wednesday, September 2= 0, 2017 9:05 AM
To: Alexandre Petrescu; dickroy@alum.mit.= edu; its
Subject: Re: [ipwave] correc= tion

=C2=A0

=C2=A0

=C2=A0

Hi Alex and the authors of other emails included,

=C2=A0

My comments and discussion=C2=A0below

=C2=A0

=C2=A0

On Tue, Sep 19, 2017 at 1:4= 4 PM, Alexandre Petrescu <alexa= ndre.petrescu@gmail.com> wrote:

So, should I remove this paragraph:

=C2=A0 =C2=A0o=C2=A0 Prohibition of IPv6 on some chann= els relevant for IEEE 802.11-OCB,
=C2=A0 =C2=A0 =C2=A0 as opposed to IPv6 not being prohibited on any channel= on which
=C2=A0 =C2=A0 =C2=A0 802.11a/b/g/n runs:

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 Some channels are reserved for safety communic= ations; the IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets should not be sent on these chann= els.

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 At the time of writing, the prohibition is explicit at higher
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0layer protocols providing services to the application; these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0higher layer protocols are specified in I= EEE 1609 documents,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i.e. the "WAVE" stack.

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 National or regional specifications and regulations specify the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use of different channels; these regulati= ons must be followed.


Alex

=C2=A0

you can remove but not sure did WG agree on that,

=C2=A0


Le 19/09/2017 =C3=A0 00:06, Dick Roy a =C3=A9crit=C2=A0:

Alex et.al= .,

The simple fact is that how physical resources are to be used (aka "wh= at
apps are allowed on which channels") is a topic/issue way outside the scope
of the IETF's work.=C2=A0

=C2=A0

I don't agree with Dick Roy. =

[RR] Join the crowd! Y= ou are by no means alone.

<= /u>
=

[AB]=C2=A0 I don't follow ideas =C2=A0without dis= cussions.=C2=A0.......You never know when the crowd change their mind, but = it is good to discuss=C2=A0among different ideas when designing, otherwise = our ideas are the creation of one person or one company and we don't re= lise that. I always like to join the crowd but discuss more=C2=A0to get to = the best solution. The crowd=C2=A0are not always right, so be careful when = you follow the crowd. =C2=A0

=C2=A0

=

The problem with the past IPv4 protocols is just that = approach, we are in the future of IPv6, we need to look into future systems and protocols th= at use IPv6.

[RR] IPv6 is a set of = protocols for communication between peer entities in the network layer (layer 3 of the OSI model).=C2=A0 They c= an be management entities (ND, ARP, etc.) and they can be data plane entities (NP= DU processing entities).=C2=A0 The physical layers over which the NPDUs are ex= changed is/should be irrelevant to the peers.=C2=A0 That=E2=80=99s the whole point = of the layered model of communications. Yes, there are cross-layer optimizations t= hat are possible, but that is beyond the scope of any IETF effort in this regar= d (making IPv6 work over rapidly varying network topologies).=C2=A0 If a regu= lator states that physical streams (physical layer communication strings of bits exchanged over communication media) on a particular RF channel can not use = IPv6 as the layer 3 protocol, will that change in any way the work upon which th= e rest of the ITS world hopes the IETF will embark?=C2=A0 I sure as h__k hope= not! I recommend people stop thinking about issues that are irrelevant to their wo= rk and over which they have no control.=C2=A0 It=E2=80=99s a waste of time and= energy.=C2=A0 The IETF should concentrate on its job, not someone else=E2=80=99s.<= /u>

=C2=A0

=

[AB] We now days need to= cooperate with SDOs=C2=A0even if we work in separate SDOs, before=C2=A0exp= erts work alone but now we need to work together. However, we are not discu= ssing use case of rapidly varying network topology, we only discussing IPWA= VE, I think they are different cases.

[AB] You say= physical layers should be irrelevant, but we know that it affects the peer= communications. For example using wired or wireless channels for TCP appli= cations has different results, so we have recommendations for using such pa= ckets/protocol in such media, regarding frequencies, different countries as= Japan/USA/Germany/etc. may=C2=A0rule for=C2=A0different PHY technology for= ITS, but our system we design in IETF is not for one country or two. Howev= er, yes countries/governments are controlling channel allocation technologi= es use, but we travel=C2=A0among different countries/systems with IPv6 tech= nologies.

[AB] =C2=A0IMHO, it is not waste (to dis= cuss on list) of time to make our work original and use all PHY-technologie= s with recommendation of such channel allocations or media accesses. I will= stop thinking when SDOs=C2=A0 make a standard available for IPWAVE.
<= div>
[AB]=C2=A0IMO, Our=C2=A0use-case user is a vehicle that = can carry many/100 of physical=C2=A0devices (Am I wrong?), a us= er may decide/allocate the best regulated-channel/technology available to u= se in terms of reliability or other purpose. The user owns the technologies= and can use the best channel of communication available (physically or vir= tually).=C2=A0

=
[AB] our charter states:
=
The group will try to reuse relevant te= chnologies for Internet of
Things (IoT) and infrastructure mobility that= have been developed
in other IETF and IRTF groups. The WG will pay part= icular
attention to the privacy characteristics of solution it develops<= br>in order to minimize unwanted tracking opportunities. The group
will = closely coordinate with IEEE 802.11. The IETF has also
established a for= mal liason relationship with ISO/TC204 in
connection with the work to be= performed by this working
group. The work produced by this group may al= so be of interest to
other SDOs such as ETSI TC ITS, 3GPP, and governmen= t
organizations such as the NHTSA. No formal co-ordination is
anticip= ated with these groups at this point but work done in
these SDOs may end= up becoming relevant to the WG deliverables in
the future.= =C2=A0
=

=

I highly recommend you make no statements on such
issues nor make any recommendations along those lines.=C2=A0<= /span>

=C2=A0

I think that is clean idea for now, however, we may ne= ed to make=C2=A0few conditions.

=C2=A0

Stick to IPv6
networking and the network (and transport) layer functions required to
implement it.=C2=A0 Leave channel allocation issues to the appropriate enti= ties
... the regulators and system integrators.

<= u>

=C2=A0

The problem is that our system is not always TCP/IP mo= del layers that was IPv4 systems.=C2=A0IMO =C2=A0IPWAVE systems are more complicated and ha= ve cross layers=C2=A0(I think we should not stick to one system layer model an= d separate IPv6 networking).

[RR] First, as you sta= te, TCP/IP is simply a transport protocol on top of a network protocol, whether it=E2=80=99s IPv4 or IPv6, a= nd while there is no such thing as an IPWAVE system (unless you defined one), = the WAVE (1609.x) standards have gratuitous support for IPv6 in one small paragraph,= and in a WRA (I know because I was part of the team that wrote it.).=C2=A0 That= said, =E2=80=9CWAVE systems=E2=80=9D (really WAVE devices acting as nodes in the ITS communicat= ion system) are no more complicated than your laptop.=C2=A0 There are no =E2=80= =9Ccross layer=E2=80=9D issues other than those well-known ones which were found to = be relevant over 20 years ago when the =E2=80=9Cmanagement plane=E2=80=9D was = conceived. =C2=A0

<= /div>


[AB]=C2=A0 IMO, Define the IPWAVE system/application (as from the WG char= ter) as=C2=A0that work on V2V and V2I use-cases where IP is
well-suited = as a networking technology and will develop an IPv6
based solution to es= tablish direct and secure connectivity
between a vehicle and other vehic= les or stationary systems. These
vehicular networks are characterized by= dynamically changing
network topologies and connectivity.
[AB] We in IETF are different than IEEE, they look=C2=A0into de= sign down to up, but we look from up to down, we look at our applications a= nd=C2=A0services for users and then look into physical, so we have an advan= tage above IEEE. Furthermore, the Internet services is needed by all so the= physical layer experts needs to work harder to follow our IPWAVE applicati= ons. As you may know that the mobile system is changing from many generatio= ns for best internet service,=C2=A0there was a change in frequency allocati= on worldwide and per countries just because they want higher/better interne= t services. Systems/technologies within 2G, 3G, 4G are available with diffe= rent frequencies and different users=C2=A0=C2=A0

=

=C2=A0

From your statement you want us to stick to old= approach of system design,

[RR] Absolutely not!=C2=A0 Read any (or all:^= )) of the ISO TC204 WG16/18 standards (many of which I worked on) and see if there is anything therein = that would lead you to believe we are looking for yesterday=E2=80=99s technology= ! You will NOT find anything!

=C2=A0but=C2=A0we need new for our protocols of= IPv6.

So I recommend we don't stick to old IP net= working because IPv6 is new and is future work. However, IMHO if this WG takes your approach we may nee= d in future to change our specifications.

[RR] The ITS community is counting on the IETF = to revise old standards and create new ones to address the challenges of implementing IPv= 6 networking in ITS! That said, IPv4 will be around for quite a while and ITS needs to accommodate that fact. IPv6 is still in its infancy, and we are counting on it succeeding!=C2=A0 Let=E2=80=99s get the ball rolling, and no= w!


[AB]=C2=A0 Yes I agree that we all need to standa= rd for IPWAVE so IETF wants all experts to participate, its open to all, bu= t we do things right in IETF not like others maybe. however, in our WG we n= eed to into new standards of other WGs that related to us as well for the f= uture of IoT, which yes we never say we will stop IPv4 availability for our= users.=C2=A0
=C2=A0

=C2=A0

Nothing is wrong with channel allocation in IET= F we should be able to do that as well.

[RR] If I understand the IETF=E2=80=99s chart= er, the answer is, while you should be =E2=80=9Cable=E2=80=9D to do it (remember we are talkin= g about layer 1 physical channels, not layer 3 logical channels), you should not do= it. =C2=A0It is rarely if ever a good idea to step outside one=E2=80=99s area o= f expertise and make proclamations which, with probability one will, in the very near future, make them look like something less than knowledgeable let=E2=80=99s= just say. There is NO upside to making such statements, only a downside.=C2=A0 I= f someone wants to transmit IPv6 packets using tin cans and strings, or smoke signals= , they should be able to do so and the IETF should cheer loudly and admire their i= ngenuity!

We can regulate any of our protocols within any= channel we agree on (if not please tell me what restricts us or what RFC stops us from such regulat= ion)

[RR] Since the IETF has no authority to do so= , and it has NO means of enforcement, any restrictions you put on physical layer communications in your RFC=E2=80=99s are vacuous. =C2=A0<= /i>


=
[AB]=C2=A0 We=C2=A0should recommend what is best to be use per technol= ogy per service. Our user can carry many technologies and is travelling wit= hin many regulators areas, so there is in some points that you can use/conn= ect both/two/three channels when you become in boarders. The user is travel= ling and owns the technologies which are regulated/available.=C2=A0As we do= a section for security considerations in RFCs the user may not use it but = it is there for best.
=C2=A0

because the packet is our protocol.

[RR] The layer 3 packet conforms to your prot= ocol; the physical layer stream conforms to someone else=E2=80=99s protocol and that is, as th= e prophet said, =E2=80=9Cnone of your business=E2=80=9D.


[AB]=C2=A0 It is the owner's business, he owns the transmitter and m= aybe the receiver as well, this layering thinking/business is wrong. We hav= e business with IP users around the world, why we should not recommend what= is best in PHY layers including allocation of channels.

=C2=A0

No one can own the channel=

[RR] That=E2=80=99s also not true, but I digr= ess.


[AB]=C2=A0 A physical wireless channel can be u= sed by any one that owns a transmitter and/or receiver that works on such c= hannel,
=C2=A0

=C2=A0but we own the IPv6 specification, <= /p>

[RR] No you don=E2=80=99t.=C2=A0 It=E2=80=99s= in the public domain.=C2=A0 Just google IPv6 specifications!

=

[AB]=C2=A0 I mean owning= it as we can change/amend =C2=A0it when=C2=A0IETF decides so. The author i= s the owner of the document even if it is in public.
=C2=A0=C2=A0=
<= div>

and we can say which is recommended (usually fo= r the best benefit of users not regulators).

[RR] You can recommend whatever you like =E2= =80=A6 and users can freely ignore it as they wish.=C2=A0 Who cares?=C2=A0 What makes you th= ink that an expert in physical layer communications should listen to a network layer gu= ru who has never held a soldering iron trying to tell him how to do his job?= =C2=A0 Is there anyone so foolish??=C2=A0 I wonder ...

<= /div>

[AB]=C2= =A0 You can see how the developed the mobile cellular system and you will k= now that both experts computing and engineering must listen/advise to each = other, otherwise no networking. Yes users may ignore but when a problem occ= urs the user becomes the fool not the standard issuer.

=
best,
AB

 --001a113dbbeac9d9e50559b0ebef-- From nobody Sat Sep 23 11:42:52 2017 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 EE7C0132992 for ; Sat, 23 Sep 2017 11:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=it-uc3m-es.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 EecVBBrGFM-g for ; Sat, 23 Sep 2017 11:42:48 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c: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 0B9E813295C for ; Sat, 23 Sep 2017 11:42:48 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id m72so5680183wmc.0 for ; Sat, 23 Sep 2017 11:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:organization :mime-version:content-transfer-encoding; bh=1kz5dQXODjXhj7pknZYGHSfm5Ug8VstZsfYZ9P1C774=; b=TiPNv5F3G4M/nrJXSPDRTKQT7HNF266DupWtdYyqeeSlBN9VWyEDNRcAf2Ci6R92pw 7Ot+/NS0x3c1Vg1kyrw8Kicn2ZrnW6cB8rZvVFoiTpRfSW0L5e0Y6pSrfnV/W+AqVrEC lAoJo8+zHoOZ1fKpDDvLHitA9+XMEeg2Wbqfx0iZ/ewWHQimscNHhgGmTzTcNwSFrrK2 1T6yT6Q9TzcVRChoWR9R9B5nUlA/6vWHA1Km2YlB207PYAnKccOJ4LFmUDfaA7SdEMoK Ay4cIwlM94vnc5uLZ2b/x90DKO+qerxO6h3IMTFuwaWMFrdgxmtWxKhDdTyb45+HiCZ6 xHog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :organization:mime-version:content-transfer-encoding; bh=1kz5dQXODjXhj7pknZYGHSfm5Ug8VstZsfYZ9P1C774=; b=R9uQ+Iw+KaBBiwkRGr4OxCT+TgW5yQFOZhmZUZLUR0FXYMTbs0btYLpcoHlQ3eUxLw azYWDq58Ra54JNW4dzgXx45d9ycHSatOO2mviNUPc2+79UwQxN1FmcNN5QiEmsRith9m OfWFokS8fe5TWdbISmXB4fPdC0XG+6ifHCwaKLweIxK1dk3jNCE989ew3NtKjiBClyFC HxaYXYzwqJPqSMW4u9ept3naFEmkhrFMo/zUHGpHJWpFGQ4CulMfEeIZZaLpoDk+qYzA GrnSSe6qOpMMDc4fjlpo+dtg/HiDRcQwrj28cL7FhixQAwvDCuQ5JwJPeFc5tKaAJmWv DZvw== X-Gm-Message-State: AHPjjUjfq1KpYIV7kMhqYYOrRli26QgOENQLBb2Z+RwIS5V6tbSZKjw6 R3pytnYNgBIFk0U0bOtEDApnVsl+ X-Google-Smtp-Source: AOwi7QB2qZiRXhGhcyJcLtooq1qru5t7ckNiuZ5ISWB9/NCULAm4068z6ZzefQf7lmKduvLEJdnynA== X-Received: by 10.28.63.134 with SMTP id m128mr7049192wma.137.1506192166266; Sat, 23 Sep 2017 11:42:46 -0700 (PDT) Received: from cjbc_dell.lan (2.154.162.161.dyn.user.ono.com. [2.154.162.161]) by smtp.gmail.com with ESMTPSA id y99sm8572114wmh.1.2017.09.23.11.42.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 23 Sep 2017 11:42:45 -0700 (PDT) Message-ID: <1506192164.12227.3.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: "its@ietf.org" Cc: ipwave-chairs@ietf.org Date: Sat, 23 Sep 2017 20:42:44 +0200 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 18:42:51 -0000 Hi, Hereby we are issuing a WGLC for draft-ietf-ipwave-ipv6-over-80211ocb- 08.  The WGLC will be open till the 8th of October to give enough time for people to review. We kindly ask the WG to review the document and provide comments. If you have no comments and think the document is ready, please do send a note stating that to the WG ML. Additional information about the document is below:         Title           : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)         Authors         : Alexandre Petrescu                           Nabil Benamar                           Jérôme Härri                           Christian Huitema                           Jong-Hyouk Lee                           Thierry Ernst                           Tony Li         Filename        : draft-ietf-ipwave-ipv6-over-80211ocb-08.txt         Pages           : 38         Date            : 2017-09-19 Abstract:    In order to transmit IPv6 packets on IEEE 802.11 networks running    outside the context of a basic service set (OCB, earlier "802.11p")    there is a need to define a few parameters such as the supported    Maximum Transmission Unit size on the 802.11-OCB link, the header    format preceding the IPv6 header, the Type value within it, and    others.  This document describes these parameters for IPv6 and IEEE    802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB    similarly to other known 802.11 and Ethernet layers - by using an    Ethernet Adaptation Layer.    In addition, the document lists what is different in 802.11-OCB    (802.11p) links compared to more 'traditional' 802.11a/b/g/n links,    where IPv6 protocols operate without issues.  Most notably, the    operation outside the context of a BSS (OCB) impacts IPv6 handover    behaviour and IPv6 security. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-08 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211 ocb-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb- 08 Thank you for your support. -- Russ and Carlos